Fernando,
> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont
> Sent: Saturday, December 7, 2019 2:10 AM
>
> On 6/12/19 20:55, otr...@employees.org wrote:
> >> * polling the mailing list instead of deciding (on your own) that the
> >> group wants to work on EH insertion, and,
On 08-Dec-19 00:47, Robert Raszuk wrote:
> Besides the pseudocode says it black and white "S14.1. If (updated SL == 0)
As I already pointed out, "updated SL" is undefined in the text and may in fact
simply mean "Segments Left" after executing S14. Pseudocode really should be
unambiguous.
On 7/12/19 12:57, Darren Dukes (ddukes) wrote:
> Hi Robert, thank you for injecting clarity to this thread.
>
> draft-ietf-spring-network-programming defines PSP, and the only relevant
> portion of this thread to that draft is Discussion #3.
>
> As I stated in another post, I consider #3 closed a
On 7/12/19 13:03, Robert Raszuk wrote:
>
> Exactly - That is why I thought it does make sense to make this crystal
> clear to everyone here.
>
> From some comments it seemed that either folks do not understand or want
> on purpose to make false assertions only to mud the waters :)
FWIW, I wil
Exactly - That is why I thought it does make sense to make this crystal
clear to everyone here.
>From some comments it seemed that either folks do not understand or want on
purpose to make false assertions only to mud the waters :)
All - have a great weekend,
Robert.
On Sat, Dec 7, 2019 at 4:
Hi Robert, thank you for injecting clarity to this thread.
draft-ietf-spring-network-programming defines PSP, and the only relevant
portion of this thread to that draft is Discussion #3.
As I stated in another post, I consider #3 closed as this is clearly complying
with RFC8200.
https://mailarc
Le 06/12/2019 à 17:21, Sander Steffann a écrit :
Hi Robert,
To your specific first question this is very popular deployment
model ... just look at SDWANs. So Internet is just a L3 transport
for all routers in your administrative domain or global WAN. Spot
on. I do sincerely hope that whate
Hey Fernando,
(pop when you are the destination but SL!=0 is essentially 'in the
> network removal')
I was trying to stay out of this but I have one fundamental question or
observation this entire debate seems to be about.
In the context of SRv6 there are two parallel discussions
*Discussion #
On 6/12/19 23:47, Brian E Carpenter wrote:
> Again, comment at the end...
> On 07-Dec-19 14:37, Fernando Gont wrote:
>> On 6/12/19 22:15, Brian E Carpenter wrote:
>> [...]
>>>
and if such a thing is required, an update to RFC8200 should be done.
>>>
>>> Why does that follow? Alternatively,
>>
Again, comment at the end...
On 07-Dec-19 14:37, Fernando Gont wrote:
> On 6/12/19 22:15, Brian E Carpenter wrote:
> [...]
>>
>>> and if such a thing is required, an update to RFC8200 should be done.
>>
>> Why does that follow? Alternatively,
>> draft-ietf-spring-srv6-network-programming could ack
On 6/12/19 22:15, Brian E Carpenter wrote:
[...]
>
>> and if such a thing is required, an update to RFC8200 should be done.
>
> Why does that follow? Alternatively,
> draft-ietf-spring-srv6-network-programming could acknowledge that it deviates
> from RFC8200.
You can deviate from s "should",
On 6/12/19 20:55, otr...@employees.org wrote:
>> * polling the mailing list instead of deciding (on your own) that the
>> group wants to work on EH insertion, and,
>
> Which decision are you referring to?
> I have certainly never decided that working group wants to work on header
> insertion.
Th
Andrew,
I am a bit confused (not unusual). Can you get back to basics on my questions
below?
On 07-Dec-19 11:23, Andrew Alston wrote:
> Ole - so - let me understand something.
>
> The definition of consensus - among other things - say that all outstanding
> objections have been addressed (thou
> * polling the mailing list instead of deciding (on your own) that the
> group wants to work on EH insertion, and,
Which decision are you referring to?
I have certainly never decided that working group wants to work on header
insertion.
With regards to the documents, I believe I clarified the s
On 6/12/19 19:02, Ole Troan wrote:
>
>
>> On 6 Dec 2019, at 22:09, Fernando Gont wrote:
>>
>> I don't think there is much room for interpretation here, but anyway I
>> should ask: are you suggesting that I have attacked or been attacking
>> the process?
>
> I would rather say taking advantage o
Ole - so - let me understand something.
The definition of consensus - among other things - say that all outstanding
objections have been addressed (though not potentially resolved). When you
have multiple people saying - a draft violates RFC8200 and that is a concern -
and if such a thing is r
Hi Ole,
>> I don't think there is much room for interpretation here, but anyway I
>> should ask: are you suggesting that I have attacked or been attacking
>> the process?
>
> I would rather say taking advantage of the process.
>
> By reiterating the same assertive arguments again and again you c
> On 6 Dec 2019, at 22:09, Fernando Gont wrote:
>
> I don't think there is much room for interpretation here, but anyway I
> should ask: are you suggesting that I have attacked or been attacking
> the process?
I would rather say taking advantage of the process.
By reiterating the same assert
On 6/12/19 16:42, otr...@employees.org wrote:
>
>> While I may agree with you that is an attack on process here – and you may
>> even find consensus on that statement – I am far from convinced you would
>> find consensus on the question of which group is conducting the attack on
>> process.
>
g; Bob Hinden ; rtg-ads
; Fernando Gont
Subject: Re: [spring] We don't seem to be following our processes (Re: Network
Programming - Penultimate Segment Popping)
Hi Ron,
> I am not quite sure how to take this email. Are you suggesting that we should
> review less, post less, and let th
ston
> Cc: Tom Herbert ; Ron Bonica ;
> SPRING WG ; 6man <6...@ietf.org>; int-...@ietf.org; Bob
> Hinden ; rtg-ads ; Fernando
> Gont
> Subject: Re: [spring] We don't seem to be following our processes (Re:
> Network Programming - Penultimate Segment Popping)
>
&
: Andrew Alston
Cc: Tom Herbert ; Ron Bonica ;
SPRING WG ; 6man <6...@ietf.org>; int-...@ietf.org; Bob Hinden
; rtg-ads ; Fernando Gont
Subject: Re: [spring] We don't seem to be following our processes (Re: Network
Programming - Penultimate Segment Popping)
> While I may agree wi
Ron Bonica
, SPRING WG , 6man
<6...@ietf.org>, "int-...@ietf.org" , Bob Hinden
, rtg-ads , Fernando Gont
Subject: Re: [spring] We don't seem to be following our processes (Re: Network
Programming - Penultimate Segment Popping)
> While I may agree with you that is an attack on
> While I may agree with you that is an attack on process here – and you may
> even find consensus on that statement – I am far from convinced you would
> find consensus on the question of which group is conducting the attack on
> process.
From https://mailarchive.ietf.org/arch/browse/ipv6/?qd
s.org"
Date: Friday, 6 December 2019 at 22:14
To: Tom Herbert
Cc: Ron Bonica , SPRING WG
, 6man <6...@ietf.org>, "int-...@ietf.org" ,
Bob Hinden , rtg-ads , Fernando
Gont
Subject: Re: [spring] We don't seem to be following our processes (Re: Network
Programming - Pe
Tom,
> Bear in mind that quality discussion is real work by those
> participating. It is a lot of effort to carefully read drafts, give
> clear feedback, and respond to rebuttals. I would like to think that
> the work individuals put in is justified by the outcome, and I assume
> it the chairs pre
On Fri, Dec 6, 2019 at 9:06 AM wrote:
>
> Tom,
>
> > The advice from the chairs seems to be continue discussion. The
> > problem with that is that EH insertion has been discussed ad nauseum
> > over the past two years since the draft first appeared. It seems like
> > we are at the point where the
Bob,
[]
>> Bob,
>>
>> The advice from the chairs seems to be continue discussion. The
>> problem with that is that EH insertion has been discussed ad nauseum
>> over the past two years since the draft first appeared. It seems like
>> we are at the point where the same arguments on the topic are
Tom,
> The advice from the chairs seems to be continue discussion. The
> problem with that is that EH insertion has been discussed ad nauseum
> over the past two years since the draft first appeared. It seems like
> we are at the point where the same arguments on the topic are just
> being rehashe
Ole,
Let me highlight a few things before getting into specific comments.
1) The IETF has no consensus about the concept of "limited domains" that
you are referring to. That means that there are no nuances in this
respect: a document that violates RFC8200, violates RFC8200. And if
there is no con
Hi Tom,
> On Dec 6, 2019, at 7:58 AM, Tom Herbert wrote:
>
> On Thu, Dec 5, 2019 at 4:30 PM Bob Hinden wrote:
>>
>> Hi,
>>
>>> On Dec 5, 2019, at 16:20, Ron Bonica
>>> wrote:
>>>
>>> Enno,
>>>
>>> That is how I parse Ole's message. But we can let Ole speak for himself.
>>
>> To clarify,
Hi,
Inline.
On Fri, Dec 6, 2019 at 5:21 PM Sander Steffann wrote:
> Hi Robert,
>
> > To your specific first question this is very popular deployment model ..
> just look at SDWANs. So Internet is just a L3 transport for all routers in
> your administrative domain or global WAN. Spot on. I do si
Hi Robert,
> To your specific first question this is very popular deployment model ...
> just look at SDWANs. So Internet is just a L3 transport for all routers in
> your administrative domain or global WAN. Spot on. I do sincerely hope that
> whatever the result be of this debate all features
Hi Sander,
To your specific first question this is very popular deployment model ..
just look at SDWANs. So Internet is just a L3 transport for all routers in
your administrative domain or global WAN. Spot on. I do sincerely hope that
whatever the result be of this debate all features will be lega
On Thu, Dec 5, 2019 at 4:30 PM Bob Hinden wrote:
>
> Hi,
>
> > On Dec 5, 2019, at 16:20, Ron Bonica
> > wrote:
> >
> > Enno,
> >
> > That is how I parse Ole's message. But we can let Ole speak for himself.
>
> To clarify, the current consensus is the text in RFC8200.
>
> There is discussion ong
Hi Ole,
> If I own and manage three routers, R1 -- R2 -- R3.
> You are saying that if R1 sends a packet to R3, it is not allowed to off-load
> some functions to R2?
> Going to be difficult to do stuff like service chaining then.
This bit I don't mind that much, but what about:
R1 -- R2 -- [open
Ole, there is no IETF accepted definition of "limited domain".
There is no IETF rough consensus that it is sensible for us to
standardize things for "limtied domains".
While there are standards that are designed for specific deployments,
they do not to date use that as an excuse to violate exist
Enno,
>>> comply with it. The onus is on them, not on us asking folks to comply
>>> with existing standards.
>>
>> Yes, we have heard your position on this now.
>> There is of course a lot more nuance to this argument.
>
> could you please explain said 'nuance' in more detail?
I could try, alth
Hello, Bob,
On 5/12/19 21:29, Bob Hinden wrote:
> Hi,
>
>> On Dec 5, 2019, at 16:20, Ron Bonica
>> wrote:
>>
>> Enno,
>>
>> That is how I parse Ole's message. But we can let Ole speak for himself.
>
> To clarify, the current consensus is the text in RFC8200.
>
> There is discussion ongoin
Hi,
> On Dec 5, 2019, at 16:20, Ron Bonica
> wrote:
>
> Enno,
>
> That is how I parse Ole's message. But we can let Ole speak for himself.
To clarify, the current consensus is the text in RFC8200.
There is discussion ongoing in 6man on this topic, but it is impossible to say
how that wi
Enno,
That is how I parse Ole's message. But we can let Ole speak for himself.
Ron
Juniper Business Use Only
-Original Message-
From: Enno Rey
Sent: Thursday, December 5, 2019 5:48 PM
To: Ron Bonica
Cc: otr...@employees.org; Fernando Gont
Hi Ron,
On Thu, Dec 05, 2019 at 10:08:53PM +, Ron Bonica wrote:
> Peace Gentlemen,
>
> For the purpose of this thread, I think that we have all of the information
> that we need. Consensus regarding header insertion and removal is "evolving".
not meaning to nitpick and admittedly I'm not s
Hi Ole,
On Thu, Dec 05, 2019 at 11:01:08PM +0100, otr...@employees.org wrote:
> > comply with it. The onus is on them, not on us asking folks to comply
> > with existing standards.
>
> Yes, we have heard your position on this now.
> There is of course a lot more nuance to this argument.
could y
Ole,
On 5/12/19 19:01, otr...@employees.org wrote:
[...]
>>
>> I don't. Again: unless folks get consensus to update RFC8200, thy should
>> comply with it. The onus is on them, not on us asking folks to comply
>> with existing standards.
>
> Yes, we have heard your position on this now.
> There is
Peace Gentlemen,
For the purpose of this thread, I think that we have all of the information
that we need. Consensus regarding header insertion and removal is "evolving".
We need to let that evolution progress, and not make any assumptions regarding
its outcome.
On Thu, Dec 5, 2019 at 1:41 PM wrote:
>
> Fernando,
>
> >>> Point taken. Could you comment on the current state of WG consensus?
> >>
> >> The working group session in Singapore ended with what appeared to be a
> >> view that we should continue work on both documents (Mark's and the Voyer
> >> d
>>> I would say that it seems we have not been following the processes that
>>> should be followed. This has happened repeatedly over time, for this
>>> very same topic. The process seems to be biased, and thus unfair to the
>>> rest of the wg participants.
>>
>> Which process are you talking abou
On 5/12/19 18:41, otr...@employees.org wrote:
> Fernando,
>
Point taken. Could you comment on the current state of WG consensus?
>>>
>>> The working group session in Singapore ended with what appeared to be a
>>> view that we should continue work on both documents (Mark's and the Voyer
>>>
Fernando,
>>> Point taken. Could you comment on the current state of WG consensus?
>>
>> The working group session in Singapore ended with what appeared to be a view
>> that we should continue work on both documents (Mark's and the Voyer draft).
>> For the state of the wg consensus, I haven't ch
Ole,
On 5/12/19 18:16, otr...@employees.org wrote:
> Ron,
>
>> Point taken. Could you comment on the current state of WG consensus?
>
> The working group session in Singapore ended with what appeared to be a view
> that we should continue work on both documents (Mark's and the Voyer draft).
> F
50 matches
Mail list logo
