----------------------------------------
--------------------
Internet Traffic Engineering WG - IETF 55
November 20, 2002
Atlanta

o) Agenda and WG Update

   Document status since last meeting.

   TE Applicability			RFC3346
   Survivability and Hierarchy		RFC3386
   IGP as second metric			RFC-ED
   CW BCP				RFC-ED
   TEWG MIB				no status
   Diffserv TE Requirements		IESG
   Diffserv TE Protocol			no status
   Diffserv Bandwidth models		no status
   TE Measurement			no status

o) TEWG MIB - Kireeti

   Issue is how to define a hop (Textual Convention for hops) Going to 
define TCs for HOPs in MPLS WG TC MIB, reference them in TEWG MIB

   Jerry Ash: It would be prefereable to merge the MPLS WG MIB and the TEWG 
MIB, service providers would prefer to have one as opposed to two mibs.

   Kireeti: They serve different purposes, so they can stay separate.

   Jim: So TEWG mib will include reference into MPLS WG mib

   Kireeti: Just the MPLS TC MIB, which can proceed independent of LSR MIB, 
or other MIBS in MPLS WG (Loa confirmed)

o) Diffserv TE (proto)  - Francois

   Bandwidth constraint models and protocol drafts have been split.
   Really no recent comments on "protocol", most discussion is on BC 
models.
   Drafts define the BC models

   Changes of proto-01 -> proto-02
	- move RSVP-TE appendix into section of text
	- CR-LDP appendix removed
	- cleanup for IESG

   Outstanding issues on 02
	- mostly clarity issues, seem resolved.

   Next steps?
	- Most of room feel that the protocol draft is ready to "freeze" so WG 
last call on list after -03 issued.

o) BC models - Francois

   Requirements
	- operates well w/ or w/o preemption
	- efficient use of bandwidth
        - isolation across CTs
        - protection against QoS degradation
	- simple

    3 documented models
	- russian dolls model (RDM) (Francois)
	- maximum allocation model (MAM) (Lai)
	- maximum allocation w/ reservation (MAR) (Ash)
	Comparison of models [see presentation]

    Propose to document not only one model but rather to document two 
models. Propose that these two documented models be RDM and MAM.

    Noted that there really aren't outstanding issues on Russian Doll 
model.

o) Maximum allocation with reservation (MAR) - Jerry

    [see presentation]

    Jerry recommended that the MA model be the default BC model and that the 
RD model be an optional BC model (should be used only when preemption is 
also used).  Jerry also recommended that we continue to study possible 
extensions to MA, such as MAR, to improve performance.


o) Maximum allocation model and comparison - Waisum

    [see presentation]

    Draft is a comparison of MAM and RDM.  At some rates of signaling and 
load, MAM provides less blocking probability for some classes (e.g. 
service isolation)

    Proposes to have MAM as default model.

o) Discussion on BC models - General

   Lots of discussion on this.  It was pointed out that if we do have a 
normative reference to a BC model, it must be standards track.  Others 
(modular) might be informational, experimental, or standards track (need to 
determine track here).  However, we have multiple BC models on the table 
here, and the requirements document says there must be a default BC model 
for implementation.  So the question becomes: Is "one" of these the 
default?  Or both? Or maybe should neither really be required, they 
proceed non-standard until operational experience shows what people 
really use (and thus should be required for implementation).  Some 
discussion and opinions, but breaking up the question:

   Must there be at least one normative reference from the protocol draft to a 
BC model [show of hands says "yes"]

   Must there be one and only one required bc model?  Or is more than one 
required bc model ok.  [hands are split]

o) Discussion on DSTE protocol drafts and how to proceed

   Obviously going to IESG, the proto draft must proceed with any 
normative referred to bc models. However, we have to first involve other WGs 
(OSPF, ISIS, MPLS).  Some discussion on whether to hold off until 
conclusion on bc models prior to involving other WGs.  Bert indicated that 
since we are going to WG last call on proto, just send some heads up to the 
other lists.

   So we will send a heads up to other WGs shortly after IETF 55 and again 
when WG last call starts (on proto).  If any feel the bc model is 
relevant to how their WG (e.g OSPF, ISIS, MPLS) evaluates the 
protocol, they can raise that issue.  We will send another reminder when the 
BC model issue is resolved.

o) Inter AS requirements

   [see presentation]

   Discussion on if TEWG is right place for these types of 
requirements, show of hands indicated it was and there was no 
objection.  Bert confirmed that was his understanding of where these would be 
too.  Also, show of hands indicated it is about time to take this type of 
requirements work on.

o) TE Measurement draft

   Specific measurements
   - Use of node-pair measurements
   - Stats of carried load -v- performance
   - record/detect label-binding changes (e.g. topology changes)

   Next steps?  Propose that it is WG item against charter item and it is 
ready for WG last call.

   Discussion: Most agree this is an important charter item.  Question is to 
whether this draft has sufficient review to proceed.

   Merike Kaeo (IPPM WG Chair) stated that the need for consistent 
measurement methods is obviously important, but after having read the 
draft, it wasn't clear if that had been achieved [note: this is the 
original issue w/ -02 discussed in Minneapolis].

   Jerry again stated his support for this moving forward.

   Although there were not many people in room who had read the draft, Bert 
asked who would read this if WG last call was raised, and most raised 
there hand.

   So it will go forward for WG last call, if there are folks with issues 
with it, they will need to raise their concern.  It is also important to 
make sure it has had thorough WG review, so there will be an attempt by Ed to 
make sure it's not proceeding to IESG w/o only minimal review.

o) DSTE link bundle options

   Augments DS-TE protocols, but DS-TE protocols (or requirements) don't 
depend on it.  There seemed to be folks who indicated in audience that they 
use link-bundles and want to do DS-TE so this is relevant work.

   As to WG item, Chairs decided to hold off for now.  Issue: If we 
complete the core work for Diffserv TE, does further work on DSTE 
protocol happen here or somewhere else?

o) Wrapup

   Sub-IP lives (for now).  There are question in terms of where TEWG 
heads as it finishes up its current charter. A dormant period? Or turn into a 
more long-term concept group (w/o becoming a research group)?