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

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Mar 2005 12:24:51 +0200

Richard and all,
I think that most of the concerns expressed by Richard
in his email are valid.

I'd like to add a couple of my own:

1. Multiple MS-PW Paths Going Through the Same S-PE
===================================================

The draft does not explicitly define that an S-PE that
has already received and transferred forward a mapping 
for the given tuple of {SU-PE, TU-PE, PW ID}
becomes unsuitable for repeating this operation. 
So more that one set of stored information can match
a given tuple (used as a key).

In this case. when the backward label mapping for this tuple 
is received, how does the S-PE decide which item should be
retrieved and progressed along the backwards path?
(Note that the rest of mappings should be released to avoid
leakage...)

2. How can TU-PE Select the Path?
=================================

When a TU-PE receives the first forward label mapping
for a given MS-PW, it cannot know, whether this
is the only label mapping it can use, or more mappings
are to follow. So the obvious way for the TU-PE to react
seems to "accept the first offer" and release all the
others. 

IMHO this is the ONLY method really available to the TU-PE
since the label mappings it receives do not carry any
information about the MS-PW path they represent (well,
the last segment is known, but this is not much since in
many cases it will be the same for all mappings).
Overcoming this with, say, recording each S-PE on the 
forward path in an appropriate TLV in the label mapping
message could probably help (and also could help
to prevent paths with loops), but smacks too strongly
of RSVP-TE to me.

Hopefully these comnments will be useful.

Regards,
                                  Sasha Vainshtein
email:                         [email-masked] <mailto:[email-masked]> 
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2005 8:34 AM
> To: [email-masked]
> Subject: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
> 
> 
> 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
> 
>  
> 
>