Subject: [PWE3] [Fwd: Re: WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt]

From: Stewart Bryant <[email-masked]>
Date: Mon, 21 Jul 2008 14:28:41 +0100

Subject: RE: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt
From: Maarten Vissers <[email-masked]>
To: [email-masked]
Date: Fri, 18 Jul 2008 18:11:18 +0200

 Stewart,

Can you forward this email to the pwe3 mailing list for me. 
The pwe3 list server keeps rejecting most of my emails.

Thanks,
Maarten

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: 16 July 2008 17:58
To: 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Dan,

In my proposed solution there is **no** response to a temporary congestion
occurrence necessary. The network design and the traffic engineering that is
associated with every service addition takes care of the correct operation.
Congestion is now a calculated risk, and typically only affects the
Yellow/discard eligible packets.

It is as such very scalable and reliable.

Regards,
Maarten 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: 06 July 2008 12:22
To: Maarten Vissers; [email-masked]
Subject: RE: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Marten,

I think that I understood you well from the start. And I still don't like
it. 

The response time of such a congestion management solution is (5/10/15
minutes) + (time for retrieval of counters or alarm message to make it to
the NMS in the whatever congestion conditions exist on the management
network) + (time it takes to the operator to get this information and make a
decision) + (time to transfer reprovisioning of links or routing
reconfiguration commands to all involved devices in the whatever congestion
conditions exist on the management network). 

This is one of the reasons that I think that such a solution does not look
as satisfactory to me. Response times of five minutes and higher do not seem
to me to be what is expected from a congestion management solution. What you
are describing may be 'part of normal network engineering/resource
management in at least some packet transport networks' but network
engineering and congestion management are not the same thing, they work at
different time scale, and what is acceptable in network engineering does not
seem to be acceptable as a congestion management solution. 

Note that beyond the issue of response time I have doubts about scalability,
reliability, and fault localization analysis. I believe that this needs more
analysis before it is accepted as a congestion management solution if at
all. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Maarten Vissers
> Sent: Friday, July 04, 2008 11:57 AM
> To: [email-masked]
> Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt
> 
> Retry...
> 
> Dan,
> 
> You have misunderstood my words. Let me clarify.
> 
> Packet based links often contain OctetsTransmitted counters, of which 
> the value can be stored every e.g. 5/10/15 minutes and presented to 
> NMS for resource management/network engineering purposes. These values 
> are analysed by NMS tools to determine the actual link load.
> 
> When the load on a link increases and passes a threshold, the operator 
> can get a warning indicating that in the near future this link may 
> experience congestion. There is now enough time for the operator to 
> either increase the link capacity, add an additional link, or to 
> schedule a reroute of some services (e.g. PWs, HVPLSs).
> 
> If there is a sudden congestion (typically only temporarily
> present) before the operator has taken one of the above mentioned 
> actions, some of the packets (typically the Yellow/EIR packets) will 
> be discarded at the ingress port of the link. This does not present 
> any problem, and no immediate reaction from the operator is as such 
> required.
> 
> What I describe is part of normal network engineering/resource 
> management in at least some packet transport networks.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: 01 July 2008 13:22
> To: Maarten Vissers; Yaakov Stein; Stewart Bryant; Danny McPherson
> Cc: [email-masked]
> Subject: RE: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt
> 
>  
> 
> Making a Network Management application that monitors link load and 
> reprovisions the PWs part of the congestion management framework is a 
> very problematic design. There are many reasons why such a solution 
> should be discouraged, to start with the fact that the congestion can 
> impact the management traffic itself.
> 
> My 2 agorot. 
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > 
> > Furthermore, netowrk management will monitor the actual load on the 
> > links and will receive indications when the load is
> increasing and/or
> > crosses a threshold. Then either the link capacity will be
> increased
> > or some of the PWs are rerouted over another link.
> > 
> > Regards,
> > Maarten
> > 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3