Hi Gyan,
What revision are you reading ?
I found the 4.21.1 only in its very early revision (-00 and -01).
There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft is
rev-11 : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
And I think the explanation of “A
Hi Barry,
At 12:35 PM 02-03-2020, Barry Leiba wrote:
- We need to just let this stuff go and not worry about it.
Thanks. I was a bit worried about whether the old statement was
still applicable.
Regards,
S. Moonesamy
___
spring mailing list
spr
Hi Jingrong
I am following what you displayed and it makes sense. In section 4.21.1 for
the PSP flavor what was confusing was it said that the End.X with PSP
flavor can pop the SRH. The way it’s written, to me it reads that any P
router can pop the SRH when the last SID is written to the DA. So
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
At Sat, 29 Feb 2020 12:06:17 +0100,
Robert Raszuk wrote:
> Even if RFC8200 section 4 text would say:
>
> "Extension headers cannot be added to a packet after it has left its
> source node and extension headers cannot be removed from a packet until it
> has arrived at its ultimate destination".
>
Folks,
I'm trying to come up with a list of the issues raised during the WGLC
of this document.
So far, this is what I have:
1) Participants requested a justification for the need of PSP
(Penultimate Segment Pop). [PSP-R]
2) Participants noted that PSP violates RFC8200 [IPV6-V]
3) Partici
Contributor - not co-author - but also with 6 drafts that have normative
references to the draft in question that could not proceed if this stalled
Andrew
On 03/03/2020, 00:44, "ietf on behalf of Sander Steffann"
wrote:
Hi,
> I have no information about the situation but I do n
On Tue, 3 Mar 2020 at 08:39, Mark Smith wrote:
>
> This -11 draft was posted at 3:53 am Melbourne, Australia time, and this
> declaration of consensus was at 5:35 am Melbourne, Australia time.
>
> Sometimes I'm awake at those hours, but not last night. I did not have an
> opportunity to review t
well, that is a funky situation
thanks
Scott
> On Mar 2, 2020, at 4:43 PM, Sander Steffann wrote:
>
> Hi,
>
>> I have no information about the situation but I do not understand why an AD
>> would be declaring consensus in any case -
>> that is normally the responsibility of WG chairs. see
Hi,
> I have no information about the situation but I do not understand why an AD
> would be declaring consensus in any case -
> that is normally the responsibility of WG chairs. see RFC 2418 section 3.3
The only active/available WG chair was a co-author of this draft.
Cheers,
Sander
I have no information about the situation but I do not understand why an AD
would be declaring consensus in any case -
that is normally the responsibility of WG chairs. see RFC 2418 section 3.3
Scott
> On Mar 2, 2020, at 4:30 PM, Sander Steffann wrote:
>
> Hi Ted,
>
>> Without any comment
This -11 draft was posted at 3:53 am Melbourne, Australia time, and this
declaration of consensus was at 5:35 am Melbourne, Australia time.
Sometimes I'm awake at those hours, but not last night. I did not have an
opportunity to review the changes.
Regards,
Mark.
On Tue, 3 Mar 2020, 05:53 Ma
Hi Ted,
> Without any comment on this particular instance, it is generally a good idea
> to go through an appeal of a specific decision first. My experience is that
> people do reconsider their actions in the light of appeals fairly frequently,
> and it is generally better to explore the option
Hi Sander,
Without any comment on this particular instance, it is generally a good
idea to go through an appeal of a specific decision first. My experience is
that people do reconsider their actions in the light of appeals fairly
frequently, and it is generally better to explore the option of
reco
Dear all,
The procedure to instantiate what effectively constitutes a resignation is
described in 7437 + 8713, specifically
https://tools.ietf.org/html/rfc7437#section-7 and
https://tools.ietf.org/html/rfc8713#section-7
Keep in mind, this is a different process than an appeal on for instance a
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
Hi Darren,
On Fri, 28 Feb 2020 at 08:11, Darren Dukes (ddukes)
wrote:
>
> Mark AH is not defined for SRH. There is no specification to ignore.
>
So AH is defined for RFC8200 IPv6 (and back to as early as RFC1883 IPv6 in
RFC1826), and if a node claims to talk RFC IPv6, then AH should be able to
I won't just throw in a +1 ;)
On the serious side; following this discussion closely, I have to agree
that at the least it doesn't feel correct and as if this is the right way
of operating.
It might be correct from a procedure pov but it doesn't feel like it should
go this way.
Thanks Nick for wo
Hi Nick,
> At the very least, the consensus judgement needs to be rolled back. I
> respectfully suggest that Martin needs to recuse himself from any further
> involvement with this draft, and that he should consider whether his actions
> are compatible with continuing to be an AD.
Thank you,
Sander Steffann wrote on 02/03/2020 20:32:
Steamrolling a draft through a working group completely undermines
the whole idea of the IETF and greatly damages it trustworthiness and
reliability. By bluntly declaring consensus despite all of the
objections within two hours of the latest version of
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
> On 02/03/2020, 23:34, "ietf on behalf of Sander Steffann"
> wrote:
>
>Hi,
>
> I am shocked by the declaration of consensus on
> draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was
> much discussion going on about one aspect of the draft, and there was clearly
The IESG discussed this years ago (during my prior term) and decided
the following:
- Such disclaimers are impossible for us to stop: they're mandated by
people's companies and they will appear.
- Regardless of what disclaimers appear in people's messages, any
messages that amount to Contribution
Hi,
I am shocked by the declaration of consensus on
draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was much
discussion going on about one aspect of the draft, and there was clearly no
consensus amongst the participants. There are still questions that haven't been
answere
Martin,
As an Area Director, what are your thoughts regarding Bruno's claim that
this working group (Spring) doesn't have the necessary skills for
evaluating the need of a functionality (PSP) that this wg is including
in draft-ietf-spring-srv6-network-programming?
Specifically, Bruno has not
Martin,
On 2/3/20 15:53, Martin Vigoureux wrote:
WG,
as I had indicated in a previous message I am the one evaluating
consensus for this WG LC.
This is more and more confusing, seriously.
Bruno did the WGLC, and also communicated the outcome of the WGLC in
first person, and now you state t
Hi Alvaro,
At 11:09 AM 02-03-2020, Alvaro Retana wrote:
[Changed the subject to better reflect the topic and for easier tracking.]
Thanks.
Hi! How are you?
I am okay.
I looked at BCP 9, but didn't find anything related to your question.
If I missed it, please point me in the right direct
Hi,
> My overall conclusion is that there is support and rough consensus to move
> this document to the next stage.
Declare consensus immediately after a new version is published and people
haven't even had the change to read it?
NO, just NO
Sander
signature.asc
Description: Message signed
Hi Bruno,
>> Wait, what?! There is no "we needed to advance this document" in the IETF
>> or any other consensus based forum...
>
> By advance this document, I meant start the WG LC. Which is about collecting
> comments on the document.
I think you are confused. This document has been in WG L
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
I am completely stunned by this.
The question regarding RFC8200 is still unaddressed.
The promises to deliver an assessment of IP Space burn as per what is on video
from the montreal meeting – was not delivered on or addressed
The issues around the potentially problems in relation to rfc7112 – ha
The explanations added to section 4.16.1 "PSP: Penultimate Segment Pop of the
SRH" certainly help. However, there is still no explanation of how this section
is reconciled with RFC 8200. Whether the reader agrees with that reconciliation
or not is a separate matter, but I fail to see how this dr
Martin,
On 03-Mar-20 07:53, Martin Vigoureux wrote:
> WG,
>
> as I had indicated in a previous message I am the one evaluating
> consensus for this WG LC.
>
> I have carefully read the discussions on the list. I acknowledge that
> disagreements were expressed regarding what a particular piece
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 March 2, 2020 at 1:21:25 PM, S Moonesamy wrote:
[Changed the subject to better reflect the topic and for easier tracking.]
SM:
Hi! How are you?
> I sent a message to the SPRING Working Group Chairs. The reply which
> I received from a person who is listed as one of the SPRING Working
> Gro
WG,
as I had indicated in a previous message I am the one evaluating
consensus for this WG LC.
I have carefully read the discussions on the list. I acknowledge that
disagreements were expressed regarding what a particular piece of text
of RFC 8200 says, and on which this document builds to p
Dear IESG,
I sent a message to the SPRING Working Group Chairs. The reply which
I received from a person who is listed as one of the SPRING Working
Group Chairs contains the following footer:
"This message and its attachments may contain confidential or privileged
information that may b
Ketan,
Based on current documents, allocating all SRv6 locators used in a domain
from a single block is optional.
However, assuming for the moment that a network operator has chosen to
allocate all SRv6 locators used in a domain from a single block, so that
there is a well-defined value of B and
Dear S Moonesamy,
> -Original Message-
> From: S Moonesamy [mailto:sm+i...@elandsys.com]
> Sent: Monday, March 2, 2020 6:34 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: Warren Kumari; Martin Vigoureux; Rob Shakir; spring@ietf.org
> Subject: RE: [spring] Request to close the LC and move forward/
On 2/3/20 14:28, bruno.decra...@orange.com wrote:
Fernando,
From: Fernando Gont [mailto:ferna...@gont.com.ar]
Sent: Monday, March 2, 2020 6:14 PM
To: DECRAENE Bruno TGI/OLN; S Moonesamy; Martin Vigoureux; Suresh Krishnan
Cc: spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-ne
Dear Mr Decraene,
At 09:14 AM 02-03-2020, bruno.decra...@orange.com wrote:
On my side, the header from your email is the following:
> > -Original Message-
> > From: S Moonesamy [mailto:sm+i...@elandsys.com]
> > Sent: Thursday, February 27, 2020 8:53 PM
> > To: DECRAENE Bruno TGI/OLN; Rob
Fernando,
> From: Fernando Gont [mailto:ferna...@gont.com.ar]
> Sent: Monday, March 2, 2020 6:14 PM
> To: DECRAENE Bruno TGI/OLN; S Moonesamy; Martin Vigoureux; Suresh Krishnan
> Cc: spring@ietf.org
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
> On 2/3/20 11:16, br
Dear S Moonesamy,
> From: S Moonesamy [mailto:sm+i...@elandsys.com]
> Sent: Monday, March 2, 2020 5:34 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: Warren Kumari; Martin Vigoureux; Rob Shakir; spring@ietf.org
> Subject: RE: [spring] Request to close the LC and move forward//RE: WGLC -
> draft-ietf-spri
On 2/3/20 11:16, bruno.decra...@orange.com wrote:
[...]
The summary provides by the Working Group Chair states that the
Responsible Area Director "has not accepted the related errata". I
took a quick look at erratum eid5933; it is listed as "Reported". As
the erratum has not been classified as
Hi all,
Based on the email below and the received feedback we have published a new
revision of draft-ietf-spring-srv6-network-programming.
This new version only introduces changes in the PSP section. Those changes are
editorial changes destined to simplify the reading of the aforementioned
sect
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the
IETF.
Title : SRv6 Network Programming
Authors : Clarence Filsfils
Pablo Cam
Dear Mr Decraene,
At 04:48 AM 02-03-2020, bruno.decra...@orange.com wrote:
I would suggest that next time you want the communication to be
public, you start it on the public mailing list, so that the whole
WG is aware of the whole thread.
(Note that this would not change the text in my email)
Hello, Bruno,
On 2/3/20 10:19, bruno.decra...@orange.com wrote:
[]
===
A) PSP [1] & RFC 8200 [2]
===
This point is whether SRH removal by the penultimate SR end point
(aka PSP) is allowed by RFC 8200.
More specifically
" S14.4.Remove the SRH from the IPv6 extensi
Dear Rakesh,
my apologies for the belated response and comments that you can find below:
- as I understand, the draft is applicable to TWAMP Light mode,
mentioned in the informational Appendix I in RFC 5357, not the TWAMP
protocol itself. Since TWAMP Light is not a standard but its idea i
Hi Tianran,
using node based information like added by IOAM is another valid option. The
method I propose is to stay at forwarding layer and work without node support.
That way forwarding issues are detected, even if the control plane isn’t aware
of it. Also that happens.
Active measurements a
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
Hi Haoyu,
thanks for your remarks. Let me pick up your numbering
1. IOAM information could be added by a passed router, if there's interest.
The draft doesn't exclude that. But that's not in focus either. I didn't make
up my mind, whether and which IOAM information may add value to such
me
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
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
>
> As far as I can tell, most of your email below is fair and well taken.
> I appreciate your efforts Bruno.
Thank you Joel.
> However, I have to disagree with your description of what it takes to
> decide to keep in or remove a "feature
Andrew,
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Andrew Alston
Sent: Monday, March 2, 2020 8:07 AM
To: Joel M. Halpern; Robert Raszuk
Cc: SPRING WG
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
(off-topic)
The usual practice when a hair o-authors a doc
Dear S. Moonesamy,
Please see and read inline
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of S Moonesamy
> Sent: Friday, February 28, 2020 11:03 PM
> To: Martin Vigoureux
> Cc: spring@ietf.org
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
> Dear Mr
S. Moonesamy,
Please see inline
>
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of S Moonesamy
> Sent: Sunday, March 1, 2020 9:36 PM
> To: Andrew Alston; i...@ietf.org
> Cc: spring@ietf.org; Martin Vigoureux
> Subject: Re: [spring] WGLC - draft-ietf-spri
+1.
Not to make a decision, but to agree with Bruno. Many thanks for your
information, very useful to me :)
Best Regards,
Cheng
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Monday, March 2, 2020 8:49 PM
To: S Moonesamy
> [under Suresh's control that I'm explicitly adding in copy]
Sorry Suresh, I meant :s/that/who
My primary excuse is that English is not my first language. Still, my mistake.
--Bruno
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Dear Mr S. Moonesamy,
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of S Moonesamy
> Sent: Friday, February 28, 2020 11:03 PM
> To: Martin Vigoureux
> Cc: spring@ietf.org
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
> Dear M
As far as I can tell, most of your email below is fair and well taken.
I appreciate your efforts Bruno.
However, I have to disagree with your description of what it takes to
decide to keep in or remove a "feature". You assert that an
implementation having been done and a claimed use is enough
Sander,
> From: Sander Steffann [mailto:san...@steffann.nl]
> Sent: Friday, February 28, 2020 8:51 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: SPRING WG List; draft-ietf-spring-srv6-network-programming; 6man WG
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
> > ===
Fernando,
> -Original Message-
> From: Fernando Gont [mailto:ferna...@gont.com.ar]
> Sent: Friday, February 28, 2020 8:28 PM
> To: DECRAENE Bruno TGI/OLN; 'SPRING WG List'
> Cc: draft-ietf-spring-srv6-network-programming; rtg-ads
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-netwo
Dear S Moonesamy,
Speaking as an individual contributor, please find below a few comments
1) The below email was a private email between a set of persons.
Forwarding it, to a public list without permission is frown upon by the
Netiquette (if not savoir-vivre, to begin with)
"If the message was
Hi,
I think this work is very interesting and could serve a very broad use case
as mentioned by others in this thread as well.
For example I would like to see, and offer to help out write those, the
working of NETWORK_LATENCY in combination with ADD-PATH.
This particular example would offer a dow
Hi Al,
the draft explains the “or” in section “2. A brief segment routing
connectivity monitoring framework” (the last bullet point list at the end of
the section).
Segment Routing allows to concatenate Tranport Labels, which carry routing
information following SPF. A loss in connectivity is
> On 28 Feb 2020, at 01:51, Brian E Carpenter
> wrote:
>
> Pablo,
>
> I have been looking at the latest version. See my previous note to Stefano
> Salsano. I really think that the problem here is that certain things are
> obvious to SRH experts but not to others, and they simply need more
>
70 matches
Mail list logo
