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

From: [email-masked]
Date: Fri, 19 Jan 2007 10:11:48 -0500

Francois,
 
I have no problem with your preference to do the "right thing"
even if it differs with RFC 3175.  I'm not an RSVP expert and
hence I'm not in a position to express a strong opinion on
alignment with vs. divergence from RFC 3175.
 
So, your proposal is fine with me, and I'll leave it to you
and others on this email to determine what the rough consensus
of the RSVP community is on how to deal with issues and
limitations in RFC 3175.
 
Thanks,
--David
p.s. Nit - One probably should use plain text email when
	including ASCII data structure diagrams.  Microsoft's
	HTML renderer did "interesting" things to your diagram
	in the HTML-format email ;-).
---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

________________________________

	From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
	Sent: Friday, January 19, 2007 12:50 AM
	To: Black, David
	Cc: Francois Le Faucheur IMAP; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [saag] tsvwg,preemption and rsvp: exposing
characteristics of confidentialtraffic

	Hello David, 

	Please see below:

	On 29 Dec 2006, at 19:00, [email-masked] wrote:

		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.

	Thinking this over, I now have a marked preference for the
second approach (ie change the GENERIC-AGGREGATE-SESSION object format
to include PHB-ID instead of DSCP). Despite that fact it is "the right
thing to do", my main argument is that this is required to be able to
operate in a scenario where the Aggregate RSVP reservation would span
two Diffserv domains which happen to use different DSCP markings for the
same PHB (or PHB-group). 

	The object would look like this:

	            0           7 8          15 16         23 24
31
	
+-------------+-------------+-------------+-------------+
	           |               IPv4 DestAddress (4 bytes)
|
	
+-------------+-------------+-------------+--+----------+
	           | Reserved    |     Flags   |  vDstPort   |Rd
|
	
+-------------+-------------+-------------+--+----------+
	           |       PHB-ID              |           Reserved
|
	
+-------------+-------------+-------------+-------------+
	           |                    Extended vDstPort
|
	
+-------------+-------------+-------------+-------------+

	I don't think we need to change RFC3175. In fact, the objective
of the Generic Aggregate I-D is to remove restrictions of RFC3175. This
is just one more restriction of RFC3175 that we remove. I think
ultimately the Generic Aggregate I-D will effectively supersede RFC3175.

	Does this work for you ?

	Cheers

	Francois

		> 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:[email-masked]] 
			Sent: Friday, December 29, 2006 5:01 AM
			To: Black, David
			Cc: Francois Le Faucheur IMAP;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
			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, [email-masked]
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
				[email-masked]        Mobile: +1
(978) 394-7754
	
----------------------------------------------------

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Fri, 19 Jan 2007 17:12:56 -0500

Actually it's now 3140, which fixed a few problems in 2836 ;-).

Thanks,
--David 

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 10:27 AM
> To: Francois Le Faucheur IMAP
> Cc: Black, David; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Sorry for being late picking this up. I personally can buy 
> either the  
> "a PHB group can be identified by the numerically least value in it"  
> approach or your second option. If you want to go with 2836, 
> it works  
> for me.
> 
> On Jan 18, 2007, at 9:50 PM, Francois Le Faucheur IMAP wrote:
> 
> > Hello David,
> >
> > Please see below:
> >
> >> 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
> looks like I  
> >> missed
> >> > 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
> >> > 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  
> >> 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
> >> > 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).
> >>
> use a PHB- 
> >> ID, something
> >> that it's probably entirely too late to do, and I agree that a  
> >> divergence between
> > Thinking this over, I now have a marked preference for the second  
> > approach (ie change the GENERIC-AGGREGATE-SESSION object format to  
> > include PHB-ID instead of DSCP). Despite that fact it is 
> "the right  
> > thing to do", my main argument is that this is required to be able  
> > to operate in a scenario where the Aggregate RSVP 
> reservation would  
> > span two Diffserv domains which happen to use different DSCP  
> > markings for the same PHB (or PHB-group).
> >
> >             0           7 8          15 16         23 24          31
> >            |               IPv4 DestAddress (4 bytes)              |
> >            | Reserved    |     Flags   |  vDstPort   |Rd        |
> >            |       PHB-ID                |            
> > Reserved         |
> >            |                    Extended vDstPort                  |
> > I don't think we need to change RFC3175. In fact, the objective of  
> > the Generic Aggregate I-D is to remove restrictions of RFC3175.  
> > This is just one more restriction of RFC3175 that we remove. I  
> > think ultimately the Generic Aggregate I-D will effectively  
> > supersede RFC3175.
> >
> > Does this work for you ?
> >
> > Cheers
> >
> > Francois
> >
> >>
> >> > 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
> >> The second EF instance would be a case 2 PHB-ID - experimental or  
> >> local use.
> >> One of the things I think we're discovering (e.g., w/Fred's  
> >> admitted-voice PHB)
> >> 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
> >>
> >>
> >> On 28 Dec 2006, at 22:44, [email-masked] wrote:
> >>
> >>> Francois,
> >>>
> >>>>> 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
> >>    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.
> >> "
> >>
> >>> 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  
> >> 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