Re: Proceedings of the 52nd IETF - submissions deadline Monday

[Jim Boyle <[e-mail]>]

The minutes for the TEWG are available from:

http://www.pdnets.com/ietf/tewg/ietf52/01-minutes.html

I've included them here for your convenience.

Jim

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Minutes of 52nd IETF TEWG
13 December, 2001
Salt Lake City, Utah

Thanks to Josh Broch of AON Networks and Julian Lucek of Juniper for
keeping the minutes.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

draft-ietf-tewg-restore-hierarchy-00
        - through last call, reviewed in CCAMP, IPO, MPLS
        - may need more requirements to add to these
        - currently in ADs hands and moving forward with IESG

draft-ietf-tewg-principles-02
        - IESG - not really a framework draft.  Issues have been resolved.
        - on its way to RFC editor

draft-ietf-qos-routing-04
        - under consideration as info RFC by IESG

draft-lefaucheur-te-metric-igp-01
        - will go to WG last call after meeting for BCP

draft-liljenstolpe-tewg-cwbcp-01
        - Will proceed to IESG as info RFC

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Chris:  (draft-liljenstolpe-tewg-cwbcp-01.txt)

Described CW's offline TE practice - see proceedings for details.

View MPLS as "IP friendly ATM" - no CSPF, QoS.  Actually more like Frame
Relay
- did not want IP IGP to contaminate MPLS IGP.  One IGP for MPLS TE layer,
one
for IP network.

Hierarchy:
        MPLS LSRs
        Core Routers
        Aggregation Routers

Core routers are completely meshed with FR DLCIs (OC-48/OC-192).  Each
CR has an IS-IS adjacency with every other core router/

Can run multiple services over TE core.

Robert (SPRINT):  If efficiency is a concern (FR-MPLS-IP), why not
Frame-based ATM?

Chris: No core routers have Frame based ATM interfaces, so only WAN.
And also fastest ATM interface for routers is OC12, so lots of
mux/demux to OC192 backbone.

Q: When migrate network to MPLE-TE, any management problems?

Chris: Not really - home grown tools.  Took a few months.

Q: Planning on an MPLS service network?

Chris: Yes, but not same as TE network.

Kireeti: When went from ATM PVCs to MPLS, you presumably do EROs
signaled via RSVP.  Did that make you happier or sadder?

Chris: I have tools that do PVC mapping - could do that same for MPLS
layer.  Wanted to do restore at layer 3 so primary and backup paths
signaled via RSVP.

Q: When you calculate LSPs offline, do they have to be typed in?

Chris: Automatically push to routers with scripts, but usually do a
sanity check before is initiated.

Ananth: When you say MPLS service network, what do you mean?

Chris: Services provided over MPLS; primarily L2/L3 VPNSs.

Ananth: Is MPLS running over ATM?

Chris: No, running over POS.

Jerry: What constrains are taken into account (available bw)?

Chris: Take constrains into account during path computation, but don't
put on the router.

Jerry: How often to you recalculate a TE solution?

Chris: Every 6 months as needed.

Francois: Do you do accounting for backup LSPs as well.

Chris: Yes - a percentage of required BW.

Jim: Nice architecture that gives BGP isolation from internal events.
Also can provide multiple services.  What about the network has
characteristics of TE?

Chris: TE is done at layer 2.  Compute paths over the network and can
engineer network as things change.

Jim:  Can better use topology?

Chris: Yes, and regarding the questions about BW accounting?  Assume
that I have a hot spot between Denver and Chicago (due to increase of
traffic between San Francisco and Chicago).  I can easily move the
Denver-Chicago traffic.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Kireeti - TE MIB update  (draft-ietf-tewg-mib-01.txt)

Issues
- make mibs read-create
- need to make tePath* (pieces of teTunnelEntry) a separate table
- make index for teTunnelEntry and integer (not string)

32 byte string index breaks many tools, but should work, so make integer.

