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

From: [email-masked]
Date: Tue, 8 Mar 2005 23:17:31 +0000

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