Subject: Minutes of IETF 55 TEWG Meeting

From: Jim Boyle <[email-masked]>
Date: Fri, 29 Nov 2002 08:53:28 -0500 (EST)

------------------------------------------------------------
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)?

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 04 Dec 2002 15:40:07 +0100

Dear All,
>    to take this type of requirements work on.

People interested by the inter AS requirements could also be interested
by a draft that Cristel Pelsser and myself submitted in parallel to
this work on the inter AS requirements. 

Our draft  proposes a set of extensions to RSVP-TE to allow
the establishment of inter-AS LSPs. In this draft, we take into
account the following requirements listed in the interAS draft :

4.5 Support of diversely routed inter-AS TE LSP
4.6 Fast Recovery support using MPLS TE Fast-Reroute
4.10 Confidentiality

More precisely, we show how to support 4.5 and 4.6 on the interdomain 
links and routers while maintaining a similar type of confidentiality 
as the one listed in your draft. Preserving confidentiality while supporting
fast recovery and diversely routed LSPs requires some small extensions to 
RSVP-TE but is feasible. We intend to update the draft based on
the requirements defined by the TEWG.

You can find a pdf version of our draft, containing all figures here : 

http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-09.html

Best regards,

Olivier Bonaventure

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 11 Dec 2002 18:50:19 -0500

Hi Jim and Ed,

[snip]

>    to take this type of requirements work on.

I think the conclusion went a bit further and there was a consensus that 
draft-zhang-mpls-interas-te-req-00.txt should be a WG document (I remember 
having explicitly asked the question and the answer was positive).

I would just like to re insist on the fact that this draft has been driven 
by Service Providers requirements (see the list of co-authors). Several 
other Service Providers will join this draft soon, providing additional 
input. By the way, as far as I know, this is the only existing draft 
dealing with inter-AS TE requirements. This draft is a -00 version and we 
would, of course, be more than happy to receive other 
comments/suggestions/... from the list on those requirements for the next 
revision.

May I request the TE WG to adopt it as a WG document ?

Thanks.

JP.

---

From: Jim Boyle <[email-masked]>
Date: Thu, 12 Dec 2002 22:07:52 -0500 (EST)

Jean Philippe, it is not my recollection that the feel of the room 
for adoption of your draft as a WG item was actively polled.  I do
recall polling that this subject (Multi-area TE requirements) is
probably prime for active pursuit by the WG and that TEWG would
probably be the right place for that.

So, you ask why is it that we don't just adopt your draft and march 
forward.

There are many reasons.  The primary one is that this is (or will 
be) a new work item, and there hasn't been any list discussion 
on this topic.  I'd like for others that are interested in this 
subject to comment on your draft to the list, or put forward their
own proposal.

Jim

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 13 Dec 2002 10:00:37 -0500

Hi Jim,

>subject to comment on your draft to the list, or put forward their

adopting it as WG doc did not prevent from receiving comments and improving 
it ;-) Anyway, let's move the discussion on the list.

Thanks,.

JP.