Joel,
> On 10 Oct 2022, at 15:36, Joel Halpern wrote:
>
> Eric, you seem to be objecting to something I did not say. I have not asked,
> and do not expect, for the document to mandate or even suggest that arbitrary
> domains should drop packets with SRH. I will note that given that SRH is
>
Tom,
> Yes I am with you here.
>
> However let's observe that this is pretty common best practice to disable any
> hardware offload on the box when running tcpdump or wireshark.
>
> In fact some implementations (F5) do it for you automagically :)
>
> And as it has been said based on the fac
> On 25 May 2020, at 17:49, Ron Bonica wrote:
>
> Ole,
>
> When commenting on list, could you indicate whether hats are on or off?
And that is important to you for this particular message because?
> Juniper Business Use Only
Ole
> -Original Message-
> From: otr...@employees.org
> On 9 Oct 2021, at 22:02, Brian E Carpenter
> wrote:
>
> It is mandated by the current IPv6 addressing architecture. Despite many
> discussions, there has never been consensus to change it. So if /64 is not
> the boundary between the routeable part and the host-specific part, it's not
> IP
Ron,
>
>
> Folks,
>
> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
> define a set of SIDs that have the following things in common:
>
> - they are consumed by the egress node (SL == 0)
> - they tell the egress node how to forward the payload into a VPN
>
> If th
> Ron
>
>
>
> Non-Juniper
>
>> -Original Message-
>> From: Ole Troan
>> Sent: Wednesday, May 8, 2019 2:14 PM
>> To: Ron Bonica
>> Cc: Bob Hinden ; Tom Herbert
>> ; SPRING WG
Sander,
>
> The next-header should identify what follows, so that anybody parsing the
> packets knows what to expect. Using "No Next Header" should mean "nothing
> follows". Once we start using No-next-header for "some stuff may follow" it
> will become very hard to make sense of packets. Over
mation signalled separately?
Cheers,
Ole
>
> Ron
>
>
>
> Juniper Internal
>
>> -----Original Message-
>> From: Ole Troan
>> Sent: Wednesday, May 8, 2019 3:33 PM
>> To: Ron Bonica
>&
> On 9 May 2019, at 11:05, Stewart Bryant wrote:
>
>
>
>> On 08/05/2019 19:13, Ole Troan wrote:
>> Ron,
>>>
>>>
>>> Folks,
>>>
>>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
>>>
>>> I suspect that we will be far more likely regret this use of 59 in the long
>>> term than we will regret changing to 97 at this early stage.
>> But it’s not that nh=59 can be used to imply that Ethernet follows. That
>> would be very bad.
>> It’s that ip processing stops here.
>> Then if the
> I think it is equally important to note that given an existing way of
> encapsulating Ethernet in IP, one ought to have a good reason for creating a
> different one. There is no indication that this use case needs anything
> different than next-header 97.
>
> And Ole, no next-header does not
is an extension point. If people found some use for that, what's the harm?
That middle boxes get confused? Isn't that a feature? ;-)
Cheers,
Ole
>
> Yours,
> Joel
>
> On 5/9/19 8:36 AM, Ole Troan wrote:
>>> I think it is equally important to note that given an ex
> End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will
> insert a new SRH in the received IPv6 packet, which results in two SRHs in
> one IPv6 packet. It is contradict with RFC8200 that says Each extension
> header should occur at most once, except for the Destination Op
Fernando,
>>> Since there have been plenty of attempts to do EH insertion or
>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>> had consensus that EH insertion is not allowed, I think it would be
>>> bad, wastefull, tricky, and even dangerous to let a document go
>>> throu
t;
> Ron
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Ole Troan
> Sent: Wednesday, September 4, 2019 2:58 AM
> To: Fernando Gont
> Cc: Suresh Kri
rnando Gont wrote:
>
> On 4/9/19 09:58, Ole Troan wrote:
>> Fernando,
>>
>>>>> Since there have been plenty of attempts to do EH insertion or
>>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>>> had consensus that E
Fernando,
>> The IETF is not writing de jure standards.
>> In fact reality is quite different, and the Internet evolves the way it does
>> somewhat independently of what documents the IETF produces.
>> In fact I know of no networking products (or deployments) that follow the
>> intent and spirit
Joel,
> Part of the reason we write restrictions and requirements into RFCs is so
> that we do not have to repeat the arguments.
>
> If the proponents of the insertion have arguments for why it is now okay,
> they need to make those arguments. And they need to make sure that the
> discussion
> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>
> We have wasted way too much time and energy with all the methafores and
> curious interpretations of standards by folks pushing and/or supporting
> EH insertion, really.
Pot calling kettle black?
This is an issue we all know is there. And h
Fernando,
> On 5 Sep 2019, at 21:54, Fernando Gont wrote:
>
> On 5/9/19 22:30, Ole Troan wrote:
>>
>>
>>>> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>>>
>>> We have wasted way too much time and energy with all the methafores an
>
>
>
>> I think you have repeatedly made your point.
>
> Yes he has, and he makes a good point that should be heard. Your argument of
> "RFCs aren't the law, and we can ignore parts of them if it suits us" just
> isn't true. RFCs are based on consensus, and ignoring the outcome of that
> co
>> I don’t see a need to continue this debate on meta issues, but since you
>> framed this as criticism of me in the chair role I found it required to
>> reply.
>
> I expect the chair to uphold a previously reached consensus and put the
> requirement of justifying deviating from it with the o
Fernando,
>> The takeaway I attempted to highlight is that there is in fact agreement
>> between 6man and spring on how to proceed, and we are proceeding as
>> agreed to work on the relevant documents.
>
> I don't really know what the agreement is, other than the implicit
> agreement that if you'
Hello,
As agreed in the working group session in Singapore, this message starts a
new two week 6MAN Working Group Last Call on advancing:
Title: Operations, Administration, and Maintenance (OAM) in Segment
Routing Networks with IPv6 Data plane (SRv6)
Author : Z. Ali, C. Filsfils, S.
> 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
25 matches
Mail list logo
