Nick
I fully agree that IF SRv6 were requiring non-backward-compatible changes this
would be a contradiction to the definitions of RFC 8402.
So, let's prevent SRv6 from requesting such changes and, where necessary,
extend IPv6 in a backward-compatible way.
I believe this is doable.
My 2c,
Hi Joel,
Let me very clear here.
I am not really proposing any changes. What is already standardized is
sufficient to address all issues raised.
All I was doing in those threads is to clarify what problem are we talking
about and how could it be fixed reasonably.
And yes I did read RFC6936 and
Which - as you know since I have stated it to you - is still not incompatible
with the ravioli draft - since the ravioli draft could well take advantage of
an ethertype allocated by the safe-limited-domains draft
Again those drafts are in no way mutually exclusive or reliant on each other
On Thu, Mar 28, 2024 at 8:40 AM Robert Raszuk wrote:
>
> Hi Tom,
>
> Not really.
>
> RFC8200 defines an exception which is tunneling and says:
>
> As an exception to the default behavior, protocols that use UDP
> as a tunnel encapsulation may enable zero-checksum mode for a
>
Joel,
> On Mar 28, 2024, at 8:46 AM, Joel Halpern wrote:
>
> Robert, as far as I can tell, you are asking for a different change than any
> of the other proposals. If I understand, you are proposing that even end
> hosts inside an SRv6 domain should encapsulate the underlying IPv6 packet.
Hi Joel,
Le 2024-03-28 à 16:46, Joel Halpern a écrit :
CAUTION:This is an external email. Please be very careful when clicking
links or opening attachments. See the URL nok.it/ext for additional
information.
Robert, as far as I can tell, you are asking for a different change than
Alvaro
Minor correction, there is also
https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/
for a more generic approach on limited domains
-éric
From: spring on behalf of Alvaro Retana
Date: Thursday, 28 March 2024 at 13:03
To: SPRING WG List
Cc:
Robert, as far as I can tell, you are asking for a different change than
any of the other proposals. If I understand, you are proposing that
even end hosts inside an SRv6 domain should encapsulate the underlying
IPv6 packet. In order to help the chairs keep track, and tell if there
are other
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
Hi Tom,
Not really.
RFC8200 defines an exception which is tunneling and says:
As an exception to the default behavior, protocols that use UDP
as a tunnel encapsulation may enable zero-checksum mode for a
specific port (or set of ports) for sending and/or receiving.
On Thu, Mar 28, 2024 at 7:46 AM Robert Raszuk wrote:
>
> Hi Tom,
>
> > because of SRH
>
> Ok I buy this that there are devices which do check checksum and are not
> final destination of the packets ... I was more talking about plain
> forwarding devices (aka P routers). Then I doubt firewalls
Hi,
At this point of time new ethertype buys us nothing then disturbance.
If anything is here to discuss is the question if in the cases of using
C-SID/uSID hosts talking native SRv6 and using more then one uSID should
also use additional 40 octets of IPv6 extra header or not.
It could be
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
instantiation of SR on the IPv6 data plane.
From my POV using
Sasha,
I think that we are in agreement regarding points 1 and 2. Issue #3 is the bone
of contention.
More inline...
Ron
Juniper Business Use Only
From: spring on behalf of Alexander Vainshtein
Sent: Wednesday,
Hi Tom,
> because of SRH
Ok I buy this that there are devices which do check checksum and are not
final destination of the packets ... I was more talking about plain
forwarding devices (aka P routers). Then I doubt firewalls would be sitting
in the core of the networks.
But let me come black
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
>
>
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
A.1.1. Regular SIDs are used
A.1.2 Compresses SIDs are
Focusing on the C-SID draft, some have suggested requiring the
presence of the SRH whenever C-SIDs are used. Please discuss whether
that is the desired behavior (or not) -- please be specific when
debating the benefits or consequences of either behavior.
Please keep the related (but independent)
Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the
behavior when an originating node inside an SRv6 domain creates a
packet with a C-SID as the final destination. This description differs
from the text in Section 8.1 of RFC8200.
We plan to send the draft to the 6man WG for review
Dear WG:
While the chairs strongly appreciate the engagement in the discussions
around the SRv6 compression draft, several topics have gotten tangled,
and the subject lines do not help track the conversation. Following
this note will be two messages intended to serve as an anchor for
separate
20 matches
Mail list logo
