Subject: RE: draft-balus-mh-pw-control-protocol (was draft-shah-bo cci-pwe3-ms-pw-signaling-00.txt)

From: "Florin Balus" <[email-masked]>
Date: Tue, 8 Mar 2005 20:04:39 -0500

Matthew,
(changed the subject as we are talking about a different draft now)...
As per our presentation in L2VPN WG, procedures for "Quantity and Quality"
of Service Signaling, Reservation are going to be added in version 1 of the
draft. 
Regards,
Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, March 08, 2005 6:18 PM
> To: Loomis, Mike [BL60:NP02:EXCH]
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
> 
> 
> 
> Mike,
> 
> I think my concern is that an S-PE only knows about the 
> resources allocated on its egress tunnels, not its ingress 
> tunnels, but the signalling progresses upstream.  So while it 
> may know reachability information, it may not know the 
> reources available on a given tunnel in its reverse 
> direction. Because of this, you would need a crankback 
> mechanism in draft-balus.
> 
> Best regards,
> 
> Matthew
> 
> 
> 
> 
> 
>                                                               
>                                                               
>             
>                       "Mike Loomis"                           
>                                                               
>             
>                       <mloomis@nortel.         To:      
> Matthew BOCCI/GB/ALCATEL@ALCATEL, "[email-masked]'"  
>                   
>                       com>                     
> <[email-masked]>                                      
>                            
>                                                cc:      
> "[email-masked]'" <[email-masked]>, 
> "[email-masked]'"            
>                       08/03/2005 20:22         
> <[email-masked]>                                               
>                            
>                                                Subject: RE: 
> [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt           
>               
>                                                               
>                                                               
>             
> 
> 
> 
> 
> Hi Mathew,
> 
> 
> I think you overlook a few important distinctions between 
> draft-balus and draft-shah-bocci.  I would not describe 
> draft-balus as a special case, but instead a workable dynamic 
> MH-PWE3 solution that is consistent with defined SH-PWE3.  
> Draft-balus does not flood/prune LM messages - a minor 
> addition of MH-TLV allows S-PE nodes to pick the best path 
> between U-PE and avoid all of the unnecessary 
> flooding/pruning/reservations.  It also stays consistent with 
> the pt to pt paradigm of PWE3 and does not try introduce a 
> new pt to mp PWE3.
> 
> 
> Regards,
> Mike
> 
> 
> -----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

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 9 Mar 2005 07:22:34 -0500

Himanshu,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shah, Himanshu
Sent: Tuesday, March 08, 2005 5:58 PM
To: Wright, Gregory [CAR:NP02:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt

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.
 
FB: We left both options opened in our draft: i.e. pinning or not the
reverse path. That is because there was no clear requirement to do one or
the other in version 00 of MH PW Requirements draft. We'll add the details
for pinning down the reverse path in version 1.  
 
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.
 
FB: As per my previous answer to Matthew the procedures for "Quantity and
Quality" of Service Signaling, Reservation are going to be added in version
1 of the draft. We're looking to re-use the already defined TLVs for the
signaling part, you're being involved with the definition of the one for
Bandwidth/Quantity of service.

/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. 

> From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On 
>                       pwe3-bounces@iet         Subject: 
<https://www1.ietf.org/mailman/listinfo/pwe3>  
<https://www1.ietf.org/mailman/listinfo/pwe3>