Alexander Vainshtein wrote on 28/03/2024 15:03:
Alvaro and all,
Regarding the proposal for using a dedicated Ethertype for SRv6:
Please note that RFC explicitly “introduces two data-plane
instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6)”
and defines SRv6 as the
Robert Raszuk wrote on 27/03/2024 10:13:
WGLC on this doc started Jan 22nd - Today we have March 27th - was the
result of the working group's last call announced and I missed it ?
Looking at the list it seems this draft got pretty overwhelming support
already. Why are we not progressing ? What
theory you could put an IDS/IPS in the middle of the 400G
core transit in practice it is never the case.
Kind regards,
Robert
On Tue, Feb 6, 2024 at 10:49 PM Nick Buraglio
mailto:burag...@forwardingplane.net>>
wrote:
On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard mailto:n...@fo
Francois,
Fairly sure Andrew was referring to middleboxes, as defined in rfc3234.
In terms of what rfc8200 does or doesn't say, if srv6 is going to
unearth problems with the well-established operational practices of
embedding middleboxes deeply inside networks, then this will need to be
Zafar,
can you confirm that if Router A in one domain uses next-c-sid and
Router B in another domain uses replace-c-sid, that they will be able to
interoperate? I'm not picking this up from the draft, and this would be
the overriding operational consideration in terms of what a single data
If the proposed change is a non-backwards compatible modification right
down at the bottom of the IP stack, that's a pretty big ask. Has there
been any assessment of what this is going to change or break?
Nick
Tony Przygienda wrote on 03/08/2023 17:29:
well, turns out using a destination
Eliot Lear wrote on 24/10/2021 18:17:
On 24.10.21 17:36, Nick Hilliard wrote:
The issue is a good deal deeper than just debugging. As long as
there's an option to specify a variable length parameter without being
able to specify the length in the protocol, then the protocol is
fundamentally
Sander Steffann wrote on 24/10/2021 16:15:
The tool used doesn’t matter. What matters that an engineer can
understand and decode what’s going on on the wire when stuff breaks.
And that the headers contain enough information to use for interop
between multiple admin domains for example.
The issue
Hi Stefano,
Stefano Salsano wrote on 23/10/2021 01:29:
if an operator wants to combine CSIDs of different length, building the
debug tools becomes more complex, but this actually depends on the
specific choices and configurations
Exactly. For example, problems will occur when the operator
Hi Stefano,
[spring@ re-added to cc:]
Stefano Salsano wrote on 20/10/2021 22:36:
I can anticipate that it is possible to use wireshark to dissect CSID
packets, by providing very simple configuration information.
This is exactly the problem though - operators will need to manually
instruct a
Joel M. Halpern wrote on 13/10/2021 04:52:
1) Does the placement of a list of sids in the IPv6 DA field change the
IPv6 architectural description of that field.
the draft, as I understand it, specifies that inside the srv6 limited
domain, the DA is overwritten in-flight with a locator of
-10-12, 10:40 AM, "Nick Hilliard" wrote:
Darren Dukes (ddukes) wrote on 12/10/2021 15:35:
> Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined
> in RFC8986 are also IPv6 addresses.
Ok, this is good that we're all on the same page about SIDs bein
Darren Dukes (ddukes) wrote on 12/10/2021 15:35:
Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined
in RFC8986 are also IPv6 addresses.
Ok, this is good that we're all on the same page about SIDs being IPv6
addresses. This means that they and
Robert Raszuk wrote on 09/10/2021 22:25:
What really matters to me is that SRv6 packets can be forwarded by not
SR aware IPv6 network elements with no change to data plane and control
plane required. That's it - no more - no less.
Andrew Alston's email indicates that there is at least one
Robert Raszuk wrote on 09/10/2021 19:14:
What technical harm will happen to anyone if I use bits 11-128 as it
seems to fit and still send those packets via v6 Internet ? No basement,
but public Internet.
Andrew Alston already answered this question with a production example.
Robert Raszuk wrote on 09/10/2021 21:26:
Really ? Where ? I am looking at RFC4291 and nowhere I can find /64
reference.
Robert, there's been extensive discussion about this on 6man. Please
run a search on the ietf mail archive for
draft-bourbaki-6man-classless-ipv6 to get a flavour for some
I object to adoption on pretty much the same basis as what Tony wrote.
IPv6 isn't some game of Jenga where the object is to see how many
foundation blocks you can pull out before the whole thing collapses.
Separate to this, the WG adoption call for this draft violates two
sections of the
Robert Raszuk wrote on 09/10/2021 12:39:
In my books if I get allocated say /48 or /40 from RIR what I do with
the remaining bits is my own business.
on your own network, indeed you can. It would interoperate with
nothing, and no-one else would mind. But we're not talking about your
Eduard Metz wrote on 07/10/2021 10:03:
For my understanding, apart from that the (definition of) SID may not be
aligned with the literal text in below RFCs, what is the real problem?
the concept of an ipv6 destination address is deeply ingrained in the
ipv6 protocol. So, looking at this from
Brian E Carpenter wrote on 03/10/2021 05:13:
Does that harm the Internet, even if it leaks? It might disappoint the
sender, as any sender of a bogus packet is disappointed, but apart from that,
who is damaged?
in the smaller sense, limited domain leakage will happen and if the
destination
Chengli (Cheng Li) wrote on 23/05/2020 18:27:
Sure, you are right, we can use CRH and NSH, but personally, I don't think this
is a good idea.
As an operator, I agree - this sounds like a foolish thing to do.
Fortunately, both CRH and NSH processing are disabled by default. I.e.
this is
Zafar Ali (zali) wrote on 15/05/2020 13:53:
It is clear to all that the current draft and adoption request is an
attempt to circumvent the standard practice.
Zafar,
Speaking as an unaffiliated operator who runs kit from plenty of
vendors, CRH looks interesting from a technical point of view.
Zafar Ali (zali) wrote on 06/04/2020 16:37:
We continue to see strong industry consensus on SRv6, Juniper show-cased
SRv6 functionality at the latest EANTC report, especially:
Zafar,
EANTC are an interoperability testing shop, so it seems unlikely that
they're advocating for any particular
Sander Steffann wrote on 02/03/2020 20:32:
Steamrolling a draft through a working group completely undermines
the whole idea of the IETF and greatly damages it trustworthiness and
reliability. By bluntly declaring consensus despite all of the
objections within two hours of the latest version of
Andrew Alston wrote on 27/02/2020 10:35:
1. The burn of address space required to adequately deploy some of this
(something that there was agreement on in Montreal that there would
be analysis on – which was never done)
I'm a bit alarmed by the lack of engagement here between the
Joel M. Halpern wrote on 05/09/2019 14:11:
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
Rob,
Clarifying what I wrote previously, I don't think it would be
appropriate for draft-filsfils-spring-net-pgm-extension-srv6-usid to
progress further unless the authors can demonstrate that the volume of
IPv6 addressing required can be satisfied in a way that works within the
constraints
Robert Raszuk wrote on 02/09/2019 12:49:
Yes you are 100% correct.
The decision to inject any prefix into someone's IGP (or BGP) is a local
operator's decision.
It is, and most operators take pains to avoid injecting shared
addressing resources into their routing domains. These days it
Robert Raszuk wrote on 02/09/2019 12:09:
If that is the only concern I think we are done then. The only issue is
that if you happen to have hierarchical IGP you will not be able to
summarize them - but I don't think that this would be a showstopper to
any deployment.
Robert,
please correct
Ron Bonica wrote on 01/09/2019 22:10:
-https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
Ron,
if this draft proposes using up to /32 per router in a SRv6 domain, or
even /40 to /48, it may be appropriate to solicit input from RIR address
policy groups about
30 matches
Mail list logo
