Daniel Migault writes:
> I am under the impression that if one wants to ensure that the agreed DSCP
> value takes the right SA we need to check that. As a result, I am inclined to
> have in any case a MUST be checked. I am wondering if we are expecting this
> check to take a significant overhead ?
DSCP is mutable enroute. The numbers are from a palette of actions.
It is explicite in the DS architecture that ISPs may and SHOULD remark it
across boundaries. (I recall the diffserv WG 23 some years ago.. and I've
been an operator of b2b VoIP, and we had to make sure we did not allow
packets
Hi,
Please find a new version of the draft. The draft considers some comments
provided by Scott and Valery but has not considered comments received today. We
expect to discuss the use of notify during the meeting and will update the
draft accordingly.
Yours,
Daniel
Hi Tobias,
> > You do not need to make childless IKE SA mandatory, you simply need to
> > do first rekey after initial sa creation using normal rekey, and if
> > that normal rekey has SA/KE payloads that are acceptable for the
> > optimized rekey in the future, then you can use optimized rekeys
Thanks for the comments.
I am under the impression that if one wants to ensure that the agreed DSCP
value takes the right SA we need to check that. As a result, I am inclined
to have in any case a MUST be checked. I am wondering if we are expecting
this check to take a significant overhead ?
I
Daniel Migault writes:
> Let me know if that text addresses your concern or if you prefer a different
> wording. I believe I should add some more specific references to 4301.
Note, that RFC4301 already describes how to handle DSCP, and your
draft would actually change mandatory features of
Lorenzo Colitti wrote:
> When working on a VPN implementation we found that it's very difficult
> to rely on IPv6 ESP packets because many networks drop them, so even if
> IKE negotiation succeeds, the data plane might be broken. Worse, this
> can happen on migrate, blackholing
Hi Valery,
Thanks for comments. Please see inline my responses.
On Wed, Jul 26, 2023 at 8:42 AM Valery Smyslov
wrote:
> Hi Harold,
>
> I have a couple of comments (in addition to the good points made by Scott,
> which I support).
>
> According to RFC 4302 DSCP value is not preserved
Hi Harold,
I have a couple of comments (in addition to the good points made by Scott,
which I support).
According to RFC 4302 DSCP value is not preserved end-to-end, i.e. intermediate
routers are free to re-classify traffic and thus change DSCP. So, the situation
is possible,
that peers agree
