[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ipsec] RE: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic



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
 


From: Francois Le Faucheur IMAP [mailto:flefauch@xxxxxxxxx]
Sent: Friday, December 29, 2006 5:01 AM
To: Black, David
Cc: Francois Le Faucheur IMAP; hartmans-ietf@xxxxxxx; saag@xxxxxxx; ipsec@xxxxxxxx; tsvwg-chairs@xxxxxxxxxxxxxx; fred@xxxxxxxxx; pratik.bose@xxxxxxxx
Subject: Re: [saag] tsvwg,preemption and rsvp: exposing characteristics of confidentialtraffic

Hello David,

Now I understand your concern. Please see below:

On 28 Dec 2006, at 22:44, Black_David@xxxxxxx wrote:

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
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec