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

[Black_David@xxxxxxx]

Fred,

This looks like a good approach.

Please check the rest of the draft for more "residual verbiage
about tunnels", as there's also potentially problematic text in at
least Sections 2.1 and 2.3.1  In 2.1, there are a number of places
where use of singular "reservation" instead of plural "reservations"
may imply that there is one aggregate reservation for the tunnel.

Also, please consider how the approach in this draft ought to be
applied to a PHB that consists of multiple DSCPs (e.g., an AF
class, cf. RFC 2597).  I believe AF is not a good fit to the
sort of traffic that motivated this draft, so explaining that
may suffice.

Thanks,
--David

> -----Original Message-----
> From: Fred Baker [mailto:fred@xxxxxxxxx] 
> Sent: Friday, September 29, 2006 6:59 PM
> To: Black, David
> Cc: hartmans-ietf@xxxxxxx; saag@xxxxxxx; ipsec@xxxxxxxx; 
> tsvwg-chairs@xxxxxxxxxxxxxx; flefauch@xxxxxxxxx
> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing 
> characteristics of confidentialtraffic
> 
> hmm. It sounds like there is some residual verbiage about tunnels in  
> the vpn-signaled-preemption draft.
> 
> Bottom line, both drafts call for a common DSCP. Both require  
> multiple reservations by vport in the RSVP signaling, with the vport  
> indicating anything that the network administrator wants it to  
> indicate, and the vpn-signaling draft specifically saying that the  
> network administrator in question is requesting that it signify call  
> precedence. Call precedence is, in reality, not signaled by the vport

> number, but by the priorities signaled in the RFC3181-clone priority  
> (precedence) fields of the rsvp draft, but the values used for the  
> vports have to be agreed upon throughout the network in order to name

> the resulting reservations so they can be "discussed" among the  
> equipment.
> 
> I am willing to clean up the use of "priority" and "precedence" as  
> you suggest and clean up this paragraph, along with Jari's  
> "discuss" (as in, "remove a section the principal client of the draft

> asked to have written into it"). I think it's fair to ask for any  
> remaining IESG comment before doing so...
> 
> On Sep 29, 2006, at 3:01 PM, Black_David@xxxxxxx wrote:
> 
> > Actually, only the vpn-signaled-preemption draft appears to do this.
> >
> > The rsvp-ipsec draft allows multiple reservations between the same
> > endpoints for the same DSCP, which would allow such traffic to use
> > different tunnels but if it requires traffic for different
> > reservations to use different tunnels, I was not able to find
> > a statement of that requirement.
> >
> > OTOH, the vpn-signaled-preemption draft is quite clear that
different
> > precedence levels for the same DSCP result in different IPsec
tunnels.
> > Section 2.3.3 says:
> >
> >    Due to
> >    the mechanics of preemption, however, this would not expand the
> >    existing "routine" reservations in the interface and inner
domains,
> >    as doing this causes loss of information - how much of the
> >    reservation is now "routine" and how much is "priority"?  Rather,
> >    this new reservation will open up a separate set of tunnels or
> >    security associations for traffic of its application class at its
> >    precedence between that aggregator and deaggregator.
> 

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec