Subject: IETF 56 TEWG Minutes

From: Jim Boyle <[email-masked]>
Date: Wed, 26 Mar 2003 21:45:01 -0500 (EST)

----------------------------------------
IETF 56 Internet Traffic Engineering Agenda
March 17th - 1930-2200

Minutes         Subject                         Who

15              Agenda / WG Update              Chairs

15              TE-Preemption techniques        de Oliveira

45              Diffserv TE                     Francois
                - Requirements
                - Protocol
                - BC Models
                  - Russian
                  - MAM
                  - MAR
                - DSTE MIB                      Nadeau

30              Multi Area / Multi AS TE
                - draft-zhang update            Zhang
                - Q&A

15              Perennial update on TEWG MIB    Kireeti

Others as time permits.

Drafts for Meeting:

http://www.ietf.org/internet-drafts/draft-deOliveira-diff-te-preemption-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-03.txt
http://www.ietf.org/internet-drafts/draft-wlai-tewg-bcmodel-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-russian-01.txt
http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-mam-00.txt
http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt
http://www.ietf.org/internet-drafts/draft-zhang-mpls-interas-te-req-02.txt
http://www.ietf.org/internet-drafts/draft-vasseur-inter-as-te-00.txt
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt
ttp://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-tewg-mib-04.txt
http://www.ietf.org/internet-drafts/draft-sivabalan-diff-te-bundling-01.txt

WG Update :

WG Items Status (see specific discussions below)

   IGP as second metric                 RFC-ED / normative reference hold

   CW BCP                               RFC-ED, author revision

   TEWG MIB                             Ready for WG Last Call
					      
   Diffserv TE Requirements             RFC-ED

   Diffserv TE Protocol                 Ready for WG Last Call

   Diffserv Bandwidth models (all to be progressed as Expiremental)

   - Russian Doll Model                 Ready for WG Last Call

   - Maximum Allocation                 Revise and reissue as WG document
					Then will go to Last Call

   - Maximum Allocation w/ Reservation  Revise to cover comments.

   TE Measurement                       IESG

----------------------------------------
Started of with Diffserv TE

Diffserv TE

DSTE Requirements Update - Francois
- version 7 updated sent to IESG which has already approved
- removed concept of "default" BC model
- alignment of Diffserv terminology

DSTE Protocol Draft - Francois
- Changes from version 2 to 3
- removed concept of "default" BC model
- ready for last call
- will send notice to other WGs (e.g. OSPF, ISIS, MPLS)

DSTE Russian Doll BC Model (RDM) - Francois
- Changes from version 0 to 1
- removed concept of "default" BC model
- Security consideration updated
- no current known open issues
- ready for last call
- DSTE w/ RDM has limited deployment experience now
- question as to which track to follow (experimental, standards?)

Chairs: After some discussion, it seems the way to go forward is to
make all of them experimental, then as they get some use, move them
toward standard.  [there was a call for comment, but no questions
raised at this point]

It was agreed that RDM should go forward to WG last call [note, that
version 2 will be what is used for this].

DSTE Maximum Allocation Model (MAM) - Francois
- multiple analysis drafts, both biased, and neither really a
specification
- thus, specification draft put forward
- propose that we make this WG document in next revision
- then issue next revision (working with Waisum) and take to WG last call.
- progress BC model analysis in a document separate from individual BC
  Model specs.

Dave McDysan: Will this include a discussion against the scenarios in
the requirements document?

After discussion it was determined that in the Russian dolls draft,
there is a discussion of how it meets the requirements, so this will
also be done in the maximum allocation specification.

It was agreed that diff-te-mam should be accepted as WG document and
that next rev should be moved to Last Call.

DSTE Maximum Allocation Model (MAM) - Waisum
- Slides may not match what Francois discussed, but only since they
  were prepared last week, in general he echos what Francois outlined
- Drafts intent was specification and comparison of performance
- Main difference with RDM is higher degree of sharing with
  tradeoff of service isolation impact (ala preemption)
- Proposing it as an applicability statement to MAM (or BC models more
  generally) 

Chair proposed to move this draft forward as an individual
informational RFC. Waisum agreed.

DSTE Maximum Allocation with Reservation Model (MAR) - Jerry
- Some amount of discussion on list (esp. between Jerry and Francois)
- Feels all models should work well with or without preemption.
- This is especially important with lack of "default" model

Francois had some comments on whether all the assumptions have been
fully outlined in the MAR draft, Jerry agreed that they he will revise
the draft to cover this more fully.  

DSTE MIB - Tom Nadeau
- Linked into MPLS WG TE MIB
- Not tightly coupled to any specific BC model
- Comment from Bert that while this is worthwhile thing to work on,
  there are some significant comments that need to be incorporated
  into base MPLS MIB documents, and he'd like to see progress on that
  before worrying about which WG DSTE MIB should be in.

----------------------------------------
Preemption algorithm and analysis - Jaudelice
- (see presentation and draft)

----------------------------------------
Multi-AS Requirements

