there are +/- here
1) SRH will be notably more expensive to filter than dispatching ethertype
in HW unless it can be guaranteed to be present at a fixed offset
2) ether type is completely optional and will interop easily with
"pseudo-IPv6" per raviolli draft and is trivial to implement in HW on al
Robert, please do read the according draft with the explanation of this
being completely optional and freely mixable with "SRv6 is IPv6 kind of"
mode ...
And let's stick to basic technical sanity and IETF STD documents being
standards that cannot be violated by following documents lest they be no
which has been said many times since the effort started by people who have
been around many architectures in networking space and lived the dreams of
violating/bending standards, shortcutting layers and other "clever"
solutions justified by exigency, limited-use-only or whatever other
figleaves cou
support. good solution for the problem in its scope though ultimately
relying on the deus-ex-machina all-knowing controller of the SR technology.
Nothing new ;-)
-- tony
On Mon, Dec 25, 2023 at 3:32 PM Adrian Farrel wrote:
> Hey SPRING,
>
> Please be aware of this working group last call in MPL
ould possibly remedy that by patching the destination address into frame
from SRH of course. But yeah, let's see we start to see further fallout
here as well.
-- tony
On Thu, Aug 3, 2023 at 8:18 PM Tom Herbert wrote:
> On Thu, Aug 3, 2023 at 9:30 AM Tony Przygienda
> wrote:
> &g
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 ...
as to bis'ing STD86 I was quickly thinking "it's not April yet" ...
-- tony
On Thu, Aug 3, 2023 at 9:43 AM wrote:
> Hi Tal,
>
>
> Plea
On Sat, Apr 1, 2023 at 10:29 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> Tony,
>
> On 02-Apr-23 05:53, Tony Przygienda wrote:
> > ?
> >
> > I heard the argument that IPv6 address space is large and "easy to carve
> up to mean other things&
5 PM
> > *To:* Krzysztof Szarkowicz ;
> Kireeti Kompella
> > *Cc:* Adrian Farrel ; Andrew Alston - IETF
> ; int-a...@ietf.org;
> spring@ietf.org; Dr. Tony Przygienda
> > *Subject:* RE: [spring] [Int-area] FW: New Version Notification for
> draft-raviolli-intarea-tru
obile nodes
>>> which move from network to network.
>>> >
>>> > Is this closed domain - no by any means. Is it working today - yes
>>> pretty well.
>>> >
>>> > So proposing a new ethertype for SRv6 today seems to be comparable to
&g
Though I would like to cheer for Kireeti's 2. as well I think the point of
SHOULD is more realistic (for now) as Joel points out ...
As to ethertype, I think grown-ups in the room were since long time drily
observing that a new IP version would have been appropriate after enough
contortions-of-it'
On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) wrote:
> Bruno, Jim, Joel,
>
>
>
> Without any hat, or only with the experience of reviewing so many I-Ds
> from different areas and having implemented a couple of proof-of-concept
> implementations of various IETF drafts.
>
>
>
> The followin
? No basement, but
> public Internet.
>
> Last time I checked bits are bits and there is either 0 or 1 in the
> packets (at least till we get to quantum networking). It should be in no
> one's business in the transit to look anywhere beyond /10.
>
> Again please limit the answer
I object adoption of this document as well based on copious amount of
technical counter arguments laid out in multiple threads. Beside that it
seems that to violate IETF v6 architecture documents we seem to be
trampling on established standards more and more using increasingly
contorted sophisms (y
On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk wrote:
> Hi Brian,
>
> Thank you - yes by legacy I meant not upgraded one - no different meaning
> intended.
>
> As far as conforming to addressing architecture sorry to say but to me
> this is red herring. Sure address must be a legal address - no que
Taking this new "philosophy of limited domain" to its bitter conclusion
A is Internet Standard
B is also Internet Standard for "Limited Domain" that violates A
C is also Internet Standard for "Limited Domain" that violates A
D is also Internet Standard for "Limited Domain" that violetes C
so by t
I can beat that ;-) AFAIR, my first job in IBM in the 80s was to remove
loose source routing code from token ring bridges since it was causing
operationally too many problems ...
-- tony
On Thu, May 28, 2020 at 8:13 AM Ron Bonica wrote:
> Ketan,
>
>
>
> Neither of these forwarding methods are u
On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote:
> Hi Tony,
>
> >
> if you're willing to provision things correctly yourself via S-PGP.
>
> I am not willing to do that. I would like routing to do it for me
> auto-magically.
>
The price of that would be that you can run strict SPF only th
oes not allow me to do that
> seems pretty limited - wouldn't you agree ?
>
> Thx,
> R.
>
>
>
>
>
>
>
> On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda
> wrote:
>
>> Robert, productive points, thanks for raising them ... I go a bit in depth
&g
rvers behind those TORs need to
> talk to each other in a non blocking fashion _and_ I have spare 100 GB
> ports on TORs having routing protocol which does not allow me to do that
> seems pretty limited - wouldn't you agree ?
>
> Thx,
> R.
>
>
>
>
>
>
>
s pushed down to all
other nodes. That's more of a "per leaf node" information case and pretty
good unless leafs go crazy doing dynamic re-assignment (but we can dampen
that in spines @ every level if needed) but it's not _per prefix_ which you
seemed to ask about
--- ton
Robert, productive points, thanks for raising them ... I go a bit in depth
1. I saw no _real_ use-cases for SID in DC so far to be frank (once you run
RIFT). The only one that comes up regularly is egress engineering and that
IMO is equivalent to SID=leaf address (which could be a HV address of
co
21 matches
Mail list logo
