Daniel Migault writes:
> Thanks for the comments, this matches how we envisioned to update the draft,
> except that we envisioned the responder sends a N(DSCP) and that we also
> indicated the support of the N(DSCP). I think you recommend not to have these
> two notifications, which could work for
Daniel Migault wrote:
> As far as I understand it, yes, the two end sites are managed by the
> MNO.
So they should be able to either coordinate DSCP values (use the same ones),
or they should know how to translate them between sites (before entering
tunnel and/or after exiting tunnel).
Hi Michael,
As far as I understand it, yes, the two end sites are managed by the MNO.
Yours,
Daniel
On Wed, Aug 9, 2023 at 9:27 AM Michael Richardson
wrote:
>
> Tero Kivinen wrote:
> > If we agree on the inner DSCP values, but map them differently that
> > does not actually matter as
Tero Kivinen wrote:
> If we agree on the inner DSCP values, but map them differently that
> does not actually matter as long as we never bypass some DSCP values
> while mapping others, as every packet in the tunnel will have same
> outer DSCP value thus will receive same processin
Hi Tero,
Thanks for the comments, this matches how we envisioned to update the
draft, except that we envisioned the responder sends a N(DSCP) and that we
also indicated the support of the N(DSCP). I think you recommend not to
have these two notifications, which could work for us.
Please see inlin
Daniel Migault writes:
> I am coming back to one comment that has been made during the
> presentation that DSCP values do not necessarily be associated with
> a pair of SA.
>
> We want to organise tunnels where DSCP values are partitioned
> between a subset of SAs. More specifically suppose that w
I am coming back to one comment that has been made during the presentation
that DSCP values do not necessarily be associated with a pair of SA.
We want to organise tunnels where DSCP values are partitioned between a
subset of SAs. More specifically suppose that we have g1 = (DSCP_a,
DSCP_b), g2 =
Thanks Tero, this is helpful and overall improves the design. Please see
inline additional comments/questions. We basically would like to know if
these DSCP selectors could be reasonably called "pseudo traffic selectors"
or if someone believes that will be confusing. Feel free to suggest other
alte
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 to
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 do
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 RFC430
re and tunnel handling.
Regards,
> Valery.
>
>
> > Scott, thank you for your review. Here are the responses to your
> comments, see
> > inline for details.
> >
> > Brs
> >
> > From: IPsec On Behalf Of Scott Fluhrer
> (sfluhrer)
> > Sent: Thurs
rom: IPsec On Behalf Of Scott Fluhrer (sfluhrer)
> Sent: Thursday, July 13, 2023 2:58 AM
> To: ipsec@ietf.org
> Subject: [IPsec] draft-mglt-ipsecme-ts-dscp
>
> Hi,
>
>I rereviewed this draft, and have a few comments:
>
> - As the draft is written, the administrato
Scott, thank you for your review. Here are the responses to your comments, see
inline for details.
Brs
From: IPsec On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Thursday, July 13, 2023 2:58 AM
To: ipsec@ietf.org
Subject: [IPsec] draft-mglt-ipsecme-ts-dscp
Hi,
I rereviewed this draft, and
Hi,
I rereviewed this draft, and have a few comments:
* As the draft is written, the administrator can specify that (for example)
traffic with DSCP=3 must be protected, but other traffic is not. I don't
believe giving administrators this option is a good idea, it can likely result
in
16 matches
Mail list logo