Chair comment: There's been a lot of discussion on this work, in terms
of what our scope should be, where should protocols be discussed, and
whether to accept this particular on as the WG document to be the
requirements draft.  At this time we have several WG items that are
very near to completion and that is our top objective now.  We can
continue to have discussions on the list in terms of requirements, and
even discussions on how current protocols meet or fall short of these
requirements, but we are not ready now to adopt drafts in this area
now as WG documents.

Multi-AS draft-zhang
- updates from draft 1 to 2
- incorporated several comments from the list
- echoed that now is the time for this work.
- show of hands showed that most in the room had read this draft.

Chair - Question on whether we should address Inter-area as well as
Inter-as.  Raymond indicated that most folks are not that interested
area, however a show of hands indicated that several in the room were
interested in inter-area.  Question on if this draft could cover that
as well?

JPV and Raymond said that the SPs co-authoring the inter-AS TE
requirements draft are not interested to extend the scope of this
draft to inter-area TE. There could be a separate draft for inter-area
TE requirements though.

JPV mentioned that although some solutions will be both applicable to
inter-area and inter-AS, the set of requirements will likely be different
in particular the aspects related to policy, confidentiality and security.

Vijay - Some of this seems to be looking very far down the road, why
focus protocol changes in support of inter-as while not even figuring
out how to work out some of the issues that might be experienced
within one network, or across networks within one company.  Many of
the larger companies actually have one global network.

Yonghwan Kim: Indicated that this is not necessarily universal, they
have quite a deal of traffic they would like to engineer, but their
current architecture has regional AS structure.

Comment:  Did the Hierarchy / Restoration RFC3386 discuss multi-area?

Answer: No, there was some discussion, but nothing firm was finalized
and there was an explicit door left open for this.

JPV indicated that he hoped that this moves forward quickly, as
customers are waiting for this, and we are delaying that. 

Jim indicated that if customers are waiting, then by all means provide
them with a solution.  In fact, some experience in this regard migh be
a good thing before final specification.  What expectation is there on
timeframe for the IETF to develop requirements and specifications?

Francois mentioned that DSTE is an example of something whose
standardisation lingered because it took a lot of discussion to agree
that it should be worked on.  This has resulted in proprietary
deployed implementations.

Bert echoed that there is nothing wrong with going out and developing
solutions to problems for operators.  In fact having some experience
fed back into the specification process might help us better
define our requirements.

There was some objection to this idea, since if solutions are
developed in a proprietary manner, proprietary solutions can become
de-facto standards, then what is the role of the IETF?

It could be seen to imply that the proposed progression was:
   demonstrated solution -> 
   requirements -> 
   specification
which seems cumbersome.

Francois pointed out that progress on items already in our charter can
be done independently of discussion on multi-as requirements, and he
feels that by not making draft-zhang a WG document, we are only
delaying our progress.  It is his belief that draft-zhang will become
more fully reviewed and make better progress as a WG document, and
that lack of a WG document in this area indicates that the WG is not
committed to progress on this subject.  This was echoed by Bruce
Davie, George Swallow and Jean Phillipe Vasseur.

Jim agreed that the effort is orthogonal, but felt that, for instance
some had indicated that although there were clearly folks who felt
they had requirements for inter-as, there were also folks that
indicated an interest in inter-area.  It might be best to consolidate
the requirements for these in a coherent requirements document instead
of doing requirements piecemeal as they develop.  Or at least we
should explicitly decide to group these or work on them separately.
It might also be good to analyze the potential scope and to make sure
that we focus on particular subset of this.

There were several other comments that are not captured in the notes,
but it certainly seemed that several felt that the path being proposed
would do nothing more than delay.

JVP asked where he should be discussing the different proposed
solutions that he has, and Jim replied that he can have individual
contributions to the IETF, and that in the context of making sure we
have flushed out the requirements correctly we can discuss these on
TEWG list.  JVP's response was that it was clear that over 80% were
enthusiastic about the current requirements draft, and that any delay
to make it a WG document will result in eventual delay in the
solutions being specified.

This number seemed at least to the ADs and to the chairs to be a bit
high, given some comments of concern for the potential impact on
routing scalability and manageability for making the wrong choices in
this area.  It certainly was clear that the document had been read by
most in the room.

Jim tried to determine to what extent there was support in the room
for pushing forward with draft-zhang, compared to those that did not
support it moving forward at this time either because they had
particular issues with it in particular or felt there needed to be
more discussion in general.

After much discussion on how to capture this in a clear question, it
was agreed just to leave it at those that thought we should accept
draft-zhang as a WG document (to capture multi-as requirements), and
those that felt that it should not be a WG document at this time.

There was an overwhelming majority of folks in the room that felt that
it should be adopted as a WG document now.

At this point there was little more to discuss, other then to continue
with following the discussion up on the list (and for the chairs and
IESG to figure out what if any charter update is required at this
time).

--------------------------------------------------
TEWG Mib Update - Kireeti

The draft has been revised to be inline with the MPLS WG document TCs.
Need to confirm if it compiles cleanly, and if necessary revise
draft (by March 31st).