RE: [Tsvwg] DRAFT TSVWG meeting notes - corrections requested

["Francois Le Faucheur \(flefauch\)" <[e-mail]>]

James and all,
Below are suggested edits on minutes.
Francois


>> 
>> Francois's                                    10:25-10:40 
>> (until 10:53)
>> draft-lefaucheur-emergency-rsvp-00              (20 min)

Above : s/(20 min)/s(15 min)/



>> draft-ietf-tsvwg-rsvp-ipsec
>> 
>> - RSVP-IPSec
>>        - Removed SPI from what identifies the Reservations
>>        - This made everything here simpler
>>        - Added notion of extended virtual destination port, 
>> also used in
>>          MPLS

Above: s/MPLS/MPLS TE/


>> - RSVP-Emergency

Add:
"
	    - Draft presents RSVP extensions to identify Emergency sessions and give them elevated probability of session establishment
"

>>        - Speaker asked to take this
>>        - Gerald Ash - how is this mech mapped to the RPH
>>        - James answered - that SIP is disconnected from Router
>>          behaviors, and that local policy determines the mapping from
>>          the RPH to RSVP Priority values and treatments

Above:s/and treatments/and treatments (Note that the draft now proposes an extension to also convey the RPH inside RSVP signaling)/


>>        - Janet commented - <missed it>
>>        - Georgios asked about if there are too many higher priority
>>          calls, at what point, at what capacity does this 
>> doc suggest to
>>          terminate calls

Replace previous bullet by:
"
	- Georgios asked, in the case of the new Priority Bypass Model, about if there are too many higher priority calls, at what point, at what capacity does this doc suggest to stop admitting new emergency calls or terminate non-emergency calls
"


>>        - Francois answer that preemption is not discussed

Replace previous bullet by:
"
	- Francois answered that, with the Priority Bypass Model, new emergency calls are always accepted and non-emergency calls do not get preempted. It is a simple model that works under the assumption that emergency load remains reasonable. The other models described in the draft can be used to deal with other cases (eg. stop admitting emergency calls at some stage).
"

>>        - Allison commented on reorganizing the doc but 
>> separating the BW
>>          model from the mechanism, as this ID is clearly a 
>> PS track, but
>>          the model is not - so it can be in an appendix
>>        - Francois to think about that

Replace previous bullet by:
"
       - Francois agreed. This will be reflected in next rev.
"

>> 
>> Jukka's and Markku's                          10:50-11:00 
>> (until 11:19)
>> draft-manner-tsvwg-lrsvp-00                      (10 min)
 
>> - Francois - thinks there is value is documenting proxy behavior, not
>>    clear that the endsystem needs to be the starter of this mechanism
>>    (i.e. a L-RSVP proxy in a early router, more like edge-to-edge)
>>        - Will send comments to the list now

Above: remove "now".


>> ====================================
>> CL+RMD Bar BoF                           attendance:  13+15+5=33
>> 
>> Chairing James Polk
>> 
>> Francois on the overall approaches.
>> 
>> Edge2Edge/Controlled Deployment Model
>> 
>> David Black: Assumption that all in PCN domain are in on the 
>> PCN. That
>> domain is then interacting with ECN routers.
>> 

I think David's point was more to the effect that in Edege2Edge/Controlled we can assume that there is no interaction between PCN and ECN.
So I would propose something like:
s/That domain is then interacting with ECN routers./Inside the domain there is no interaction between PCN and ECN/



>> PCN is associated with some changes in the ECN field treatment. What
>> are opportunities if there are mixed ECN and PCN end to end. 
>> The model
>> discussed is an Edge to Edge/controlled. Important to consider these
>> models when doing the discussion.
>> 
>> See first model slide for this model.
>> 
>> The end system does not need to be trusted.
>> There is the use of normal RSVP to the end system.
>> 
>> End to end/open deployment model is the other version. Consider mixed
>> usage model with PCN and ECN.
>> 
>> Questions:
>> 
>> A) Focus on edge to edge/controlled

