On Wed, Jul 3, 2024 at 9:35 AM Bob Hinden wrote:
>
> Alvaro, Spring Chairs,
>
> The 6MAN chairs have reviewed the discussion on your query to the IPv6 list.
> This is our thoughts.
>
> Process wise we don’t think we can declare any kind of formal consensus on
> this. We are sure you have als
u
send". For the past thirty years the checksum has always been sent to
be correct on the wire unless there's a routing header, so changing
that behavior would be a violation of the robustness principle.
Tom
Tom
>
> Thx,
> R.
>
>
> On Thu, Jun 13, 2024 at 6:54 PM Tom
On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk wrote:
>
> All,
>
> As far as I recall during IPv6 discussions a notion of end-to-end principle
> of Internet design was treated as paramount. Number of decisions made in
> shaping IPv6 encoding were derived from this.
>
> One of those is checksum wh
On Thu, Jun 13, 2024 at 1:12 AM Andrew Alston - IETF wrote:
> Hi All,
>
>
>
> As I have repeatedly stated in spring and will state so again here. In
> certain circumstances the use of C-SID breaks the checksums as relates to
> transit nodes. RFC8200 lays out specific processing rules for upper
On Mon, Jun 3, 2024 at 5:00 AM Alvaro Retana wrote:
>
> Dear 6man WG:
>
> As you may be aware, the spring WG is in the process of advancing
> draft-ietf-spring-srv6-srh-compression [1]. The WGLC discussions have
> resulted in the need to ask you the following questions (see below)
> related to the
On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT wrote:
> Hello,
>
> After reading RFC 8754 and RFC 8986 together with the draft (version 14),
> it seems to me that the cases when the SRH will be omitted are quite
> limited, and will happen among nodes sharing the same locator block. We can
> as
d the processing of routing headers is well specified. If they ignore the
RH and try to verify checksum based an intermediate address then it won't
work-- that's expected behavior. So when RH is present, everyone knows how
L4 checksum works.
Tom
> On Thu, Apr 4, 2024 at 10:57 PM Tom H
scribing their
> perceived issue in random thread. My gently hint for the chairs would be to
> log issues in github and have more structured processing them there.
>
>
>
> On Thu, Apr 4, 2024 at 9:50 PM Tom Herbert wrote:
>
>>
>>
>> On Thu, Apr 4, 2024, 3:37
th IPv6 we can also
> do a checksum neutral mapping. Basically, this uses the low order 16 bits
> in the DA address as the checksum adjustment value. For instance, if we can
> use the low order bits in a SID block then that would be simplest to
> implement.
>
> Tom
>
>
>>
For instance, if we can
use the low order bits in a SID block then that would be simplest to
implement.
Tom
> If anything just do encap and move on.
>
> Thx,
> R.
>
>
> On Thu, Apr 4, 2024 at 7:06 PM Tom Herbert wrote:
>
>>
>>
>> On Thu, Apr 4, 2024,
> Can’t be the only example where a device in the middle cannot snoop
> traffic between endpoints…
>
For plain TCP/IPv6 packets? I'm not so sure...
Tom
> Cheers,
> Ole
>
>
> >
> > Tom
> >
> >
> > Cheers,
> > R.
> >
> &g
On Thu, Apr 4, 2024, 1:08 PM Michael Richardson
wrote:
>
> Tom Herbert wrote:
> >> Tcpdump can determine that this packet is steered onto an SRv6 path
> by
> >> checking if the DA matches the SRv6 SID block.
>
> > That would require introducing e
;d
need to change the implementation to ensure the checksum is not computed by
HW.
If SR without SRH is needed, then I believe the best answer is for SR aware
routers to update L4 checksum when they change DA per NAT requirements.
This solves tcpdump as well as offloads.
Tom
> Cheers,
> R
This would be a major divergence in both implementation and ops
compared to how things work today.
Tom
> Thanks,
> Francois
>
> On 4 Apr 2024 at 16:59:59, Tom Herbert wrote:
>
>>
>>
>> On Thu, Apr 4, 2024, 9:39 AM Francois Clad wrote:
>>
>>> Hi Ma
On Thu, Apr 4, 2024, 9:39 AM Francois Clad wrote:
> Hi Mark,
>
> Tcpdump/wireshark decodes the IPv6 header just fine. I do not see any
> issue here.
>
Francois,
The problem is that tcpdump can't tell that a packet is an SR packet if
there's no SRH. For instance, if the checksum is not maintaine
andate a zero checksum in
UDPv6 tunneling, this is a deployment time consideration. For example,
see RFC8086; it took three pages to describe how the zero checksum can
safely be set in GRE/UDP.
Tom
>
> Even Andrew agreed with that :)
>
> Cheers,
> Robert
>
> On Thu, Mar 28, 202
perator who enables SRv6 in
> the first place sees those checksum errors how difficult is to address it ?
>
> Thx,
> Robert
>
>
> On Thu, Mar 28, 2024 at 3:29 PM Tom Herbert wrote:
>>
>> On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk wrote:
>> >
>> &
On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk wrote:
>
> Hi Alvaro,
>
> On this specific topic I think you have flatted it a bit too much.
>
> These are apparently the options on the table:
>
> A) Original packet get's encapsulated with IPv6 header
>
> A.1 SHR is added to it
>
>
> From: Alexander Vainshtein
> Sent: Tuesday, March 26, 2024 4:24 PM
> To: Ron Bonica
> Cc: spring@ietf.org ; Andrew Alston - IETF
> ; Robert Raszuk ; Tom Herbert
> ; Alvaro Retana
> Subject: Re: [spring] Chair Review of
> draft-ietf-sprin
infeasible. I believe the best answer is to always require an SRH, and
otherwise maintain compliance with IPv6 standard.
Tom
>
> Ron
>
> Juniper Business Use Only
>
>
> From: Tom Her
> Thanks!
>
> Alvaro.
>
>
> On March 25, 2024 at 2:58:48 PM, Tom Herbert (t...@herbertland.com) wrote:
>
> On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana wrote:
> >
> > FWIW, I agree with most of what Joel wrote. ;-)
> >
> > I see another path forward:
somehow, and
> presumably approved by 6man. related to that, any intermediate node looking
> at the packet will see an apparently ordinary IPv6 packet whose upper layer
> checksum is incorrect.
>
> Tom Herbert, if I am understanding him correctly, is arguing that since the
>
be a clear MUST NOT in the draft
to resolve the issue.
Tom
>
> Many thx,
> R.
>
>
> On Mon, Mar 25, 2024 at 5:57 PM Tom Herbert wrote:
>>
>> On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk wrote:
>> >
>> >
>> > Actually looking at this from t
On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk wrote:
>
>
> Actually looking at this from the perspective where SRH may be omitted I see
> in the subject draft this clearly stated:
>
> A source node steers a packet into an SR Policy. If the SR Policy results in
> a Segment List containing a singl
21 PM Andrew Alston - IETF
>> wrote:
>>
>> Robert,
>>
>>
>>
>> By RFC8200 Section 8.1 Second paragraph of Page 28 –
>>
>>
>>
>> “Ipv6 receiveers must discard UDP packets containing a zero checksum and
>> should log the error”
Tom
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
> Internal All Employees
>
> From: Robert Raszuk
> Date: Monday, 25 March 2024 at 18:16
> To: Tom Herbert
> Cc: Andrew Alston - IETF , Ron Bonica
> , spring@ietf.org
> Subje
Hi,
I believe there are requirements in
draft-ietf-spring-srv6-srh-compression that would allow a compressed
SID to be placed in the IPv6 Destination Address without an SRH being
in the packet where the DA is modified at each hop following the
procedures of the draft. This proposal would have rami
On Thu, Oct 26, 2023 at 2:23 AM wrote:
>
> with Yao2>>
>
> Original
> From: TomHerbert
> To: 刘尧00165286;
> Cc: i...@ietf.org ;spring@ietf.org ;
> Date: 2023年10月25日 23:15
> Subject: Re: [IPv6] Fw: New Version Notification for
> draft-liu-6man-max-header-size-00.txt
>
> >
> > Hi Yao,
> >
> > I've
On Wed, Oct 25, 2023 at 12:59 AM wrote:
>
> Hi Tom,
>
> Thanks for your thoughts.
>
> In line with Yao>>
>
>
> Original
> From: TomHerbert
> To: 刘尧00165286;
> Cc: i...@ietf.org ;spring@ietf.org ;
> Date: 2023年10月24日 23:30
> Subject: Re: [IPv6] Fw: New Version Notification for
> draft-liu-6man-ma
On Mon, Oct 23, 2023 at 6:02 AM wrote:
>
> Hi Tom，
>
> In line with [Yao3].
Hi Yao,
I've be thinking how to generalize this. Would it make sense to add
>
>
> Thanks,
>
> Yao
>
>
> Original
> From: TomHerbert
> To: 刘尧00165286;
> Cc: i...@ietf.org ;spring@ietf.org ;
> Date: 2023年10月23日 06:06
> Su
but they are not sufficient.", if you want to
> make that argument then please reference RFC8883 and
> draft-ietf-6man-eh-limits and describe why they're not sufficient.
>
> * I know that your primary motivation for this draft is segment
> routing, but extension header l
ively use extension headers in environments where
intermediate nodes may enforce limits.
Tom
>
>
> Thanks,
>
> Yao
>
> Original
> From: TomHerbert
> To: 刘尧00165286;
> Cc: i...@ietf.org ;spring@ietf.org ;
> Date: 2023年10月20日 01:03
> Subject: Re: [IPv6] Fw: New Ve
Please look at draft-ietf-6man-eh-limits that is.
Tom
On Thu, Oct 19, 2023 at 10:02 AM Tom Herbert wrote:
>
> Yao,
>
> Please look at draft-herbert-6man-eh-limits and RFC8883. The draft
> defines limits for things like maximum IPv6 header chain and maximum
> extension he
Yao,
Please look at draft-herbert-6man-eh-limits and RFC8883. The draft
defines limits for things like maximum IPv6 header chain and maximum
extension header size. The RFC defines ICMP errors that can be sent if
a limit is exceeded.
These can be applied to easily discover what the maximum IPv6 he
a
fundamental requirement in an Internet standard for a narrow use case
requiring external context for correct packet processing will be
difficult.
Tom
>
> Cheers,
> Tal.
>
>
> On Thu, Aug 3, 2023 at 5:47 PM Tom Herbert wrote:
> >
> > Tal,
> >
> > From t
On Thu, Aug 3, 2023 at 9:30 AM Tony Przygienda wrote:
>
> well, turns out using a destination address to piggy back some computation
> semantics and especially changing it in mid-flite is not a great idea. Who
> knew ...
Tony,
We already have a working example on how to change destination
addr
Tal,
>From the draft: "Compressed segment lists can be used in the
Destination Address without the presence of a Routing header, and in
this case the IPv6 Destination address can be modified along the path.
This is another case in which the checksum is computed based on the
Destination Address val
---
> From: Greg Mirsky [mailto:gregimir...@gmail.com]
> Sent: Tuesday, November 16, 2021 11:48 AM
> To: Tianran Zhou
> Cc: Ron Bonica ; Tom Herbert ;
> draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
> Subject: Re: [spring] A question for draft-fz-spring-sr
Pascal,
Comments in line.
On Thu, Nov 11, 2021 at 10:58 AM Pascal Thubert (pthubert)
wrote:
>
> +1 .
>
> To Ole that without a good use case in a limited domain it’s hard to expect
> implementation.
>
Unfortunately, TLVs weren't interesting enough when the protocol was
defined so now we have a
On Wed, Nov 10, 2021 at 10:48 PM Tianran Zhou wrote:
>
> Hi Tom,
>
> Please see my reply below.
>
> Best,
> Tianran
>
> -邮件原件-
> 发件人: Tom Herbert [mailto:t...@herbertland.com]
> 发送时间: 2021年11月11日 2:32
> 收件人: Tianran Zhou
> 抄送: Joel M. Halpern ;
&
o deploy alt-mk in these network?
> > The way is to bypass those non-supportive nodes without packet drop.
> >
> > This is why SRH TLV based spring-srv6-alt-mark is proposed.
> >
> > Best,
> > Tianran
> >
> > -Original Message-
> > From: ipv6 [mailto:
drop.
> >
> > This is why SRH TLV based spring-srv6-alt-mark is proposed.
> >
> > Best,
> > Tianran
> >
> > -Original Message-
> > From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert
> > Sent: Tuesday, November 9, 202
On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern wrote:
>
> Let me try phrasing the question about the SRH TLV in a different way.
> And this is as a participant, not as co-chair.
> Assumptions as I understand them:
>
> 1) The 6man draft requires support of both the HbH and DoH cases
> 2) Any node s
On Tue, Oct 19, 2021, 12:10 AM Mark Smith wrote:
> Hi Brian,
>
> On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter
> wrote:
> >
> > Hi,
> >
> > After reading a lot of messages, I'm going to offer my considered
> > opinion as a direct response to Joel's OP.
> >
> > Firstly, I don't believe that in
On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter
wrote:
> On 18-Oct-21 09:39, Tom Herbert wrote:
> > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith
> wrote:
> >>
> >> On Sun, 17 Oct 2021, 06:36 Michael Richardson,
> wrote:
> >>>
> >>> Mark
On Sat, Oct 16, 2021 at 4:59 PM Mark Smith wrote:
>
> On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote:
> >
> > Mark Smith wrote:
> > > In fight changing DAs also will break AH protection of the IPv6
> > header.
> >
> > AH is dead. It's been dead for decades.
> > I say this as an IPsec
On Fri, Oct 15, 2021 at 12:14 AM Mark Smith wrote:
>
>
>
> On Fri, 15 Oct 2021, 17:18 , wrote:
>>
>> Hi Joel , all,
>>
>> C-SID is no more than another mechanism that relies on some algorithmic
>> mapping embedded in the IPv6 address. We do have already many of such
>> algorithmic approaches: R
On Thu, Oct 14, 2021 at 2:07 PM Brian E Carpenter
wrote:
>
> On 14-Oct-21 22:41, Ted Hardie wrote:
> > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter
> > mailto:brian.e.carpen...@gmail.com>> wrote:
> >
> >
> >
> > Including semantics *of any kind* in an IP address is a very fundamental
> >
On Mon, Oct 11, 2021 at 4:14 PM Ron Bonica
wrote:
>
> Folks,
>
> It is much more simple than this.
>
> According to RFC 8200, an IPv6 Destination Address is the “128-bit address of
> the intended recipient of the packet (possibly not the ultimate recipient, if
> a Routing header is present). See
On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard
wrote:
>
> Ø By contrast, a Compressed SID Container (i.e., the 128-bit entity that
is copied into the IPv6 Destination Address field) represents an entire SR
Path. Specifically, it represents *many* functions that reside on *many*
nodes
>
>
>
> But
On Tue, May 26, 2020 at 10:27 AM James Guichard
wrote:
>
> Hi Andrew,
>
>
>
> Some of your comments about SRv6 are a little subjective.
>
>
>
> You say SRv6 is complex and yet in its basic form it is simply a list of IPv6
> addresses carried in a routing header which does not seem too difficult t
On Sun, May 24, 2020 at 2:51 PM Brian E Carpenter
wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote:
> >>
> >> Hi Ron,
> >>
> >> I have one small question on the Destination Option Header you
On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote:
>
> Hi Ron,
>
> I have one small question on the Destination Option Header you keep
> referencing to carry for example VPN demux instructions.
>
> As DOH follows Fragment Header it is indeed inspected before CRH.
>
> So please kindly clarify wh
On Thu, May 21, 2020 at 10:21 PM Ketan Talaulikar (ketant)
wrote:
>
> Hi Joel,
>
> I'll point you to RFC7855, RFC8355 and RFC8402 that cover both the
> data-planes for Spring. Then the RFC8354 which is focussed on SRv6. All this
> body of work along with a whole lot of discussion and brainstormi
On Fri, Feb 28, 2020 at 4:03 AM Sander Steffann wrote:
>
> Hi,
>
> I have been thinking about SRv6 and the whole discussion around header
> removal at one of the SR nodes. While I strongly see the current network
> programming PSP function as a violation of RFC8200, one of the possible
> option
On Wed, Feb 26, 2020, 6:26 AM Andrew Alston
wrote:
> Figured I’d add to this – as I continued to read the charter
>
>
>
> *SPRING WG should avoid modification to existing data planes that would*
>
>
>
>
>
>
>
>
> * make them incompatible with existing deployments. Where possible,
> existing contr
On Tue, Dec 10, 2019 at 4:49 PM Joel M. Halpern wrote:
>
> Fernando, I really wish I could agree with you.
> But I can't.
>
> In 8200, it is clear that the meaning fo "Destination Address" for an
> IPv6 packet is the value placed in the IPv6 destination address field.
> the fact that if we had loo
On Sat, Dec 7, 2019 at 7:10 AM Darren Dukes (ddukes) wrote:
>
> Ron, you say
> >> RFC 8200 addresses extension header insertion and deletion identically,
> >> in the same sentence.
>
> This sentence you refer to clearly permits PSP as defined in network
> programming:
>Extension headers (ex
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
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
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
On Thu, Oct 17, 2019 at 4:53 PM Fred Baker wrote:
>
>
>
> > On Oct 17, 2019, at 5:30 AM, Lizhenbin wrote:
> >
> > In the past two years, China pushed the IPv6 deployment and almost all the
> > IP networks of operators achieve the goal "IPv6 Ready". This provide a
> > strong base for SRv6 deploy
On Sat, Sep 21, 2019 at 10:02 AM Voyer, Daniel wrote:
>
> Hi Joel,
>
> Sent from my mobile
>
> > On Sep 21, 2019, at 00:54, Joel M. Halpern wrote:
> >
> > I see where the draft defines a set of constraints.
> > The constraint that there be no other extension headers is a fairly drastic
> > const
Some comments:
Most of the constraints listed section 2.2 should be specified as
normative requirements.
"SR domain link MTU is sufficiently greater than the MTU at the
ingress edge of the SR domain..." should be the requirement: "The MTU
for all paths in the domain MUST be large enough to accomm
e feasible.
Tom
>>
>> - Dirk
>>
>> On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert wrote:
>>>
>>> On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes)
>>> wrote:
>>> >
>>> > Hi Ron.
>>> >
>>> > I s
On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes) wrote:
>
> Hi Ron.
>
> I summarized my argument as follows:
> "Regardless of ASIC capabilities there are two performance penalties you will
> not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”
>
> You’ve confirmed this additiona
r other text proposal is welcome.
>
> Many thanks,
> Pablo.
>
>
> -Original Message-
> From: Tom Herbert
> Date: Thursday, 12 September 2019 at 21:12
> To: "Pablo Camarillo (pcamaril)"
> Cc: SPRING WG , "6...@ietf.org" <6...@ietf.org>
On Thu, Sep 12, 2019, 4:15 PM Robert Raszuk wrote:
> Hi Brian,
>
> > To what extent is this behind the present argument?
>
> If you are calling elephant and ASIC/FPGA - that was not my reasoning at
> all.
>
> Regardless if you are processing packets by a fixed burned ASIC or
> programmable NP the
On Thu, Sep 12, 2019 at 10:02 AM Pablo Camarillo (pcamaril)
wrote:
>
> Hi all,
>
> Following the comments from IETF105, the working group preferred to allocate
> a new Next Header value.
>
> The authors would like to propose this diff. Any feedback is welcome.
>
>
>
>9. IANA Considerations
On Wed, Sep 11, 2019 at 10:20 PM Xiejingrong wrote:
>
> +1
>
> I think the need to ‘walk through the EH chain’ in fast-path is difficult,
> for the last 2 decades, and will for the near future I guess.
>
> The SRv6 is very careful not to ‘walk through the EH chain’.
>
> Instead it just ‘handle th
On Wed, Sep 11, 2019 at 5:58 PM xie...@chinatelecom.cn
wrote:
>
>
> Hi, folks,
> Last year China Telecom begun to implement SRv6 trial in Sichun province for
> the bearing and interconnection of video platforms which are located in
> different cities, service agilities,secure sepertion, traffic
On Mon, Sep 9, 2019 at 8:16 AM Robert Raszuk wrote:
>
>
>> In any case, I don't believe option number space being exhausted is why TLVs
>> are in SRV6 (if it was a problem, we'd want a general solution instead of
>> point solution just for SRV6). The reasons why TLVs were need in SRV6, as
>> op
ercise for the reader to judge which approach
> is more complex.
>
> Is it to put the cards on the table and play open by clearly defining SRv6
> SRH with SIDs and functions or to play such poker with IETF WGs ?
>
> Thx,
> R.
>
>
> On Sat, Sep 7, 2019 at 11:19 PM Tom H
my overlay I do not plan
> to run any control plane. Underlay basic reachability provided by third
> parties is all I need to construct optimal paths. So any protocol which
> requires new signalling to distribute mapping is non starter.
>
> At the end we should learn from other
On Sat, Sep 7, 2019 at 10:38 AM Zafar Ali (zali) wrote:
>
> Hi Alex, Robert,
>
>
>
> I agree fully.
>
>
>
> From an IETF process viewpoint, Suresh recently cited his email on this topic:
>
> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc
>
> “I just want to confirm that hea
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
wrote:
>
> Folks,
>
>
>
> We have explored many facets of SRv6 and SRv6, sometime passionately. I think
> that this exploration is a good thing. In the words of Tolkien, “All who
> wander are not lost.”
>
>
>
> But it may be time to refocus on the follow
On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk wrote:
>
> Sander,
>
> But this is exactly what both chairs of 6man did with the help of AD long
> time back. You must have missed it !
>
> And below is a link precisely written to address requirement of justifying
> deviation:
>
> https://tools.ietf.
On Fri, Sep 6, 2019 at 3:20 PM Sander Steffann wrote:
>
> Hi Ole,
>
> > Proposals are judged on their merits.
> > There is no protocol police.
>
> There is existing consensus, and changing that requires consensus on the
> changes. The onus is on those wanting the change, yet you demand the ones
On Thu, Sep 5, 2019 at 12:20 PM Robert Raszuk wrote:
>
> Hi Tom,
>
>>
>> insertion. For instance, I'd invite you do the thought experiment
>> about what happens when an intermediate node inserts a header that
>> causes the packet to exceed the MTU of some downstream forwarding
>> node.
>
>
> Absol
On Thu, Sep 5, 2019 at 11:01 AM Robert Raszuk wrote:
>
> Hi Ron,
>
> Nope that is not correct interpretation. Let me try to rephrase it ...
>
> An IPv6 path contains a source node, a destination node, and transit nodes
> Transit nodes belong to network operators which move the packets
> When packe
On Thu, Sep 5, 2019 at 6:35 AM Ole Troan wrote:
>
> 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
On Sat, Aug 31, 2019, 4:34 PM Ron Bonica wrote:
> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
>- Efficient forwarding with deep SID lists
>- Operational Simplicity
>- SRv6+ work may finish before SRv6
>
>
>
> Efficient forwarding with deep SID Lists
>
> -
cially in light of the complex functionality being defined in other low
level protocols such as SR. Can you, or someone who sees this as an issue,
provide a little more context on this problem?
Thanks,
Tom
>
>
> Ron
>
>
>
>
>
> *From:* Mark Smith
> *Sent:* Wednesda
it
simplifies the protocol, reduces support and test matrix, ensures
interoperability, etc.
Tom
>
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Tom Herbert
> Sent: Wednesday, July 3, 201
Hi Ron,
Thanks for the draft.
I think the name SRV6+ might be a little misleading in that it could
be misinterpreted as SRV6+ being a superset of SRV6. Specifically,
SRV6+ doesn't allow 128 bit SIDs which seems inherent in SRV6 and so
the primary function (and implementation) of SRV6 isn't compat
On Thu, May 23, 2019 at 3:18 AM Robert Raszuk wrote:
> All,
>
> May I ask where this concern is coming from ?
>
> All hardware I am aware of can easily do simple match on the type field
> rather then make any assumptions on the order of EHs.
>
> So putting aside main topic of this thread (as hone
t work here. Can you please clarify your concern?
Tom
> Ron
>
>
>
> Non-Juniper
>
> > -Original Message-
> > From: Bob Hinden
> > Sent: Wednesday, May 8, 2019 2:45 PM
> > To: Ole Trøan
> > Cc
On Wed, May 8, 2019 at 11:13 AM Ole Troan wrote:
>
> 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
On Tue, May 7, 2019 at 7:17 AM Tom Herbert wrote:
>
> On Tue, May 7, 2019 at 7:05 AM Mark Smith wrote:
> >
> >
> >
> > On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote:
> >>
> >> That is not what Next-Header means.
> >> Even with thi
On Tue, May 7, 2019 at 7:05 AM Mark Smith wrote:
>
>
>
> On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote:
>>
>> That is not what Next-Header means.
>> Even with this explanation, it is clear that 59 is NOT the right value
>> for the next header.
>
>
> If the SID value isn't a reserved for this
a software trap
must be taken on every unaligned access.
Tom
> Ron
>
>
>
> Juniper Internal
>
> > -----Original Message-
> > From: Tom Herbert
> > Sent: Sunday, May 5, 2019 11:10 PM
> > To: Ron Bonica
troducing a new encapsulation.
>
>Ron
>
>
>
> Juniper Internal
>
> > -Original Message-
> > From: Mark Smith
> > Sent: Sunday, May 5, 2019 9:37 PM
> > To: Xiejingrong
> > Cc: Tom Herbert ; Ron Bonica
> > ; SPRING WG ; 6man
> >
&
much fun it is to deal with unaligned network headers! ;-)
Tom
>
> Jingrong
>
>
>
> *From:* ipv6 [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Tom Herbert
> *Sent:* Monday, May 06, 2019 9:11 AM
> *To:* Ron Bonica
> *Cc:* SPRING WG ; 6man
> *Subject:* Re: SRv6 Network
On Sun, May 5, 2019, 5:47 PM Ron Bonica wrote:
> Folks,
>
> According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00,
> when processing the End.DX2 SID, the Next Header must be equal to 59.
> Otherwise, the packet will be dropped.
>
> In the words of the draft, "We conveniently r
our comments on that draft, suggestions.
>
> Regards,
> Greg
>
>
> On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert wrote:
>
>> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith
>> wrote:
>> >
>> > Hi Tom,
>> >
>> > On Sat, 13 Apr 2019 at 00
t-bonica-6man-vpn-dest-opt for an example.
>>
>>
>>
>>
>> Ron
>>
>>
>>
>>
>>
>> Juniper Internal
>>
>> From: Robert Raszuk
>> Sent: Thu
very likely
in the closed domains that it seems like source routing is targeted
to.
Tom
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Internal
>
> From: spring On Behalf Of Robert Raszuk
> Sent: Friday, April 12, 2019 6:13 PM
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote:
> > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 2
On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote:
>
> Hi Mark,
>
> > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32
> > bit alignment,
> > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network.
> >
> > As 32 bit SIDs are also the same size as IPv
> PC2: Let me try to give you an analogy. A external packet arrives to an ILA
> network. The original IPv6 DA is translated as per ILA. What is the packet?
> Is it an IP packet or is it an ILA packet? To me this is an ILA packet,
> because if the source and destination UPFs are not ILA capable the
1 - 100 of 106 matches
Mail list logo
