Subject: draft-shah-bocci-pwe3-ms-pw-signaling-00.txt

From: [email-masked]
Date: Tue, 8 Mar 2005 06:34:22 -0000

At the core of this draft is a proposal to set up MS-PWs by flooding LDP PW label mapping messages to all or a subset of LDP peers in order to avoid performing any kind of MH-PW routing. To be honest I’m surprised this has even been considered and I find it hard to get past this and read the rest of the draft. 

I would have thought it was pretty obvious that flooding does not scale. First of all, for mesh topologies some sort of split horizon mechanism would have to be used to ensure S-PEs in a mesh do not send label mapping messages received from S-PEs belonging to the mesh to the other S-PEs in the mesh. The draft does not address this issue, but let’s say this issue is addressed and I have a core with a full mesh of say 100 S-PEs, each connected to multiple U-PEs (which are dual homed). If I use flooding to set up a MS-PW with 1+1 protection, then in the core I need to send 100 LDP LM messages, 98 of which will result in 98 label release messages. Now lets say I want to set up 500 MH-PWs, again with 1+1 protection (although in reality I might not need to protect all of them), that’s 50,000 LDP LM messages I need to send in the core, 49,000 of which will result in 49,000 label release messages.

To be fair, the draft does state “In general, the set of T-LDP peers that are selected will be gateways to next PSN domain along the path to the TU-PE.” and therefore the intention may be to only use this approach for topologies where there are only a few S-PEs, but even this has issues. For example, I assume that bandwidth is reserved for each MS-PW (in the backwards direction) at each S-PE as the LDP LM messages are flooded across the network. Once the path has been selected, label release messages will be sent back to peers that are not part of the chosen path, which will also result in the reserved bandwidth being released. Now, during the time period for which bandwidth is reserved for paths that won’t actually be used, MH-PWs that could have been set up using that bandwidth may be rejected due to there not being sufficient bandwidth available. As the number of S-PEs in the network and number of MS-PWs to be set up at any one time increases, so too does the amount of bandwidth being unnecessarily reserved stopping legitimate MS-PWs being set up.

An alternative would be to only reserve bandwidth when signalling in the reverse direction once the path has been selected. However, this also has problems as the bandwidth that was available at the time that the signalling message was received in the forward direction, may not necessarily be available when the LDP message is received in the reverse direction (due to it since being taken by other MS-PWs). If the bandwidth is not available at this stage, then a label release would need to be sent and the whole flooding process would have to start again. 

There may be a small number of cases where this solution may work OK, but in general, flooding does not scale and introduces serious security concerns (i.e. this solution would make a great tool for initiating a DoS attack). IMO this solution is not acceptable; we should be concentrating on defining a scalable dynamic MS-PW signalling solution suitable for all network topologies. Two alternative draft solutions that I believe have the potential to address this requirement are ‘draft-raggarwa-rsvpte-pw-01.txt’ and ‘draft-balus-mh-pw-control-protocol-00.txt’.

Regards,

Richard

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