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

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 8 Mar 2005 17:58:29 -0500

There are two issues here.
 
If each U-PE selected the 'best' path next hop on its own, there is a risk
of forward and reverse path taking different path which must not happen
for co-ordinating the OAM efforts.
 
Secondly, there is a risk that best path as determined by each hop (i.e. S-PE)
may not be the best next hop. The signaling flows in the opposite direction of
the data flow and an S-PE's reverse path tunnel information is unknown during
the selection.
 
/himanshu

________________________________

From: [email-masked] on behalf of Gregory Wright
Sent: Tue 3/8/2005 3:39 PM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt

Matthew, In draft Balus, the downstream U-PE can determine the best path within its domain for the direction of the PW. When traversing domains, the normal "best path" limitations come into play. 

> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked] 
> Sent: Tuesday, March 08, 2005 1:23 PM 
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Subject: Re: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt 
> 
> 
> 
> Hi Richard, 
> 
> Thanks for your comments. 
> 
> I think that one key problem that any LDP based solution has 
> to address, if indeed we are to have an LDP solution, is to 
> what degree we want to change the current downstream 
> unsolicited behaviour of the PW control protocol. If the 
> downstream U-PE is the initiator of the signalling, then that 
> PE does not have visibility of the best path, in the 
> direction of traffic flow, for that direction of the PW. 
> 
> The "source route" can therefore not be chosen dynamically by 
> the downstream U-PE in such a way as to be useful for traffic 
> engineering. However, it is certainly desirable to be able to 
> contrain the number of S-PEs to which a downstream PE floods 
> the label mapping message. I think the choice of next-hop 
> S-PE therefore needs to be a policy decision, either 
> implicitly by each S-PE, or explicitly in a route list. 
> Please note, though, that the next hop will be chosen based 
> on rechability of the U-PE, so there will not be flooding to 
> all S-PEs in the full-mesh case. So, a combination of U-PE 
> reachability and policy is used to constrain flooding. 
> 
> If draft-balus is still using downstream unsolicited 
> signalling (it was not clear from the draft if this was the 
> case or not), then it becomes a special case of 
> draft-shah-bocci. However, if not then I believe this is a 
> significant change to the way that the PW control protocol works. 
> 
> 
> Best regards, 
> 
> Matthew 
> 
> 
> 
> 
> 
>                                                               
>                                                               
>             
>                       richard.spencer@                        
>                                                               
>             
>                       bt.com                   To:      
> <[email-masked]>                                               
>                   
>                       Sent by:                 cc:            
>                                                               
>             
>                       pwe3-bounces@iet         Subject: 
> [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt           
>                   
>                       f.org                                   
>                                                               
>             
>                                                               
>                                                               
>             
>                                                               
>                                                               
>             
>                       08/03/2005 06:34                        
>                                                               
>             
>                                                               
>                                                               
>             
>                                                               
>                                                               
>             
> 
> 
> 
> 
> 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 
> 
> 
> 
> 
> 
> 
> _______________________________________________ 
> pwe3 mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/pwe3 
> 
> 

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