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

From: "Florin Balus" <[email-masked]>
Date: Wed, 9 Mar 2005 13:04:44 -0500

Replying to everybody this time. Sorry about that..
And  Mustapha thought I was being nice with him! :)

> -----Original Message-----
> From: Balus, Florin [CAR:6955:EXCH] 
> Sent: Wednesday, March 09, 2005 12:57 PM
> To: 'Mustapha Aissaoui'
> Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
> 
> 
> 
> Mustapha and all,
> First of all your solution is based on a Mp2pt PW concept 
> which needs to be defined. If this solution is to be pursued 
> I think the problem should be decomposed in the following way: 
> 
> a) Define new concept: "multipoint to point pseudowire 
> (mp-pw)". This needs to be described separately from multihop 
> pw. and one can argue that besides the technical aspects, a) 
> is currently out of scope in the PWe3 charter 
> b) Describe "How to use MP-to-point PW to implement MH-PW". 
> "b)" depends whether a) is defined, accepted 
> 
> See also in-line...
> 
> > -----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.
> 
> As per Dave's comments in a failure scenario, I see a big 
> problem with the reservation of resources during this state.  
> Consider a condition where a whole bunch of pseudowires are 
> trying to come up at the same time. Many will get rejected 
> due to the large number of temporary reservations that will 
> exist until the label release occurs. So your solution is not 
> workable. 
> 
> > 
> > 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.
> 
> As we stated in the L2VPN session, we are going to address 
> these items in the next version of the draft. Do not make 
> assumption about what we can or can't do. If you're in rush 
> to debate that aspect, feel free to join our draft and we are 
> going to share with you the details.
> 
> > 
> > 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