list. Internet Traffic Engineering WG at IETF 57
Vienna, Austria 14 July 1300-1500
Chairs: Jim Boyle, Ed Kern
ADs: Bert Wijnen, Alex Zinin
Minutes: Jim Boyle and Dave McDysan
o) Went over agenda and WG update
- DSTE protos and BC model drafts to go to WG last call after the
meeting
- TE Measurement draft (-06) has been revised. It missed cutoff so
it should post after meeting.
- draft-ietf-tewg-mib-04.txt
- Bert pointed out MIB syntax errors
- Revision should be done by end of July
o) DSTE
+ Francois Lefaucher
- draft-ietf-tewg-diff-te-proto-04.txt
-
draft-ietf-tewg-diff-te-russian-03.txt
- "Max Reservable Bandwidth" is to be interpreted as an aggregate
constraint across all CTs
- "Link Bandwidth" does not play a role in CAC
- Overbooking
- Core specification for DSTE will cover use of LSP size or Link
Size methods
- Local overbooking method will be progressed separately
- Changes to drafts
- Took out references to LOM
- updated CAC formulas (e.g. no use of link bw)
- updated MAM definition (to account for aggregate constraint)
- added section of DSTE scenarios in MAM
Yakov: work in CCAMP related to shared-mesh restoration. In
this there are separate BW pools, but in RDM, the pools are
subsets, so how do these work together?
Francois: Will look into and say if there is or is not an issue
and if it needs to be addressed or not. (w/in 2 weeks)
+ Jerry Ash
- draft-ietf-tewg-diff-te-mar-01.txt
- MAR similar to MAM, but allows CTs to exceed their BC (w/o
preemption)
- builds on methods in use for 10 years
- Changes to draft
- notation in line with Diffserv TE
- added section on applicability (scenarios)
- added section on setting BCs for MAR and MAM
- moved simulation analysis to an annex
- Next step is ready for WG last call for experimental with other
BC model drafts
Yakov: raised that same issue for RDM and shared mesh restoration
also an issue for MAR
Jerry: Agrees that this is an issue to look into and understand.
+ Waisum Lai
- draft-wlai-tewg-bcmodel-02.txt
Purpose is to provide a relative BC model comparison
- Changes to draft
- More explanatory text for performance measures
- LSP blocking and QoS degradation
- BC model design considerations
- New results
- performance under partial preemption, blocking
- General trade-off (RDM, MAM)
- major difference is BW sharing (RDM) -v- isolation (MAM)
- Next step to submit as individual submission with review by TEWG
Waisum: Procedure for progression is still individual but would
like TEWG review.
Chairs: Suggesting that it has been reviewed by TEWG means maybe it
should be a TEWG document (which would necessitate another level of
document review and feedback). Suggest that for now it should stay
as individual contribution.
Francois: Comment that the BC chose for RDM seem to to be not very
in-line with how RDM should be used, which skews the results
towards MAM. Suggested parameters have previously been sent to the
list.
+ Waisum Lai
- draft-wlai-tewg-overbook-00.txt
- per-domain per-CT overbooking is defined in core specs (e.g. PROTO)
- this draft discusses per-link, per-CT overbooking
- two approaches, component based or integrated (this draft)
- Component
- Unreserved BWs still effected by the LOM
- use of new concepts, new formulas required based on
overbooking
approach
- proposes to put max reserv BW to the link BW to simplify
- Integrated
- single formula for all overbooking approaches
- Next steps? This (as with BC models) is experimental, author's
view is that it should move forward when the work on it is
reviewed by the WG.
Francois: indicated that this work is an alternative to the
overbooking approach which had been progressed and agreed so far by
the WG (ie Link Size Overbooking + LSP Size Overbooking +
LOM). Therefore, at this stage, the approach described by Waisum
should be considered as a "contending" approach for the
Experimental Spec but not as the agreed/default approach .
Jim: Question as to what throttles an experimental document
Francois: WG consensus can and should be the throttle
(this also seemed to be consistent with view of Bert Wijnen and Ed
Kern and many in the room - comments to the list appreciated)
+ Francois
-
draft-sivabalan-diff-te-bundling-02.txt
- clarification of MPLS semantics for DSTE over bundles
- says it is not quite obvious how to do this, thus the draft
- since this is DSTE, it is in the charter
- no new protocol specification, but modifies semantic
of existing protocol elements, e.g. p -> TE Class := [p, CT]
- probably obvious to those that are up to date, but nonetheless it
should be written down.
Jim: So is this the only MPLS derivative technology (e.g. FA-LSPs,
restoration), etc... where there is a semantics issue?
Kireeti: This is true (e.g. FA draft) , so better to address all of
them at one time.
Jim: maybe address in proto draft
Francois: Will look into doing this in proto draft if possible,
however if the issue of how to address generically all MPLS
derivative technologies (FA-LSP, restoration...) can not be easily
documented within next couple of weeks, then we should do this
outside of proto so as not to hold-off -proto.
Yakov: Points out that again we need to make sure how generally
mapping "priority" to "te-class" may impact "bw-pools"
e.g. shared-mesh restorations.
Kireeti: Suggest maybe to use general concept of bw-pools, and map
DSTE on top of that, and BC models, then say how to map "priority"
to "bw-pools"
Jim: suggest that DSTE TE-classes may be general enough.
Kireeti: Three cases need to be considered: classic TE, DS-TE,
shared-mesh restoration. As long as parameters in IGP-TE, RSVP-TE
don't change, the semantics (may) only need to be re-defined.
Francois: Agrees that priority values are an index into something,
however that can be mapped into different things (e.g. DSTE).
Would like to address this outside of proto drafts (so as to not
cause any delay on them), perhaps in a separate document to show
how semantics should be dealt with in the context of DSTE.
Jim: Let's specify the issues to the WG list and agree on them and
which need to clear to proceed proto, RDM, etc...
Francois: will try to include this in the two weeks before proto
draft last call.
Jim: summarized two snags
1. Shared mesh restoration interaction with RDM, MAR, MAM
2. Issue of mapping of semantic p to TE Class or something
general
for DSTE, and where to capture this.
o) Multi Area / Multi-AS TE
[Unfortunately, only 25-30 minutes was left in the meeting after
the DSTE discussion]
+ Raymond Zhang
-
draft-ietf-tewg-interas-mpls-te-req-00.txt
- Changes
- organized to 3 objectives
(1) bw guarantee
(2) optimization
(3) restoration
- also distinguished between multi-AS w/in and across
administrative domains.
- Section 5.2, added confidentiality and controls across
administrative domains.
- policy control at boundaries
- re-writes (e.g. reroute objects, DS-TE, etc..)
- Next steps for -01 document:
- include explicit nodes in transit AS (ISP w/ multi-AS)
- Add accounting requirements
- Consolidate section on communicating integrity to HE LSP
Rudiger (?) (DT) - Inter-domain DSTE should be possible, thinks
this should be a MUST. Next comment is OAM should be a MUST.
Raymond: Some of these might have previously been MUST, but
changed due to comment, but this comment will be considered.
+ Jim Boyle
-
draft-boyle-tewg-interarea-reqts-00.txt
- Need to cover multi-area, as there is interest but multi-as
doesn't cover it.
- secondary point is to show that it's not hard to address both
multi-as and multi-area
- To show similarities, broke out some functional areas and
compared and contrasted recommendations for multi-area /
multi-as.
- Next steps- recommend one of the following:
1. develop/refine this draft or else have someone step forward.
2. merge into the inter-AS requirements draft
- JPV: Thought we already decided to progress multi-area and
multi-as as seperate documents?
- Jim: Yes, just thought it was pretty easy to show how these can
be addressed at the same time. But doesn't mind either
incorporating inter-area into inter-as WG item, or progressing
this (or someone else's inter-area req's) separately. Main point
was to not let inter-area be passed over.
- JPV: But multi-AS requirements are very different than
multi-area, is that not agreed? E.g there is need for policy
control. How is that relevant to multi-area
- Jim It is not, multi-area does not need policy, the
requirements
are not the same, they are only similar.
- Yakov: There is no need for policy control in some multi-AS
either, only when AS boundary is same as administrative domain
(e.g. company) boundary.
+ Kireeti Kompella
- draft-ayyangar-inter-region-te-00.txt
- Region== IGP area | AS | sub-AS | routing realm (overlay) |
domain (optical)
- Multiple LSP pieces in each region
- LSP "pieces" or "segments" per region which are stitched or
nested together.
- Scheme is inherently recursive
- Nesting provides good scalability
- Each region retains autonomy, can decide to stitch or nest
- Crankback stays within region (when possible)
- Each region can have its own protection/restoration
- Email comments solicited on the tewg list.
Dmitri P: What's new here is the rules for crossing a region as
opposed to (as specified in the LSP hierarchy draft using the
switching capability field of the ISC descriptor sub-TLV) the
crossing of a technology boundary to form forwarding adjacencies It
would be worth to be expand on this.
<Name?>: concern on local optimization, what happens during
switchover
Kireeti: with topology hiding, global optimization cannot be done
unless the end-to-end LSP is re-optimized by the
head-end. Alternatively, each region can perform local
optimization.
JP Vasseur: Flag in LSP attributes object can prevent local
optimization
+ Jean-Phillipe Vasseur
- draft-vasseur-inter-as-te-01.txt
- Summarized two scenarios
1. Sequence of loose hops expanded in each AS
2. Request passed to one or more Path Computation Servers
- PCS can compute end-to-end optimal (i.e., shortest path)
since it has global knowledge.
- Summarized the two scenarios in a chart
- Summarized many changes to rev-00
- Added new LSP attribute with flags (crankback allowed,
contiguous LSP required (to prevent mid-point
reoptimization), stitching required)
- Ongoing implementations and several planned deployments
- Next steps: continue discussion in tewg, ccamp, where?
- WG chairs and ADs will work on where this draft (and loose path)
should be addressed.
-
draft-vasseur-mpls-loose-path-reopt-02.txt
- Presented to mpls wg in SF.
- Summary of changes
|
