(responding on spring mailing list)
Hi Fernando,
On Dec 7, 2019, at 11:07 AM, Fernando Gont
mailto:fg...@si6networks.com>> wrote:
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:
[...]
(Apologies up front. I am about to get on a 10 hr flight and will be unable to
respond for at least that period)
Hi all,
Picking the last message in the thread to reply to. It looks to me that there
are at least two different (but related) issues being discussed here
a) Spring SRv6 NP
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,
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.
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
> * 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
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
A new Request for Comments is now available in online RFC libraries.
RFC 8670
Title: BGP Prefix Segment in Large-Scale
Data Centers
Author: C. Filsfils, Ed.,
S. Previdi,
G. Dawra,
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
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
>> I have observed, in your original post, the conflation of SRH insertion
>> within an SR Domain with the PSP behavior defined in network programming.
>> Whether this was intentional or not, I do not know.
>> Regardless, it is wrong.
Darren,
We clearly disagree. RFC 8200 addresses extension
> 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
A new Request for Comments is now available in online RFC libraries.
RFC 8661
Title: Segment Routing MPLS Interworking with
LDP
Author: A. Bashandy, Ed.,
C. Filsfils, Ed.,
S. Previdi,
A new Request for Comments is now available in online RFC libraries.
RFC 8660
Title: Segment Routing with the MPLS Data Plane
Author: A. Bashandy, Ed.,
C. Filsfils, Ed.,
S. Previdi,
B.
Hi Ron. I am trying to be precise in my posts. Please do not interpret them as
dismissive.
I have observed, in your original post, the conflation of SRH insertion within
an SR Domain with the PSP behavior defined in network programming.
Whether this was intentional or not, I do not know.
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.
>
Ole,
In that case, peace!
Ron
Juniper Business Use Only
-Original Message-
From: otr...@employees.org
Sent: Friday, December 6, 2019 3:17 PM
To: Ron Bonica
Cc: Andrew Alston ; Tom Herbert
; SPRING WG ; 6man <6...@ietf.org>;
int-...@ietf.org; Bob
Hi Ron,
> I am not quite sure how to take this email. Are you suggesting that we should
> review less, post less, and let the rubber stamping begin?
No, not at all. And if it was open for that interpretation I am sorry.
But there are a should's all of us could improve on.
- not repeat the same
Thank you, you too!
On Fri, Dec 6, 2019, 21:16 Zafar Ali (zali) wrote:
> Hi Tadas,
>
>
>
> Many thanks for sharing the SRv6 deployment in a nationwide backbone
> network!
>
>
>
> It will be our pleasure to include the text provided by you in the next
> revision of the SRv6 deployment draft.
>
>
So you have a bunch of people who have actively read and participated in the
process – in order to ensure that was emerges from the IETF are documents that
are satisfactory and do not violate other drafts and impose things on operators
that some operators find unacceptable?
I would believe
Ole,
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.
Andrew
From: spring on behalf of
Hi Tadas,
Many thanks for sharing the SRv6 deployment in a nationwide backbone network!
It will be our pleasure to include the text provided by you in the next
revision of the SRv6 deployment draft.
We can publish it during the next week.
Have a great weekend!
Thanks
Regards … Zafar
From:
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
On 6/12/19 05:15, Andrew Alston wrote:
> In addition to the below,
>
>
>
> In Section 2:
>
>
>
> In this version of the document, we assume that there are no other
>
> extension headers than the SRH. These will be lifted in future
>
> versions of the document.
Can the authors
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
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
On 6/12/19 12:14, Sander Steffann wrote:
> Hi,
>
>> 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
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
Authors,
When an SRv6 node sends an ICMP message, how does it select the ICMP message's
source address?
Section 2.2 of RFC 4443 offers two options. If you think that a SID is a
unicast address, the first option is applicable. If you think that a SID is not
a unicast address, the second option
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
Authors,
>From which of the IPv6 Special Purpose Address ranges (see RFC 6890, Section
>2.2.3) can a locator be drawn? In some cases, it is obvious, but in others, it
>is not.
Ron
Juniper Business Use Only
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
Darren,
If the draft adhered strictly to RFC 4291 and RFC 8200 in all other respects, I
would agree with you and Bob. However, it doesn't.
As it stands, the reader is left to guess when the draft adheres to previous
specifications, but doesn't say so explicitly, and when it is taking liberties
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
Hi,
Thanks to the authors for the work on this draft. I've done a review
which is the first time I have looked at the draft for several
revisions. My thoughts are included below.
I think that considerable editorial work is needed before we can claim
that this document is ready for
Hi Ron, I agree with Bob here.
Section 4.2 pseudocode simply says an implementation would use a predetermined
egress adjacency instead of performing a FIB lookup to find one.
It specifies the SID processing, not the entire IPv6 data path.
It has no text that would indicate RFC4291 text on
Hi Shuping,
Thank you for taking the minutes.
Please find enclosed a proposed update (with diff highlighted).
Nothing that significant, but sending on the list with diff for transparency.
Regards,
Bruno
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pengshuping (Peng
Hi,
> 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.
I think there are plenty of
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 --
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
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,
In addition to the below,
In Section 2:
In this version of the document, we assume that there are no other
extension headers than the SRH. These will be lifted in future
versions of the document.
If the document is going to last call – what future versions and are plans to
lift these
Hi Zefar, Satoru,
In the next draft of
https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/,
we'd like to be added to the section “2. Deployment Status” as we have
significant progress on our SRv6 deployment:
*NOIA Network (https://noia.network
46 matches
Mail list logo
