The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Draft Minutes from Pittsburgh
Minutes MPLS WG , Pittsburgh, Aug 2000
======================================
Wednesday 9:00 - 11:30
1. A Banerjee kompella-mpls-ospf-extensions-00.txt
kompella-mpls-ospf-extensions-00.txt
These drafts specify extensions to the IS-IS/OSPF routing protocols in
support of Multiprotocol Lambda Switching (MPL(ambda)S). In particular
they specify TLVs describing the capabilities of links which can be
used and signaled with gerenalized MPLS signaling.
Proposal:
Propose that drafts be accepted as WG document.
George (as chair):
Those drafts should actually be progressed as WG document
in ISIS and OSPF WGs. They were presented in MPLS WG because they
relate directly to documents that are the subject of MPLS.
Banerjee: agreed. Will progress through ISIS and OSPF WGs.
2. Mannie mannie-mpls-sdh-ospf-isis-00
This draft specifies and suggests extensions to the OSPF and IS-IS
routing protocols in order to support the routing of dynamically
established SDH/SONET circuits using the MPLS architecture.
It builds upon existing OSPF/ISIS extensions, proposing TLVs for
routing of SDH and SONET circuits. It also proposes Bundling for
scalability (see below). It also addresses interworking between SDH
and SONET.
An important challenge is to achieve the optimal balance between the
amount of information need to make accurate routing decisions and the
cost of advertising that information. There can be many "holes"
fragmenting the capacity. Possible solutions:
- advertise exactly what's allocated-->optimum but very large overhead
- advertise min and max--> small overhead but difficult to optimize
- propose compromise: advertise per type of signal what is available
Some further challenges remain (e.g. scalability, factoring time
constraints,..)
Conclusion: - need to find compromise between optimum routing and
scalability constraints of ISIS/OSPF
Authors: will integrate OSPF/ISIS extensions with
<kompella-mpls-isis/ospf> drafts to go to ISIS/OSPF WGs
Ping: - this is a lot of info to advertise. Should some info not be
distributed via SNMP or Policy otherwise it won't scale?
Mannie: - Yes. There is a question as to whether ISIS/OSPF are the
right protocols for all that. May be possible in small areas. Plan to
do some simulations.
3. Bundling
Two drafts were presented, kompella-mpls-bundle-02 and
rs-optical-bundling-00. Disposition was deferred until both drafts
were presented.
Kompella kompella-mpls-bundle-02
This draft proposes bundling at the "protocol" level. This is
necessary for routing scalability. Bundling at Layer 1/2, while
scalable, defeats the purpose.
A bundle does not make a bigger link of smaller links. It is simply a
means to advertise many links more efficiently.
The draft proposes a notion of Max LSP bandwidth as a means of masking
the actual bandwidths on particular links. The Max LSP bandwidth is
simply the bandwidth of the largest reservation that could be made at
this point in time at a particular priority. Bundling can be used
with Forwarding Adjacencies, and with unnumbered links. Also
presented were the procedures associated with the use of Link Bundle
and use of Max LSP Bw by Constraint Based Routing.
Proposal: make this a WG document
George (as chair): need first to get consensus on the approach and then split into
different document for the different WGs.
Curtis V: the LSP max bandwidth should depend on the LSP type(L3PID)
because in some case you can split an LSP over the multiple links.
Xxx: does this approach take into account delay?
George: links with different delays have to be in different bundle.
Saha rs-optical-bundling-00
The draft describes the issues that arise when optical links are
bundled, and proposes a rule for bundling optical links. This work is
complementary to the work of kompella-mpls-bundle-02. It proposes
that Bundle be divided into sub-bundles (aka Bundle Groups).
Kireeti: sub-bundle don't buy you much compared to TE bundle
approach. They were useful with unnumbered links but this is
supported with TE bundle.
After a brief discussion, it was agreed that there was general
consensus on using the approach outlined in the kompella draft without
adding sub-bundles. New drafts for the appropriate work groups will
be drafted.
4. Ashwood-Smith ashwood-generalized-mpls-signaling-00
http://www.labn.net/docs/gmpls.pdf has the presentation slides.
In Adelaide a number of drafts on this subject that were presented.
The authors of those drafts agreed to work together to produce
framework, signaling and routing drafts. This draft represents a
consolidation of the signaling aspects.
GMPLS signaling involves extensions to RSVP-TE/CR-LDP to support
traditional statistically multiplexed, time division, frequency
division and space division-multiplexed paths. This draft describes
a generalized label structure (generalized label request, generalized
label, suggested label and label set) for MPLS and new functions: bi-
directional LSP establishment, a generalized notification mechanism
and ingress/egress binding.
Generalized label request specifies the LSP encoding type, link
protection type and G-PID. The generalized label travels in the
RESV/Mapping message. It also supports traditional statistically
muxed labels. It consists of a Link ID and Label.
The Suggested Label is a generalized label that is given by an
upstream node to a downstream node in a PATH/Request message. The
downstream node should try to use this label and pass the same label
back in the Mapping/RESV message.
The Label Set is attached by an upstream to a Request/PATH message
and is used to restrict the choice of the downstream node's label to
this set. It is literally a set of generalized label objects.
Lou Berger presented the new functions that are driven by generalized
switching requirements.
The bidirectional LSP is established by passing an upstream label in
the Request/PATH message. There is a possibility of contention for
the same label when both sides can allocate for the same direction.
The notification function expedites notification of non-adjacent
nodes of LSP events. E.g. may notify ingress of LSP failure to
reduce latency of end-to-end failure recovery.
Egress control enables the ingress of an LSP to control egress
termination. This may be used to splice LSPs. A new "Egress Label"
subobject has been defined.
Going forward, the authors will:
- investigate a better way to signal "LSP Encoding TLV"
- verify SONET/SDH label formats
- allow selection of time slots and lambdas via ERO
- minor editorial and other fixes
- incorporate feedback from this meeting
Once the functionality is stable, they will split the draft to
separate the functional description from protocol formats.
Lou: proposal to accept this as WG document.
George (as chair): Proposed to the group to accept as WG document.
The document was accepted as a WG document. No objections from the
floor.
Floor: suggest to collaborate with ITU on Waveband definition
Peter AS: 100% agreed
5. Guo sorrento-rsvp-bi-osp-00
This draft describes motivations for bidirectional setup of Optical
paths:
- faster set-up
- optical continuity
It proposes a proposal to reduce "contention" window to 1 hop (through
ordering of labels).
Proposal: move this into the generalized mpls signaling draft (in
particular incorporate the pair-wise label allocation)
Jonathan Lang: the contention window is actually removed with the
"label suggestion" or "label set" capabilities of generalized mpls
signaling. So the proposal to reduce the contention window is no
longer useful.
George (as chair): continue discussion on mailing list about whether some
material from sorrento-rsvp-bi-osp-00 should go into generalized mpls
signaling.
6. Bala bala-mpls-optical-uni-signaling-00
This draft reflects work at the OIF.
This draft addresses the "domain services" model for an optical
network. Under this model, the optical network provides a set of
well-defined services to clients (IP and others). The signaling and
routing interface between the client and optical networks is referred
to as the User-Network Interface (UNI). This draft describes the
services provided over the UNI, and the requirements on any signaling
protocol used to invoke the services. It considers both direct and
indirect interfaces. It defines abstract UNI messages and associated
parameters
The objective in presenting this work here is to:
- Guide development of MPLambaS protocols
- Harmonize extensions with OIF
Conclusion:
- identifies a MPLambdaS subset to allow support of a simple
UNI which can later be expanded
- note that the draft reflects ongoing work in the OIF and is
still work in progress
Bala: where does this draft belong?
George (as chair): It is useful to have information from the OIF presented here.
The draft itself is not something to adopt here. Rather it should be
reflected into the actual MPLS WG drafts (i.e. extensions to RSVP-TE
and CR-LDP for UNI). We encourage you to keep bringing up-to-date
information on status of OIF work as guidance to this group.
Ping P: this is similar to RSVP-to-ATM, and UNI concept is not useful
Bala: this is not quite the same thing as ATM, and UNI is useful to
define interface requirements.
7. Aboulmagd aboulmagd-mpls-ldp-optical-uni-00
Create, Delete, Modify and Status Enquiry actions are possible across
the O-UNI. This draft argues that LDP already has well defined
messages to support the O-UNI and there is no need to invent yet
another protocol. A proposal was made to consider this draft as a WG
document.
Xxx: a comment was made that if the IETF is going to follow the OIF's
recommendations, and the OIF was expecting to introduce major changes
to the definition of the UNI. So this is definitely work-in-progress
at the OIF.
Ross Callon: what is the relationship to the generalized signaling
draft? Osama responded that they plan on using as many of the
mechanisms specified in that draft as possible and the intent was not
duplicate work.
Peter Ashwood-Smith stated that it is good idea to adopt the document
as a WG document.
Lou Berger: recommended coordination with the generalized draft.
The document was accepted as a WG document without objection.
8. Lang lang-mpls-lmp-01
Why link management: The control channel may be on a different
medium/link than the component links being controlled. LMP includes
control channel management, link connectivity verification, link
property correlation and fault isolation. The presentation described
the major changes from the -00 version of the draft.
The proposal was made to advance the draft to WG document status.
Greg Bernstein: wanted to do link verification and fault management
differently for SONET than what is specified in LMP. He wanted to
know whether we should change the applicability statement for the LMP
draft. George said that this should be explicitly stated in the
document.
The document was unanimously adopted as a WG work item.
9. Nadeau nadeau-mpls-packet-classifier-mib-01
The goal is to provide FEC to NHLFE mapping for MPLS LSRs. This is
motivated by customer requirements to specify how packets enter the
MPLS domain. The new version is based on comments on the mailing
list, requesting simplifications.
The ClassifierTable defines rules to compare against incoming packets
and an action to be taken on matching packets. The PerfTable
contains performance statistics on packet classifiers on a per
interface table.
Tom asked that the MPLS WG adopt this draft a WG work item. The
request was approved without objection.
Thursday 9:00 - 11:30
10. Le Faucher ietf-mpls-diff-ext-06
First last call on version -05 resulted in a number of comments.
These have been addressed in the -06 version. Second last call
resulted in one comment on the list related to backward compatibility
with LSPs established with pre-Diff-Ext RSVP QoS. A compromise
solution was worked out on the mailing list. Francois presented the
details of this solution. Francois proposed that we incorporate the
text of the resolution in version -07 and he believes that the
document is ready to be sent to the ADs for IESG last call. There
were no comments or questions.
11. Le Faucher lefaucheur-diff-te-reqts-00
lefaucheur-diff-te-ext-00
Requirements for support of Diff-Serv-aware MPLS TE
The requirements draft was presented in the TE WG; the authors are
driving corresponding protocols extensions in the respective WGs
(MPLS, OSPF, IS-IS). Current MPLS TE performs constraint based
routing on a single bandwidth constraint. With Diffserv, there are
additional requirements to ensure the QoS of each class. These
constraints cannot be enforced by current TE model based on a single
bandwidth constraint. This requires extensions to current IGPs to
propagate per-class information. The question was raised whether this
information would place a burden on IGP scalability. The proposal
suggests to aggregate a group of classes into a class-type for
scalability improvements in IGP flooding.
ISIS/OSPF Requirements
- minimize impact on scalability
- Constraint based routing should be able to enforce different
Max Reservable BW for each class type and retains existing concept
of preemption
- CBR should enforce different Max Reservable BW for each Class Type
AND enforce an Aggregate Max Reservable BW
- Support for up to 3 additional Class Types
- IGPs to only advertise the subset of CTs actually used
RSVP/CR-LDP Requirements
- Signal CT at tunnel establishment
- Backward Compatibility
CBR Reqs
- CBR to take into account different unreserved bw for each CT
- CBR may also take into account other constraints for each CT
Francois then went through the protocol extensions to RSVP, CR-LDP.
Then he made the proposal that the MPLS WG hosts the work on RSVP-TE,
CR-LDP and MPLS MIB extensions. The Requirements would be worked on
the TE WG. He also proposed that MPLS accept the reqts-00.txt as a WG
document until it is better homed, and the RSVP/CR-LDP/MIB material of
ext-00.txt as WG document.
The first part of the proposal was accepted by the WG. Dave Oran
asked that the proposal be posted to the Routing Discussion group.
The group also agreed to accept the RSVP/CR-LDP/MIB material as a WG
work item. The final proposal regarding accepting the -reqts-00.txt
was also accepted, based on the understanding that this may get
rearranged once the work gets distributed among the appropriate work
groups. Curtis asked whether the drafts need to be dissected.
Francois responded that the OSPF and IS-IS extensions need to be
broken off into a separate draft.
12. Sharma draft-makam-mpls-recovery-frmwrk-01.txt
This draft provides a framework for MPLS recovery. It also proposes
some evaluation criteria for solutions. The draft has been evolving
for some time. This is the latest update.
Proposal: to accept as WG document on track towards Informational
RFC.
George (as chair): There may be a broader-scope document on recovery
as part of the new Routing Area/Control Plane WG. This document
applies only to MPLS. However there is material in this document that
would be appropriate for a broader-scope document.
Dinesh B: there are a few inconsistencies/redundancies in draft. Will
discuss on list.
Dave O (AD): what is meant by "extensible to Optical" in draft?
George (as chair): just means that the kind of definitions/procedures
could be reused in a separate document for Optical
Dave O: please send comment on what work belongs where on the routing
area list.
The draft was accepted as a WG document.
11. Sharma Path protection
Two related drafts were presented. The first describes the
mechanisms. The second describes protocol extentions for RSVP-TE.
The primary mechanism is the use of a Reverse Notification Tree (RNT)
which is a set of LSP in the reverse direction which merge together as
they intersect on their path to the head end of the tunnels.
A. draft-chang-mpls-path-protection-01.txt
Changes since last version:
- Better defined scope, motivations...
- Completed the features to provide complete solution
- recognized that solution works for both physically and virtually
merged LSPs
- reduced number of timers
- ideas for future extensions:
- mesh based protection, pre-qualified protection
- priority, preemption
- unify ideas for notification mechanisms
B. draft-chang-mpls-path-protection-ext-00.txt
New attribute for EXPLICIT_Route object for path setup and RNT config
Added LABEL_REQUEST object to existing messages
Open Issues:
- where to encode protection options
Proposal:
- move Mechanism draft to WG document
- merge RSVP-TE extensions draft with existing RSVP-TE spec
xxx: concern with reverse notification tree for failure notification
because itself can be subject to failure
Sharma: there is no activity involved in maintaining the reverse
notification tree. It is only states in the hops.
Xxx: so we cannot reliably know if the reverse notification tree is
actually up or not.
Ping: why define new messages than PathErr or ResvErr?
Sharma: see draft. In particular there is not enough space in error
field.
Ping: doesn't see why it cannot be achieved via existing messages
with new codes.
Kireeti: would like to think more on scheme (eg scalability) before
it is accepted
George (as chair): More discussion to take place before making
this a WG document. Since we cannot spend more time on this today,
the discussion is to be continued on the list.
12. Matthews brittain-mpls-ldp-ft-00
LDP extensions for Fault Tolerance: Within an LSR, want to switch from
one LDP stack to another LDP stack without affecting data flow.
Specific examples of applicability are for software upgrade, and for
failure-handling such as switching to a backup control processor.
Solution:
- Let old TCP connection die
- establish new TCP conn and indicate "continue old session"..
defines :
- Sequence numbers and Ack (for Fault Tolerant LSPs)
- Re-sending missed messages
Optional extension to LDP, negotiated as session initialization time
Proposal:
- that draft be accepted as WG document
Dave O: did you look at SCTP for transport of LDP rather than TCP?
Xxx: there has been discussion on list concluding that SCTP was not
mature.
Dave O: would have concluded differently. Let's talk.
Eric R: we shouldn't change the underlying transport protocol for LDP
for which TCP has been standardized for a long time.
Xxx: do we need to standardize such mechanisms which achieve Fault
Tolerance inside a box? cannot inside-the-box mechanisms achieve
FT?
Phillip M: makes FT a lot simpler, very hard to achieve FT with TCP
The draft accepted as WG document without objection.
13. Reichmeyer franr-mpls-cops-00
COPS usage for MPLS/TE
Kick off policy discussion took place in the MPLS WG in Adelaide. Not
a lot of interest then. This draft provides more details to see if
there is more interest now in MPLS WG.
The draft describes the application of the COPS for Provisioning
COPS-PR) protocol for managing TE.
Just to manage TE:
- tunnel set-up
- classification of packets onto tunnels
- LSP tunnel perf monitoring (eg if LSP more than 80% full,
setup another,...)
- Notification
Policy Management Model:
- COPS-RSVP or COPS-PR?
- needs to work for RSVPTE and CRLDP
- policy-wise RSVPTE different from RSVP
Solution proposed in draft is based on COPS-PR. May not be the best
model.
Describes:
- COPS-MPLS model (with PDP)
- exchange between PDP and LSR
- policy on a per-interface basis
Proposal:
- is there interest in the WG
- adopt as WG draft
George:
- policy is not in our charter
- should be driven top-down from the policy
Eric R: this does not achieve anything that cannot be achieved by
existing mechanism (eg SNMP)
Reichmeyer: it optimizes such control
Curtis: TE in real world does not need policy
Brian Carpenter: from IAB, there is not a stable language to specify
PIB yet so it does not make sense to specify a PIB for different
applications until such language is stable enough.
Draft is not accepted as WG document.
Declerc schrijvp-mpls-end-to-end-auth-01
Objective is to achieve end-to-end Auth between Label Edge Routers.
Two procedures (and associated TLVs) described:
- challenge
- digital certificate
Proposal:
- adopt draft as WG document
Dave O: let's assume you have security mechanisms on intermediate
LSRs. Do you need to set-up e2e authorization in situations where you
don't have transitive trust relationship with intermediate LSRs?
Floor: Yes, it is needed
Xxx: agree that there is a need for e2e auth. Would prefer a solution
that would not require message to go 2ways.
Declerc: 2nd method achieves that
Vijay (as Chair): There is agreement in room that this is appropriate
item of work for WG. More discussion on mailing list on solutions
before making it a WG document.
14. Iwata fujita-mpls-crldp-crankback-01
Crankback useful for rerouting upon setup blocking and for
restoration of failed LSP
Changes from previous draft include discussion (in section 2) of
explicit vs implicit rerouting indication.
Discuss some limits of implicit indication (in some cases does not
give sufficient info to achieve rerouting)
Proposes that Explicit notification be used, with following
information encoded in new Codepoint of Status TLV
- where blocking occurs (link ID)
- whether alternate routing should be attempted
Proposal:
- accept draft as WG document for crankback extension to
CR-LDP, OR
- merge with mpls-cr-ldp-00.txt
Billel: not clear what you achieve that cannot be done via te-feed.
Iwata: te-feed is limited intra-area
Crankback draft was accepted as a WG document without objection.
15. Ashwood-Smith daft-ietf-mpls-te-feed-01
This draft aims at improving topology database accuracy with LSP
feed-back. Bandwidth information is fed back to upstream nodes
during LSP set-up and set-up failure.
The draft was first presented in Oslo, and was accepted as WG document.
Two type of comments:
- do not re-advertise info that you learned through feed-back
--> this is agreed and addressed now
- questions about race conditions. Act
---> it actually doesn't matter who win the race
only works within single area, there is room for other mechanisms
that work inter-area (such as crankback)
Future:
- could extend for Diff-Serv-aware capability
- could incorporate some comments from mannie et al
xxx: would it not be useful to feed update info in both directions.
Peter AS: evaluated ideas to send feed-back in both directions and
also to snoop on feed-back on intermediate nodes. Simulation showed
that these other variations did not add much.
16. Peter AS paraschiv-mpls-lsp-query-00
LSP Query for LDP/CR-LDP.
Provide extensive information on established LSPs (path, label at
each hop, free bw at each hop, merge points, future:delay
estimates...)
Adds a Query Object, with a flag for each info requested. Query could
travel on Label Request or Query Message.
Query Reply traveling on both Query Reply message and Label Mapping
message
Proposal:
- to accept as WG document
- to be used to accumulate LSP and CRLDP query requirements and
protocols (eg ASON/Optical)
Eric Gray: have you considered what happens if an LSR does not
support this?
Peter AS: no but it should be addressed.
Draft accepted as WG document without objection.
17. Theimer theimer-tcrtp-mpls-00
Tunneling Compressed RTP in MPLS. Targeted for VoIP Trunking from GW
to GW.
Started from work in AVT to transport compressed RTP in L2TP.
Tunneling Compressed RTP in MPLS has benefits over L2TP approach:
- better overhead
- remove header processing overhead
- get MPLS QoS benefits
- get MPLS protection benefits
There are existing proposals for Header Compression with MPLS. This
draft focuses on end-2-end compression. End-2-end Compression has
many benefits over hop-by-hop. The solution proposed in draft
achieves 80-90% compression but is fairly complex. By contrast,
draft-swallow-,... achieves 52% but is simpler.
Operations:
- use a pair of unidirectional LSPs or use bidirectional LSP
setup if/when supported,
- defines a mechanisms to establish compression over LSP
- apply path constraints to get low-loss
- signaling extensions to RSVP-TE
Some issues:
- state synchronization in case of packet loss, should be
avoided by path-constraints
- complexity is no worse than hop-by-hop
- possible reordering
Proposal:
- it should become a WG document
Andy: points out that draft-Martini provides a mechanisms for
transport of PPP over MPLS that can be used.
Dave O: although processing is same between e2e and hop-by-hop it
would be spent in different locations which matters.
Lou B: there is a need for both e2e and hop-by-hop anyway.
The draft was accepted as a work group draft.
18. Berger ietf-mpls-hdr-comp-over-ppp-00
ietf-mpls-hdr-comp-00
Changes from Adelaide:
- Draft-name
- resolved a bit naming collision
- draft does not assume or preclude support of CRTP enhancements
Again the end-to-end and hop-by-hop approaches are useful: one is CPU
intensive and efficient, one is simple and less efficient.
Vijay: had felt that in Adelaide although it was not stated, it was
implied that this draft were accepted as WG document.
Lou: thought it was said but it is not clear in the minutes anyway.
The drafts are now accepted as WG document.
19. Leu leu-mpls-ldp-label-aggregation-00
The motivation for this draft is to conserve the number of LSPs
needed in a network by aggregating multiple FECs over a single label.
Thus a single LSP carries multiple FECs. This is particularly useful
in ATM since the number of available LSPs may be limited.
Proposal:
- accept as WG document
Curtis: cannot merge LSPs/FECs with different QoS/Diff-Serv
Leu: agreed.
Vijay: could you not achieve this via a new FEC (eg BGP Next Hop)
Peter AS: could it be implemented in the Linux implementation to
demonstrate the benefits.
Ross C: this was discussed some time ago in the context of LDP and it
was concluded that you could achieve that by only advertising
the address of the egress router.
Chairs: More discussion on the list required to clarify applicability
and demo implementation would be very useful. Until it's
utility can be demonstrated, the document is not accepted.
|
|