Subject: RE: Expanded ERO draft

From: [email-masked]
Date: Wed, 28 Feb 2001 22:03:58 -0000

Bora....I read the draft and did indeed note that backwards compatibility
had been addressed.  However, I raised this issue since it had not come up
in discussion, and if there was a valid reason to object to the proposal
this would be it.  If this is not the case, then I cannot see any strong
reason for *technical* objection.  It therefore seems to me that the matter
should be decided on the basis of whether the EERO solves any
problems/deficiencies of the existing ERO case.  I think that is the key
challenge.

BTW - The issue I raised in the previous mail on fast-prot-sw is still valid
IMO, though we can park that for now since its a different problem.

regards, Neil   

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: 28 February 2001 15:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Expanded ERO draft
> 
> 
> 
> Neil
> 
> Just to follow up on your email:
> 
> 1) There are no backwards compatibility issues by using the EERO. We
> devoted a section of the draft to this matter. The main reason for
> defining a new object was to avoid backwards compatibility issues.
> 
> 2) The main motivation for this draft is to make ERO 
> processing simpler
> and to make parsing of an ERO quick and "obvious"
> 
> I think just the clarity of the EERO sub-objects is worth 
> thinking more
> seriously about this draft.
> 
> Bora
> 
> On Wed, 28 Feb 2001 [email-masked] wrote:
> 
> > Kireeti Kompella [mailto:[email-masked]] asked on 27 
> February 2001
> > 22:24
> > > Who all think that adding a router ID to the unnumbered 
> ERO subobject
> > > would be beneficial?  A simple yes, no or don't care, please.
> > 
> > I don't think a simple Y/N/DC vote is good enough....the 
> vote has to be
> > supported by rationale.
> > 
> > Having carefully followed the discussion I come to the 
> conclusion that (i)
> > there appear to be some advantages to doing what Bora et al 
> are advocating,
> > and (ii) there are no technical disadvantages (or at least 
> none have been
> > stated that I can see....other than a clear reluctance from 
> a few parties to
> > accept a change, which is fair enough if there are serious backwards
> > compatibility issues).
> > 
> > Having said that.....
> > I think the biggest advantage is *clarity* of nodal identifier and
> > interface.  I am reluctant to buy too hard into the 
> fast-reroute arguments
> > since:
> > -	it will not cater for all possible failure modes (but 
> only, I assume
> > , below MPLS-layer failures, eg SDH)
> > -	since an intermediate LSR in a LSP is *not* a trail termination
> > point there are some defect handling issues that are not 
> being considered,
> > eg there should be a FDI from the failed LSP segment which 
> gets merged with
> > the 'new' (rerouted) LSP segment.....and since the CV flow 
> will split (at
> > point where new reroute starts) to take the new rerouted 
> segment then
> > (ideally) the FDI should be suppressed from the failed 
> segment at the
> > downstream merge point.
> > 
> > The above can be circumvented by always establishing a 
> completely new
> > server-layer LSP between the nodes where one wants to establish a
> > prot-route....and this would have its own CV flow, disjoint from the
> > (protected) segment of the client LSP.
> > 
> > So, in conclusion:
> > -	do it for clarity *and* if true technical benefits result
> > -	don't do it if any backwards compatibility is evident 
> and there are
> > no strong benefits....so are any backwards compatibility problems?
> > -	don't do it for fast-rereoute reasons since (IMO) such a device
> > appears to be architecturally flawed.
> > 
> > neil 
> > 
>

---

From: "Junaid Ahmed Zubairi" <[email-masked]>
Date: Wed, 28 Feb 2001 17:50:48 -0500

extended abstract due March 12th
CALL FOR PAPERS
INVITED SESSION ON BANDWIDTH AND SERVICE QUALITY
MANAGEMENT IN THE INTERNET

5th World Multi-Conference on 
Systemics, Cybernetics and Informatics (SCI 2001)

Orlando, Florida, USA

July 22-25, 2001

Scope
Internet is undergoing a major transformation from being a 
best effort network to a well organized and well managed 
system with built-in intelligent protocols to provide predictable 
performance. Internet Engineering Task Force (IETF) has 
developed and incorporated a number of new protocols and 
techniques for managing and allocating network bandwidth 
and supporting service quality. For bandwidth allocation and 
management, COPS (Common Open Policy Service) clients 
and servers work to convey policy decisions and allocate and 
recover bandwidth across a domain. For QoS, RSVP provides 
quantitative guarantees by reserved paths and Diffserv provides 
qualitative assurances by using PHB (per hop behavior) and 
PDB (per domain behavior) for packets marked with DSCP 
(DS codepoints). MPLS installs LSP's (Label Switched Path) 
that satisfy Traffic Engineering requirements. As LSP's are set 
up and released, the available bandwidth metrics for various 
links are updated to reflect the current state of the network. 

An invited session on managing bandwidth and service quality 
through these new protocols and techniques is being organized 
at the SCI'2001 conference. This session will serve as a forum 
to present and discuss the latest research and simulation results 
of works by researchers and developers across the world. 
Topics of interest include, but are not limited to:

Bandwidth management with COPS and MPLS
Effects of shaping and packet coloring on multimedia streams
Integrated operation of Intserv and Diffserv
Aggregation of flows for scaling of RSVP
VoIP performance over Diffserv networks
Traffic Engineering architecture for the Internet
Impact of congestion resolution schemes on QoS traffic
Voice over MPLS
Performance of RSVP-MPLS architecture
FR/MPLS Network and service interworking
Inter-provider MPLS signaling and LSP routing
Inter-domain tunneling rules
COPS Policy Server/Bandwidth Broker implementation issues

Paper Submission
Extended abstracts or paper drafts should be sent as per the 
following format:
1. Extended abstract of 500 to 1500 words or paper drafts of 
2000 to 2500 words, in English.
2. Names, addresses, telephone numbers, fax numbers and 
e-mail addresses of all authors, with the name of the contact 
author underlined.

The abstracts or papers can be submitted in ps or pdf format 
to session organizer at [email-masked] by March 
12th, 2001 via email. 

Proceedings
Accepted papers, which should not exceed six single-spaced 
typed pages, will be published by means of paper and electronic 
proceedings. Best papers will be selected for awards and 
recommended for journal publications.
Multiple author books will be published by IIIS, based on the 
best-invited sessions, the best focus symposia or the best 
mini-conferences 

Session Organizer:
Dr. Junaid Ahmed Zubairi
Department of Mathematics and Computer Science
College at Fredonia, State University of New York
Fredonia, NY 14063, USA
Tel: +1-716-673-4694
Fax: +1-508-256-8324
Email: [email-masked]
WWW: http://www.cs.fredonia.edu/~zubairi

Session Co-organizer:
Wajdi Al-Khateeb
Electrical and Computer Engineering Department
Kulliyyah of Engineering, Intl' Islamic University Malaysia
Jalan Gombak, Kuala Lumpur 53100, Malaysia
Tel: +603-2056-4574
Fax: +603-2056-4853
Email: [email-masked]

Important Dates: 
Extended Abstract/Draft Paper due: March 12th, 2001 
Notification of Acceptance: March 20th, 2001 
Camera read copy due: April 13th, 2001 

If you have questions concerning session paper submission 
or session content, please contact the invited session 
organizers at the addresses above. 

If you have questions concerning conference paper 
submissions or program, please contact Conference 
General Chair Prof. Nagib Callaos by email at 
[email-masked] (Academic) or [email-masked] 
(Personal). For further information, see conference web 
site at http://www.iiis.org/sci