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

From: "Mustapha Aissaoui" <[email-masked]>
Date: Wed, 9 Mar 2005 12:44:54 -0500

Greg,
maybe you can explain this to me. How does a S-PE compute a path looking
into the same direction as the data flow (I mean user data not PW control
packets) when it is progressing the label mapping message in the reverse
direction of the path to be computed? There is no routing information to use
to form that path.
 
Mustapha.

  _____  

From: Gregory Wright [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2005 12:33 PM
To: 'Mustapha Aissaoui'; 'David McDysan'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt

Mustapha, 

In Bocci, How is the label mapping message selected? LDP would select the
path based on the best route. If Bocci uses this method there is no
guarantee that a connection can be established if no resources are
available. 

In Balus, an S-PE can compute a path looking a resources in the same
direction as the data flow. Using the S-PE list TLV a path other than the
best IGP path can be specified. 

> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mustapha Aissaoui 
> Sent: Wednesday, March 09, 2005 12:09 PM 
> To: 'David McDysan'; [email-masked] 
> Cc: [email-masked] 
> Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt 
> 
> 
> Dave, 
> the method proposed in our draft is a direct response to the 
> fundamental issue that resource availability is not known to 
> the SPE which sends the label mapping message. That is the 
> label mapping message progresses in the reverse direction to 
> the PW path. We think that a controlled fanning of the label 
> mapping message improves the chances of finding one or more 
> paths in the reverse direction. That is, we do not need 
> crankback procedures since we have a built-in exercising of 
> multiple paths. Having said that, it also does not guarantee 
> a path will be found but improves the probability of finding one. 
> 
> The method proposed in 
> draft-balus-mh-pw-control-protocol-00.txt is missing 
> crankback procedures. If the label mapping message is 
> released back to the SU-PE, this latter will need to retry 
> through a different explicit path. How it gets this backup 
> explicit path is still arbitrary since resource availability 
> is not known for the reverse direction. So, Even if crankback 
> procedures are added, it does not solve the problem of 
> finding an alternate path. In other words, the SU-PE will 
> attempt multiple label mapping messages until it finds one or 
> it has exercised all possible combinations in explicit paths. 
> At the end of the day, it does not do a better job than the 
> fanning method in improving the probability of finding a path. 
> 
> Regards, 
> Mustapha. 
> 
> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David McDysan 
> Sent: Wednesday, March 09, 2005 10:29 AM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt 
> 
> Matthew and other co-authors, 
> 
> I read your draft again last night. I think that you are 
> proposing a signaling and routing paradigm that is 
> fundamentally different from that deployed in IP-based 
> networks today. I still have a few questions about the draft, 
> such as how the next hop S-PEs are selected that are in the 
> general desired direction, what happens if nodes fail during 
> the flooding/pruning stage, and what happens in response to 
> major failure or restart events, but in general I see how it 
> could work. 
> 
> Since this approach is so different from our experience with 
> deployments, such an approach requires careful analysis and 
> investigation. Do you have any references that describe any 
> theoretical basis and motivation for such an approach? For 
> example, an interesting result would be simulations that show 
> that in some configurations and conditions that such a 
> "constrained flooding/pruning" approach finds a viable path 
> when other distributed approaches do not may motivate the 
> additional messaging of such an approach. 
> 
> 
> I suggest that the investigation of a new routing and 
> signaling paradigm such as this not be limited to MH PW. For 
> example, this type of approach may be relevant to the 
> inter-AS and inter-area requirements developed by the tewg 
> and might be an distributed alternative for comparison with 
> the primarily centralized approach being pursued by the pce wg. 
> 
> Dave 
> 
> > -----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 
> 
> 
> 
> _______________________________________________ 
> pwe3 mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/pwe3 
> 
> 

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