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 compression.
The apparent inclination of the working group is to use
https://datatracker.
Hi Everyone,
I support the adoption of this document.
Best Regards,
Huaimo
From: spring on behalf of James Guichard
Sent: Friday, October 1, 2021 10:04 AM
To: SPRING WG
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption call for
https://datatracker
Dear WG Chairs,
I have a question about the proposed note to be added if the document is
adopted by the SPRING WG:
Given that the working group has said that it wants to standardize one data
plane solution, and given that the document contains multiple SRv6 EndPoint
behaviors that some WG members
Chairs,
I strongly object to the adoption of this draft.
I also note that this is a very strange adoption call. The WG has indicated a
preference for a single forwarding plane behavior. However, bullets #1 and #4
in the Call for Adoption suggest that the WG has yet to address whether the
draft
CSID Authors,
Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.
Please provide an example that shows us:
* What the SRH looks
Sorry – but – I’m a little confused here.
Because the way I look at this – the working group clearly stated that they
wished for a single behavior – and this – does not deliver that – it is two
separate behaviors. As such – I see this call for adoption – irrespective of
the merits or lack ther
Hi Ron,
Have you read this draft ?
Quote from it:
It is recommended for ease of operation that a single compressed
encoding flavor be used in a given SRv6 domain. However, in a multi-
domain deployment, different flavors can be used in different
domains.
On Fri, Oct 1, 2021 at 9:3
Folks,
Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID
types that can occupy the Destination Address field of an IPv6 header. See
Sections 4.1, 4.2, and 4.3 of the draft for details.
The SPRING WG has issued a call for adoption for this draft.
It is not clear that t
Just to add to this,
I am one of the people who clearly stated that I didn’t think a single solution
was the right answer here – and I stated my reasoning clearly on this list. I
still believe that – however – I recognize that the foundation of the IETF is
found in the bottom up consensus appr
All,
As agreed by WG and reiterated by chairs during this adoption call WG
agreed for a single data plane solution.
That means that the proposed solution MUST be fully compliant with the
specifications in [RFC8402], [RFC8754] and [RFC8986].
To me it does not mean that only a single flavor of th
+1
I object to the adoption.
Tony
> On Oct 1, 2021, at 1:43 PM, Andrew Alston
> wrote:
>
> Just to add to this,
>
> I am one of the people who clearly stated that I didn’t think a single
> solution was the right answer here – and I stated my reasoning clearly on
> this list. I still be
Robert,
I do remember that quote. And that is exactly why I ask the question!
If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:
* Can we say that they are a single behavior ?
* Can we justify both because each is optimized for a different kind of
network?
* Can we j
Hi Ron,
- Can we say that they are a single behavior ?
No. And neither RFC8986 defines a single behavior or single flavor. Yet the
bounds are clearly set what is the SRv6 data plane.
For some strange reason I am observing here an attempt to squeeze different
data plane into the room which i
Dear WG chairs,
I agree with Greg Mirsky that the adoption guidelines are confusing and
contradictory.
Bullet #1 states that by expressing support for adoption the WG member is
agreeing to adoption of a document that has multiple SRv6 compression
solutions.
On the other hand bullet #4 states th
Dear All,
the update in this version describes the benefits of using BFD for
multipoint networks (RFCs 8562 and 8563) over p2p MPLS LSP. Because RFC
8562 updated the BFD state machine, actors avoid the Init state and do not
use the three-way handshake to advance the BFD session to the Up state.
Thu
Hi Chairs & WG,
I strongly support the adoption call. Regarding chair's note in the email, I
would like to point that the network programming model (RFC8996) by nature
defines multiple behaviors. CSID has a single SRv6 based data plane that
defines the next and replace behaviors consistent
16 matches
Mail list logo