s/edge to edge/Edge2Edge/

>> 
>> B) Decide that we want to address both edge to edge and end-to-end.

Replace by:
"
	B) Decide that we want to address both Edge2Edge/Controlled and End2End/Open.
"

>> 
>> c) Work out viability of end-to-end/open first?
>> 

s/end-to-end/End2End


>> Are there other models to cover?
>> 
>> 
>> Pratik Bose: Will ECN have the same meaning in end to end and
>> edge-to-edge?
>> 
>> ?: Experimental solution for end to end. Use different marking system
>> and how would they be used? Need input how fast we should go forward.
>> 
>> David Black: Focus on A. Mechanism are used seem to be fine 
>> granularity
>> adjustments that would not be available in end-to-end. Figure out
>> co-existence with normal ECN (RFC 3168).
>> 
>> Bob Briscoe: Started thinking about the end-to-end case and could not
>> easily resolve it. That why we started with edge to edge. Requires
>> reasonable behavior from systems, more likely in network than end
>> hosts.
>> 
>> Encoding
>> --------
>> Presentation of 4 alternatives.
>> 
>> Bob Briscoe: Do people believe this should be done in ECN or in the
>> DSCP field?

s/ECN/ECN field/

>> 
>> François: Why would you use DSCP in a controlled environment?

s/Why would you use/Why would you not use/

>> What is the motivation for this?
>> 
>> John Anders: Is okay to use another DSCP codepoint, like alt 1?
>> 
>> David Black: It is no obvious that you need to use another code point
>> as you could filter them into another traffic class and not 
>> handle that
>> with PCN end to end.
>> 
>> François: Filter voice into its own DSCP. Have the PCN 
>> behavior depend
>> on the DSCP.
>> 
>> James: Is this a local decision on what to use?
>> 
>> David Black: No, especially for alt 1. One thing that is 
>> happening. Not
>> have the ECN field to depend on the DSCP.
>> 
>> Bob: Use AM control to traffic that handle ECN. Non ECN is static
>> assignments.
>> 
>> François: No problem in the controlled environment to use one DSCP.
>> Down path it might be a bigger problem. Like MPLS. EXP is scarce and
>> using EXP for this may not be available
>> 
>> Kwok: Pretty open on this issue.
>> 
>> Divide it on DSCP and have that control the ECN behavior:

I think the above refered to Pratik's question:
I would replace it with something like:
"
Pratik Bose: How about we allow multiple alternatives for encoding and operator decides what they do in their network?
"

>> 
>> David Black: As DSCP are operator dependent this can be a problem.
>> Complexity problem. Would be good to standardize one way to do this.
>> 
>> François: Good to do this in one way for Hard ware support.
>> 
>> Kwok: Not have ECT encoding within a the field. Question on what is
>> better to use.
>> 
>> David Black: This is not obvious. Needs to go to the list.
>> 
>> François: Goal was to get people thinking.
>> 
>> Initial simulation Study
>> Anna Charny: Limited applicability. It works in the 
>> simulation we have
>> done. Not done a complete verification. This is a proof of 
>> concept. And
>> a demonstration that there is ongoing simulation work.
>> 
>> 
>> PCN/RMD
>> François: Pre congestion marking: STD or EXP?
>> 
>> John Loughney: Good bring to that into NSIS is supported.
>> There is a individual draft for integrated service control load:
>> Will post the draft ref to the TSVWG list.
>> 
>> Bob: Do people think it is enough that PHB and ECN marking is
>> specified. Do we need to a top level document declaring that
>> combination that is required to get the service? This would be a one
>> page.

Above: s/that PHB and ECN marking is specified/that PHB and PCN marking are specified independently/


>> 
>> Restatement
>> 
>> David Black: From process point of view separating ECN from PHB is a
>> better question. Would provide better clarity.

s/ECN/PCN/

>> 
>> Anna: A PDB document would need to define a lot of behavior and group
>> things together.

I think above was a question form Anna (not a statement)