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

From: Maarten Vissers <[email-masked]>
Date: Fri, 04 Jul 2008 10:57:13 +0200

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Jul 2008 12:22:22 +0200

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

> 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,
> 
> 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 
> What I describe is part of normal network 
> engineering/resource management in at least some packet 
> transport networks.
> 
> Regards,
> Maarten
> 
> 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Jul 2008 20:11:49 +0200

Well, I suggest that we document this clearly and explicitly in the
document. When the document will go through Last Calls people will judge
if this is acceptable. I think it is not, but I may be on the wrong side
of the consensus. 

Dan

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2008 6:58 PM
> To: Romascanu, Dan (Dan); [email-masked]
> 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 
> 
> Sent: 06 July 2008 12:22
> To: Maarten Vissers; [email-masked]
> I think that I understood you well from the start. And I 
> still don't like it. 
> 
> 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 
> 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
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Maarten Vissers
> > 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).
> > 
> > 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
> > 
> > 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
> > 
> >