Hi Alvaro,
Just a clarification – I believe my comments on section 6.5 have been well
documented in other threads – would you like them duplicated here for clarity?
Andrew
Internal All Employees
From: spring on behalf of Alvaro Retana
Date: Tuesday, 2 April 2024 at 20:41
To: SPRING WG Li
On April 3, 2024 at 7:59:20 AM, Andrew Alston - IETF wrote:
> Just a clarification – I believe my comments on section 6.5 have been well
> documented in other threads – would you like them duplicated here for
> clarity?
Yes, we do.
Thanks!
Alvaro.
__
As requested,
My original email on this topic quoted below – but first some thoughts on how
we could fix this.
1. We could mandate the imposition of an HBH and then state that the draft
updates 8200 with adequate text and with 6man agreement – this would allow for
correct checksumming
2.
Andrew:
Hi!
The question was: "Does anything need to be added, deleted, changed, or
clarified?" We want to be as specific as possible when we ask 6man for
their feedback.
>From your reply, I see that you are not happy that
§6.5/draft-ietf-spring-srv6-srh-compression doesn't talk about calculati
I have no known IPR related to this document.
On Wed, Apr 3, 2024 at 12:20 AM Tal Mizrahi
wrote:
> I am not aware of any IPRs that are related to this document.
>
> Cheers,
> Tal.
>
> On Tue, Apr 2, 2024 at 7:24 PM Joel Halpern wrote:
> >
> > Can the authors (and listed contributors) please con
Hi Alvaro,
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.*
I would like you to clarify the
There are two cases covered in section 6.5 of the compression draft that
appear to be at variance with secton 8.1 of RFC 8200.
First, if the final destination in the routing header is a compressed
container, then the ultimate destination address will not be the same as
the final destination sh
Hi Joel,
My interpretation of text from RFC8200 is that it allows discrepancy
between the header and the upper layer checksum as long as final packet's
destination sees the correct one.
The last condition is met.
So I see no issue.
Sure RFC8200 does not talk about SRH nor cSIDs, but provides a
The concern with regard to the text that the chairs are asking about is
not about intermediate nodes verifying the checksum. The text does not
talk aabout that, so we are not asking about that.
But, the text in 8200 specifies how the originating node is to compute
the upper layer checksum. I
Ok Joel,
Thank you for this clarification.
To me the actual spirit of RFC8200 8.1 is to say that it is ok to
compute the checksum by the src such that it comes out right at the final
destination.
But I guess we can have different opinions about that.
But what I find specifically surprising here
I can not speak to the "norm" for other working groups. The SPRING
charter is very specific about what we have to do if we want to change
an underlying protocol. We have to go back to the WG which owns that
protocol.
6man gets to decide if the change is acceptable, and if it is acceptable
h
Hi all,
No, I'm not aware of any IPR related to this document.
Best regards
Luis
El mié, 3 abr 2024, 21:57, Nick Buraglio
escribió:
> I have no known IPR related to this document.
>
> On Wed, Apr 3, 2024 at 12:20 AM Tal Mizrahi
> wrote:
>
>> I am not aware of any IPRs that are related to thi
12 matches
Mail list logo
