|
Francois,
> Do you agree that
RFC 3175 allows use of AF?
Yes - the fact that it deliberately did not put in a full PHB-ID is
unfortunate,
as having to infer from context whether a DSCP is a singleton vs.
representative
of a group from context is not the best approach. It looks
like I missed
this AF support in quickly scanning RFC 3175.
> With respect to
rsvp-ipsec, a simple approach is to edit the description text of the "DSCP"
field in the
> GENERIC-AGGREGATE SESSION object
along the lines of what is in RFC 3175 (ie if session uses
> single PHB, then
field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then
field
> contains the
numerically smallest DSCP value as per [PHB-ID]). This would make it explicit
that
> rsvp-ipsec also
allows use of PHB groups, and would ensure consistent use of DSCP field
between
> RFC 3175 and
rsvp-ipsec.
That's probably the right thing to do at this juncture, because
...
> The other approach
would be to change the format of the GENERIC-AGGREGATE
SESSION object
> and include a full
16-bit PHB-ID instead of DSCP field. I can see that this could help in
situations where
> (i) the Aggregate
reservation crosses Diffserv domain boundaries and (ii) different DSCP values
are used
> for a given
PHB/PHB-group. But I am not sure that this would be a common situation. On the
flip side,
> it would make things
less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where
the
> operator has elected
to use a DSCP for the PHB which is different from the recommended DSCP
value,
> then RFC
3175 would encode the used-DSCP while rsvp-ipsec would encode the
recommended-DSCP
> as per
PHB-ID).
... probably entails going back and changing RFC 3175 to use a PHB-ID,
something
that it's probably entirely too late to do, and I agree that a divergence
between
RFC 3175 and rsvp-ipsec is undesirable.
> BTW: One
related question on PHB-ID. PHB-ID says " Note that the recommended DSCP
value MUST
> be used,
even if the network in question has
chosen a different mapping." So what happens if someone wants
> to deploy two
instances of EF? how do you encode those in a PHB-ID?
The second EF instance would be a case 2 PHB-ID - experimental or local
use.
The current PHB-ID reference is RFC 3140.
One of the things I think we're discovering (e.g., w/Fred's
admitted-voice PHB)
is that EF instances aren't completely combinable in practice - in theory
they're
completely combinable, and hence one never needs more than one, *if* the
rules
are followed perfectly. That "if" doesn't appear to completely hold
in practice.
Thanks,
--David
Hello David,
Now I understand your concern. Please see below:
Francois,
My general concern for the draft is:
The concern about how to use a PHB consisting
of multiple DSCPs
(e.g., AF)
also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC
3140)
may
help address this, and this concern may also
affect RFC 3175.
For example, this sentence from the Introduction
(Section 1) applies
to EF, but not AF for carrying the reserved
traffic:
One example is where E2E reservations using
different preemption priorities (as per [RSVP-PREEMP]) need to
be
aggregated through a Diffserv cloud using the same DSCP.
The underlying situation is that the raw notion of
DSCP is being used
instead of a PHB, and for better or worse, this is
already the case
in RFC 3175. The practical upshot is that RFC
3175 effectively forbids
use of AF PHBs for carrying reserved traffic -
Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF
PHBs for carrying reserved traffic.
In particular, it says:
"
In the case where a session uses a pair of PHBs (e.g.,
AF11
and AF12), the DSCP used should represent the numerically
smallest
PHB (e.g., AF11). This follows the same naming
convention described
in [BRIM].
...
[BRIM] Brim, S., Carpenter, B. and
F. LeFaucheur, "Per Hop
Behavior
Identification Codes", RFC 2836, May 2000.
"
Do you agree that RFC 3175 allows use of AF?
one has to explicitly
specify the DSCP (which could also be used as part
of an AF PHB if
one was being careful). Going back and changing RFC 3175
at this
point is definitely *not* a good idea, so I would
suggest just making
this observation (RFC 3175 requires use of a single
DSCP for traffic
aggregated into a single reservation) in the
rsvp-ipsec draft and
observing that this forbids meaningful use of AF
drop precedence
for traffic covered by an RSVP
reservation.
With respect to rsvp-ipsec, a simple approach is to edit the description
text of the "DSCP" field in the GENERIC-AGGREGATE SESSION object
along the lines of what is in RFC 3175 (ie if session uses single PHB, then
field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then
field contains the numerically smallest DSCP value as per [PHB-ID]). This
would make it explicit that rsvp-ipsec also allows use of PHB groups, and
would ensure consistent use of DSCP field between RFC 3175 and
rsvp-ipsec.
The other approach would be to change the format of the GENERIC-AGGREGATE
SESSION object and include a full 16-bit PHB-ID
instead of DSCP field. I can see that this could help in situations where (i)
the Aggregate reservation crosses Diffserv domain boundaries and (ii)
different DSCP values are used for a given PHB/PHB-group. But I am not sure
that this would be a common situation. On the flip side, it would make things
less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where
the operator has elected to use a DSCP for the PHB which is different from the
recommended DSCP value, then RFC 3175 would encode the used-DSCP while
rsvp-ipsec would encode the recommended-DSCP as per PHB-ID).
Thoughts?
BTW: One related question on PHB-ID. PHB-ID says " Note that
the recommended DSCP value MUST be used, even if the network in question
has chosen a different mapping." So what happens if someone wants to deploy
two instances of EF? how do you encode those in a PHB-ID?
Cheers
Francois
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953
FAX: +1 (508) 293-7786
----------------------------------------------------
|