- do something with EROs

people don't like string of addresses

- why new TC for "addresses"?

Can have ASs, interfaces, IPv4, IPV6.  How to support?

- conformance statements

Next Steps
- resolve issues
- compile mib with stricter checking
- reissue draft in Jan, 02
- sufficient chances to have another Last Call
- should also be added to MPLS MIB overview

Q: nexthop is missing LSP ID at tunnel ID.

Kireeti: please mention on list so I don't forget

Jim: Please send email to Kireeti in late Jan so assure we get a
revised draft.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

WaiSum Lai: TE measurement draft  (draft-ietf-tewg-measure-01.txt)

Jim: purpose of milestone - one can identity concrete measurements for
the purpose of TE - independent of technology (ATM, FR, MPLS, ...).
Concerned that draft does not meet objective.  Want to have folks read
and comment on whether or not objective is satisfied.  How many people
have read it?  (answer, 4 people in audience raise hand)

Waisum: 3 drafts merged together, significant input from 2 SPs authors
feel draft complete and achieves WG charter objectives and goals ie
doc additional measurements needed for TE

objective: framework doc for traffic metrics needed for successful TE

identifies basic areas of traffic measurement that affect TE focuses
on :

o need for uniform definitions across vendors and operators
o traffic offered load versus achieved throughput
o use of node-pair-based traffic data to derive per-service class
  traffic matrix stats
o stats of carried load vs performance (two aspects: what is coming
  to the n/w, and what traffic the n/w can handle)
o need for higher order stats for service assurance

What's next - draft summarizes principles of best practice in traffic
characterization, performance characterization.  Authors want
comments, but want to move it to RFC quickly.

Tricci: When you try to measure traffic (incoming load and
performance), do you make any assumptions about switches reliability,
packet loss, delay variation?  Should characterize these things before
defining measurements since different vendor's equipment supports
different metrics.  Also, do you make any assumptions about network
architecture?

WaiSum: Draft just identifies metrics - no assumptions as above.

Tricci: Is the assumed network router-based or switch based?

WaiSum: We talk about flow-based metrics, link-based, node-pair based
(CR-to-CR), and MPLS LSP (path-based).  Mainly rely on SNMP and
netflow - don't really have node-pair statistics today.

Jerry: Surprised by comment about this not meeting charter. Work item
is very important, draft does excellent job of identifying
measurements. Had been many favourable comments.

Jim: I did not see any comments - email sent out on Nov. 15.  No one
responded. Including me, only five people in this room have read the
draft. Hence, my concern as chair.  As a member of the WG - sure, you
need to measure when you do TE.  However, draft contains a laundry
list of things around measurement.  For example, in order to see
available capacity the draft says that you can do active insertion of
traffic until congetion shown.  The draft also talks about using RMON
within network.  Are you really recommending these things?

Waisum: For RMON, we use it to manage customer access link.  Of course, we
don't use it on all access links, only certain customer access links.
This is
mentioned as something we do today.  The main thing is to understand how
much
traffic the network carries.  We need to measure traffic on a node-pair
basis
in order to derive traffic matrix statistics.  This aspect is being
identified
as the more important need for TE."

Jim: To rephrase answer - there are things in the draft that are not
recommended.  There are also recommendations, but these are not
clearly distinguished.

Waisum:  Suggestions?

Jim: Abstract is fine, but as you get into draft you don't walk away
understanding what the MIBs need, or what other technology contains.

Waisum: That would be content for the "solutions draft".

Jim: The item that the WG is interested in is more likely this
"solutions" draft.

Kireeti: Including myelf, 5.5 people have read it now. It is a
framework doc. I don't expect much more from a f/w doc. Lots of nice
things, but what does it mean to me? What are the recs? Need something
saying the relevance of the measurement to TE is "..." In order to
measure the success of the TE. How do I use the measurements to say
whether or not the TE used in the n/w is successful?

