Hi all,
I’ve read this draft. It is proposing 2 different encodings schemes for
compressed sequence of SRv6 SIDs (and an optional behavior on border nodes)..
Although Section 4 makes a claim that different deployments usecase may deem
one encoding scheme superior over the other, I could not
I'm less interested in the definition of an "interface" than I am in the bits
in an Interface Identifier (i.e. the bottom 64 bits of an address).
There is a formal update of the addressing architecture on this very point.
https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says:
...the
Hi Chairs, WG,
Network programming model [RFC8986] defines multiple flavors of End, End.X, and
End.T SIDs. CSID draft builds on it with next and replace flavors for these
SIDs. The draft reports multivendor interop was done to show co-existence of
next and replace flavors. This is evidence
I also object to WG chairs who are also co-authors of a draft participating in
the process of advancing the draft through the WG process, whether it is WG
adoption, WGLC or IETF LC.
Look up “recuse” in the dictionary.
:K
> On Oct 1, 2021, at 07:04, James Guichard
> wrote:
>
> Dear WG:
>
I object to the adoption of this document in its current form.
—Colby
>> Dear WG:
>>
>> The chairs would like to express their appreciation for all the responses
>> received to our emails with reference to how the working group wishes to
>> move forward with respect to a solution for SRv6
I object to the adoption of this document as it currently stands.
:K
> On Oct 1, 2021, at 07:04, James Guichard
> wrote:
>
> Dear WG:
>
> The chairs would like to express their appreciation for all the responses
> received to our emails with reference to how the working group wishes to
+1
> On Oct 5, 2021, at 11:56, Ron Bonica
> wrote:
>
> Jim,
>
> The call for adoption has already been posted. There is no way to put that
> toothpaste back into its tube. However, I strongly recommend against such
> calls for adoption in the future.
>
> Normally, the authors of a
Inline [RB]
Ron
Juniper Business Use Only
From: Eduard Metz
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica
Cc: 6...@ietf.org; SPRING WG
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
Can the SID be
Hi,
After re-reading the draft I strongly support its adoption.
1. Following the Design Team work stream, CSID proves conformant and optimal.
2. It allows for the flexibility of selecting the SRv6 data plane flavor
(compressed or not) without changes to the architecture.
3. Has proven
Hi Francois,
thank you for your detailed response and confirming that C-SIDs of
different flavors/behavior may be present in the same SRH and even the same
CSID container. I've noticed Ron's proposal as I was trying to formulate my
question. His proposal highlighted what I am trying to understand
Ahmed,
That is a far cry from recommending anything.
* If you take a look at the first page of that slide deck, the DT was
tasked with enumeration and analysis of requirements. The word "recommend" does
not appear on that page.
* If you look at the third page of that slide deck, you
Folks,
We appear to dancing around the meaning of the words "solution", "behavior",
and "flavor". While this dance is semantically elegant, it is neither
productive nor uplifting.
A better way to determine whether NEXT-C-SID and REPLACE-C-SID are both needed
is with a tiny bit more analysis.
+1 to Ron’s comments.
—Colby
> On Oct 5, 2021, at 2:56 PM, Ron Bonica
> wrote:
>
> Jim,
>
> The call for adoption has already been posted. There is no way to put that
> toothpaste back into its tube. However, I strongly recommend against such
> calls for adoption in the future.
>
>
Hi Greg,
It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the
segment list in the SRH. It learns about the available SIDs in the network with
their associated behavior and flavors via control plane and/or management plane
protocols, as described in Section 8 of RFC 8986,
Hi Mark,
Ok the argument of IID space comes first time - I do apologies if I missed
it and it was mentioned before.
So the consequence of reserved IID space for application A in case of
collision with any other application B may yield unexpected results. And
that apparently is completely
On Thu, 7 Oct 2021 at 21:33, Robert Raszuk wrote:
>
> Nick,
>
> Ok let's zoom on your point.
>
> IPv6 Addressing Architecture RFC says:
>
> IPv6 addresses are 128-bit identifiers for interfaces and sets of
>interfaces (where "interface" is as defined in Section 2 of [IPV6]).
>There are
Indeed !!! Spot on.
I would further extend your suggestion ... VLAN interfaces should be
obsoleted, any form of tunneling should be considered an IPv6 spec
violation, dial in interfaces should be considered evil, IPv4 in IPv6 etc
... and this is not only in routers but also in compute nodes.
I honestly would like to understand if this discussion about fixing the
wording (e.g. use a more abstract notion of interface / link), or if there
are cases where things (may) break. I was hoping someone could point to
examples?
As pointed out by Robert not all types of interfaces used today fit
Data plane “Programmability” in principle should be discarded
If the address is only “a node's attachment to a link”.
I do not want to mention “locator” and “argument” because any programmability
is blocked by such address definition.
I hope we do not want to move everything to the control plane
Nick,
Ok let's zoom on your point.
*IPv6 Addressing Architecture RFC says: *
IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces (where "interface" is as defined in Section 2 of [IPV6]).
There are three types of addresses:
Unicast: An identifier for a
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
Can the SID be viewed as the address of the "interface" to, in this case,
the function that resides in a node? From a routing / forwarding point of
view the group of functions is more similar to a network (represented by a
prefix, rather than a single address), but still.
For my understanding,
22 matches
Mail list logo
