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

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

Retry... 

Stewart,

Many packet transport networks have PWs from a mid point in the netowrk to
another far end mid point in the network. The first and last parts of the
network (access and metro edge) are often using Ethernet. When you would
need to perform congestion management is suchnetworks, you would need to
involve also for p2p services the Ethernet netowrk and thus IEEE 802.1.

Furthermore, congestion may occur on a link between two P nodes. Those P
nodes have no PW or HVPLS awareness. This implies that congestion
notifications must be inserted in the tunnels, and when those tunnels
teminate in a PE, the congestion notification in the tunnel must be
converted into congestion notifications in each PW and HVPLS ('M-VLAN').
When a PW terminates at a midpoint in the netowrk, the congestion
notification in the PW must be converted into a congestion notification in
the Ethernet VLAN carried inside the PW.

To get such mechanism operational an operator has to replace all existing P
and PE nodes by new ones that support such congestion notification
maintenance signals.

And what should be the consequent action at a (MPLS or Ethernet) T-PE on
reception of such congestion notification maintenance signal? Should it
reconfigure the CIR/EIR parameters in the Traffic Conditioning function
located on the UNI-N port? If this would be done, then you would not longer
be compliant with the SLA. Furthermore, poor man's connection admission
control and traffic engineering will result in non-discriminatory
degradation of many services... Not something that make you a popular
transport service provider... i.e. as customer you don't get what you pay
for.

Additional OAM (congestion notification maintenance signal) can not resolve
a poor man's connection admission control and traffic engineering problem.

Let us as such not go this direction. It is a waste of time.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maarten Vissers
Sent: 01 July 2008 12:36
To: [email-masked]
Cc: 'Stewart Bryant'; 'Yaakov Stein'; [email-masked]; 'Danny McPherson'
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Stewart,

Congestion management is typically very complex to do it good.
ATM has its congestion management; I am told that it is complex and not well
functioning.
IEEE 802.1 is developing a congestion management extension, but this was
only supported when its use is strictly limited to a data center.

MS-PWs will provide world wide connectivity.
H-VPLS will also provide world wide connectivity.

Both MS-PW and H-VPLS instances will be carried over MPLS Tunnels.
Both MS-PW and H-VPLS needs thus to support congestion management.
H-VPLS isntances are VLAN instances, which use a MPLS Label Stack Entry
header instead of a VLAN Tag; i.e. a kind of a MPLS labelled VLAN (M-VLAN).

If you want to introduce congestion management, you have to do this also in
those M-VLAN (H-VPLS) instances. It is known that 802.1 does not support
congestion management beyond the data center. So any addition of congestion
management to MS-PWs does not solve the problem in the IP network.

It is better to solve this issue by not deploying MS-PW/H-VPLS instances in
such IP netowrk.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: 01 July 2008 12:22
To: Maarten Vissers
Cc: 'Yaakov Stein'; 'Stewart Bryant'; 'Danny McPherson'; [email-masked]
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Maarten Vissers wrote:
> Yaakov,
>
>   
>> We should be able to enable the PWs to be guaranteed their CR, and to
>>     
> enjoy
>   
>> excess traffic when BW is available. 
>>     
>
> I fully agree with you.
>
>   
>> When congestion occurs, we should be able to tell the ingress PEs 
>> that
>>     
> this
>   
>> is the case, and that they should police to their CR. 
>>     
>
> I very much disagree with you here.
>
> Any PW should have at its UNI-N a Traffic Conditioning function that 
> enforces the CIR/EIR of the service. Furthermore, connection admission 
> control and traffic engineering should guarantee that links inside the 
> transport network do not have unexpected congestion conditions.
>
> When congestion occurs this is per network design; the excess rate 
> traffic (marked as discard eligible) will be discarded. If the network 
> design includes committed rate based oversubscription of links, then 
> also committed rate traffic may experience congestion and some of 
> those packets will be discarded as well. No need to do anything 
> special in the PWs. In a well engineered network such conditions will 
> be
very rare.
>
> 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.
>
>   
Maarten

I agree that in a well designed network congestion will only occur very
rarely, but we do need to cope with those cases when severe congestion does
occur. 
Indeed
G.8113 recognizes the need to include detection for such events.

In most IP networks the path is always shortest path and reroute to a
lightly loaded path is not an option. In those circumstances we need the PE
to take the load off the net by its own independent action, if necessary by
shutting down the PW.

Including this mechanism in an equipment deployed on a well designed network
does no hard, because on such a network it will only get invoked when the
network departs from the planed operational state.

Stewart

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 08 Jul 2008 17:35:51 +0100

Maarten & PWE list,

I'm primarily interested in providing the necessary standards so that 
some of the stuff that is currently done by OAM (as Maarten describes 
well) can be done in-band. I'd rather 'let the market decide' than 
make assertions about which is better. But the market can only decide 
if good standards exist.

In order to do what you describe below (feeding congestion 
information up out of tunnels, or from ethernet/MPLS up to IP) there 
are problems with the way congestion notification has been defined 
for tunnels so far. I'm currently updating this draft with the aim of 
unpicking the outstanding issues:
"Layered Encapsulation of Congestion Notification"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#ecn-tunnel>

It widens what we did in RFC5129 for MPLS-IP congestion notification, 
to make it applicable for IP in IP tunnels which are currently 
defined differently from IPSec tunnels. It also gives guidance on 
carrying future Ethernet congestion notification up the layers.

We allowed this -00 draft to sit dormant for a while (with the 
transport area directors' agreement) until potential interactions 
with PCN would be clearer. We now have some consensus forming around 
PCN wire encoding, so I intend to get this encapsulation of 
congestion draft updated for the deadline on Monday.

If you believe this will be useful for the PWE efforts (I believe it 
will), pls let the tsvwg chairs know, so we can get this draft on the 
agenda as a WG item.

Also note that pre-congestion notification (PCN) drafts are coming 
along nicely. Using virtual queues would allow you a bigger cushion 
for sorting out a PWE that's imminently causing problems.
<http://tools.ietf.org/wg/pcn/>

Bob

>network departs from the planed operational state.

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196