This draft?  Should probably come up with solutions draft, may get others
together to hit target.  Should we consider other contributions to achieve
objective?

Consensus for something like this in the charter? YES

Do people think that this draft meets objectives of WG?
- does: about 5
- does not: about 5
- holdoff decision at this time: majority

Decided that work item will go on hold for a few weeks so that people can
read
draft.  So read it!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Wai Sum - Diffserv TE Requirements  (draft-ietf-tewg-diff-te-reqts-02.txt)

Design philosophy:

- minimize operational complexity - generality and flexibility not main
goal

- leverage existing protocols

- minimize impact on stability and performance of network (avoid new LSAs
whenever possible)

- distinguish between LSP and packet-level QoS requirements

- distinguish between network and local views (link local, node local)
of BW info

List of issues for discussion:

1) class type - definition

network view - specify how network resources are made available to a
class of traffic.  Used for constraint-based routing.

link-local view - specify amount of link BW available for each class.
Used for IGP advertisement, admission control and link bandwidth
allocation.

2) class type - relationship with priority/preemption

preferred approach is 1-1 correspondence between priority and
class-type.  Could also be many-to-many (matrix), many-to-one
(vector), one-to-many (covered by one-to-one).

3) max number of advertised bw constraints

4) split EF with distinct class types

5) Suppression of preemption

preemption should be optional - not needed in properly dimensioned
network.
When used under overload, can lead to instability.

What's Next?

Q: class types initially introduced to handle aggregation - number of
class
types increased to 8.  Can class-types be replaced with "class"?

Francois: This is a recurring misconception.  Two motivations -
scalability (not important now) and enforcement of common bw
constrains across an ordered set of aggregates.

Kireeti added: can just have one class in each type, but class types
are still useful because they are more general.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Francois:

Open Issues - E-LSPs and L-LSPs

What options are required??

1) DS-TE over E-LSP single OA

2) DS-TE over E-LSP multiple OA, single set of attrs

3a) DS-TE over E-LSP, multiple OA, multiple bw, single set of other attrs

3b) DS-TE over E-LSP, multiple OA, multiple set of ATTRS

4) DS-TE over L-LSP, ...


List concensus appears to be:
- clear requirement for (1)
- clear requirement for (4)
- no clear requirement for (2),
     but it comes for free so might as well have it.
- no requirements for (3b)

Claim
- 3a is a good thing and should be added to the requirements draft.
Is essentially and optimization (may reduce number of LSPs over option
(4), but requires protocol extensions)
- others say, don't need it - improvement is insignificant.

Proposal: go back to requirements draft.  Poll service providers again
and find out what SPs want to deploy.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Sudhakar Ganti (draft-ganti-mpls-diffserv-elsp-01.txt)

Version 1
- presents motivations for multiple OA E-LSPs

Assumptions in current DS-TE
- SPs never deploy LSP tunnels that carry multiple OAs
- each tunnel carriers a single OA

Why now and here in TE-WG?

- DS-TE requirements are being formulated here.
- multiple-OA E-LSPs is precluded in current DS-TE requirements

Recommendations for DS-TE
- add multiple-OA E-LSPs to DS-TE requirements
- consider proposals for multiple-OA signaling mechanisms
- decouple class-=type and preemption priority mapping
- reduce number of preemption levels (3-4)

Tricci: Fully support this draft.  Thinks many people are confused and
that his draft clarifies the issue.

Francois: Opposite view - so lets see the SPs view of this as a
requirement.

Q: When you say that we should decouple priority from classes.  What
does this mean?  How do you use priorities?  On the mailing list, can
we have a specific discussion about what this actually
means. Concerned that multiple-OA have a very limited set of valid
cases - other cases can be hazardous and would not put in my networks.

Kireeti: Useful, but we should not do it.  Had 1 SP say we need this -
reasoning is that we have to many LSPs already.  Bottom line is that
people don't have enough experience scaling networks with a large
number of LSPs.  Reduction can only be a factor of 2-4.  Let's get to
the point - a factor of 2, 4, or 8 is not really useful.  Refresh
reduction is helping already.

Chris: Echo Kireeti - maybe a bit useful, but deployment of it would
be unlikely.

Q: SPs might want to carry vpn traffic of different types from a
customer, would be useful for that

Ed: We need to see a consensus that this is necessary before
incorporating in requirements draft. You should show the group that
this is important.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Francois - Protocol Extensions for DS-TE
           (draft-lefaucheur-diff-te-proto-01.txt)

This draft is the aggregation of Jim's, Kireeti's and previous diff-te
proposal.

Open issues - disable preemption
- current solution does not allow preemption across CTs to be disabled
          (different CTs always use different preemption)
- this can be fixed (allow CTs to use same preemption)
- should it be done?

Kireeti: It is a good idea to say that the default is
index == preemption.  Can change mapping via global configuration -
same as we do for class-types.

Francois: In terms of mapping, proposing what you said,
Index ===>   needs to be configured on every box.

Kireeti: We signal setup/hold priority - could signal indices instead.

Francois: when set up lsp have to say what premption and ct is

Q Does the solution allow you to map different EFs to different
preemption?

Francois:  Yes.

Next Steps
- proposal to adopt as WG document
- should the bw constraint model be move to an "informational"?

Jim:  Let's here from Jerry and come back to this.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Jerry - proposed MPLS diffserv TE class types
                draft-ash-mpls-diffserv-te-class-types-00.txt
                draft-ash-mpls-diffserv-te-alternative-02.txt
                draft-ash-ospf-isis-congestion-control-01.txt

Theme is scalability concerns - draft proposes a small set of
well-defined class types (6 in total)

Why?
- scalability (reduce number of possible class types)
- consistent mapping of services across SP network boundaries for
  end-to-end QoS
Note - small number of "class types" defined for other standards such
as Y.1541 (6 QoS classes)

This is a straw man proposal - specific details of CT definitions TBD.

Referred to work going on in OSPF working group re: other scalability
issues.

Bruce: Sympathize about having consistent definitions of class over
service providers.  Diffserv group decided not to do this --- allow
providers to differential themselves.  Could standardize some classes
(building blocks), but should not constrain all alternatives.

Kireeti: Several things...  Defining a consistent class-type mapping
is something that does not belong in the TE working group.  Going from
8 to 6 or 5 classes is not worth it.  Scalability of IGP is also not a
TE working group item - let's keep mapping flexible.

Jerry: It is not just an 8 to 6 reduction.  There could be 64 PHBs, 8
priorities, any preemption level.  If you want to match all of these
combinations, then you should define these allocations if you want
providers to interoperate.

John:  Agree with Bruce.  Downfall of ATM was in part due to strictly
defined
service categories.

Francois: Agree with Bruce.  If you are going to document a useful
combination of attributes (informational document), that's great.
Should not mandate combinations.

Jon: Goals conflict with proposals - really bad idea.

Bruce: Scalability is a bit of a red-herring.  Does not change what is
signaled.  Not in scope of any existing working group.

Ananth: Suggestion - useful work in terms of a guideline.  Can it be an
informational document?

Jim:  Let's go to the mailing list with additional comments.

Jim: Let's return to discuss proposal to accept Francois's draft as a
WG doc.

     adopt: about 25
     no: about 6

Jim: Will follow-up on the list, but it looks like we have a consensus
to adopt.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Jerry Ash - (draft-ash-multi-area-te-reqmts-01.txt)

Jim: We had an area design team to initiate needs for restoration and
hierarchy.  Hierarchy draft, say that you just need to be able to
signal through multiple IGP areas.  Draft went through WG last call
without comments.  This document came through afterward with more
requirements.  How pressing are these new requirements?

Jerry:
Do we need multi-area TE?  If yes, do we need requirements, what are
they, and where should they go?

Draft proposes a set of requirements and compares different multi-area
TE approaches against requirements.

Some SPs want it.  Some don't - existing stuff works pretty well.

Issues:
- requirements options
   - separate requirement draft
   - add to draft-ietf-tewg-restore-...
   - no requirements

- proposed way to go forward

Jim: As a WG member, and as someone who has designed mpls based data
and TDM networks for deployment, I am not in support of looking too
far down a road we just got on. Do you use subIP technologies in your
network?

Jerry: Yes.

Jim:  In TDM network?

Jerry: No.

Jim: I can see where this is nice stuff to have on roadmap, but is it
important now?  We should be working on more pressing issues.

Ed: Chairs have feedback that we should walk before getting into this.

Kireeti: Do we need requirements?  Yes.  Requirements say that we want
to work on multi-area, single provider TE.  Don't need inter-provider
TE yet.  Maybe we will expand to that a some point, but not now.

Jerry: We need requirements.

Kireeti: draft has 2 parts, requirements. Welcome to post to ccamp ml
to see how drafts compare. Don't need i-d in tewg to do that. Enough
to know that someone should work on it. A detailed list of what knows
to be done, well that was never done for ospf, reqt was just a
link-state protocol

Jim: Are some of these issues are address in OIF?

??:  Protocol extensions for this are being considered in OIF.

Jerry: Draft has two parts - requirements and also compares existing
drafts against requirements.  In CCAMP, it was suggested to compare
these drafts.  This does that comparison.

Ed:  How many have read the draft?  [ about 20 ]

Q: Philosophy is that we have working code now and will come up with
requirements later.  There have been multiple proposals.  We need a
stated list of things against which to evaluate these.

Kireeti: Regarding comparison - I want to compare methods and proposals to
figure out where they fit it.  You can post this analysis to the list.
Don't
need an ID in the TEWG to do that.  To know that we have a requirement for
multi-area TE and have detailed requirements are two different levels of
requirements.  It is enough to know that this problem is important - I
don't
need a detailed list.

Jerry: I agree, we can argue about necessity of requirements.

Adrian: I think that that work should be done.  Just having the "need
multi-area TE" requirement is not sufficient.

Jim: RSVP spec does not prevent people from signaling through
multi-area.  What have you seen to indicate that this is a problem.

Adrian: I have customers that want multi-area in their network.  They
are unclear of feature sets that they should ask for.  This WG should
provide a roadmap for what is necessary.

Jim: What does current experience indicate?  No one has done it.

Adrian:  We should look forward.

Ed: This won't be a working group document.  Restoration hierarchy has
been handed to CCAMP and we are not seeing providers ask for this.

Jerry: I'm one.  Vendors are writing drafts, but don't have
requirements.

Bert: Requirements done and sent to CCAMP - multi-area, single
provider is in scope, but multiple providers are not.  Let CCAMP
deliver protocols to meet current draft.  Very few/none want
multiple-provider TE.

Jim: Requirements doc does say single provider, multi-area is good.
Technical merits can be discussed in CCAMP.

Q: As a point of process, can we get a sense of the room.

Jim: Question - we have forwarded a draft to CCAMP.  We could do one
of three things: pull it back and address in detail multi-area TE,
keep it over in CCAMP and generate new requirements here, keep it in
CCAMP and hold for now on multi-area TE requirements?

Ed: Just one addition.  Very difficult to add multi-area requirements.
We asked and no one responded.  Going back and asking is not going to
help.

Jim [seperating the question]:
Pull back document? 1  Keep in CCAMP?  Everyone else.
Proceed with multi-area request now? about 15  Wait? about 15

Jim: 50-50.  Not going to pull-back document or add requirements here,
but individuals within group free to keep working on there drafts in
this WG and we'll revisit this later.