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

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 11 Mar 2005 03:27:45 -0500

Hi Sasha,

Missed you at IETF. Seems like your daytime job is
keeping you busy.....

I had trouble getting access to my emails at IETF. And then
lots of emails got exchanged on this subject, but I don't
think you were responded to. So here it is

Thanks for your comments. 

A bit of background before responsing to your specific 
comments. We started discussing this 
approach in last October after we overviewed how MH-PW
signaling would work in the PWE3 mailing list. Following
from the archive, is the email I sent on Oct 13, 2004 under 
"RSVP-TE and PW" subject on PWE3 mailing list.

====
"Peter,

I believe that by using a target-PE TLV in optional field
of PWE3 control signaling, one can achieve what you are 
looking for. This additional target-PE TLV will contain the 
IP address of target-PE and some other stuff, if needed.

This along with QOS TLV as defined in shah-pwe3-pw-qos-signaling
draft would enable each intermediate PE to find the next hop
and a suitable transport tunnel to the next hop, all the way to
the destination PE. In short, starting from source, based on 
the destination, each PE hop forwards the pwe3 control signal to 
the next hop and responds to the previous hop with the pw label,
and programs the FIB for PW label switching.

Do you think this meets the requirements?

/himanshu"
======

Some of us, Me, matthew, mustapha and eric, thought that we should
put out a draft before IETF meeting but deadline for November meeting
was fast approaching and there were other issues with the proposal to
be resolved. Well we couldn't work on it until this meeting either and
some of the thoughts did not get clarified properly due to last minute
rush for this meeting.

Here is what we think we should have clarified a bit more.
1) Flooding - We never meant indiscriminate flooding; at the most 2
   at each S-PE hop - only to increase the probability of finding a 
   TE path. Alternative was to design E-BGP-TE type of protocol or crankback
   procedures which are likely not to work efficiently for MH-PW.
2) Use of IP address list TLV as ER list or RR list - to prevent far
   side looping. We had the text in earlier version of the draft but
   took it out during one of the revision in favor of keeping things simple
   in the first version. We intend to put it back.

Now response in line below about your comments preceeded by himanshu>.....

regards,
himanshu

Mathew

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2005 5:25 AM
> To: [email-masked]'
> Cc: [email-masked]; Shah, Himanshu; Matthew Bocci (E-mail)
> Subject: RE: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
> 
> 
> Richard and all,
> I think that most of the concerns expressed by Richard
> in his email are valid.
> 
> I'd like to add a couple of my own:
> 
> 1. Multiple MS-PW Paths Going Through the Same S-PE
> ===================================================
> 
> The draft does not explicitly define that an S-PE that
> has already received and transferred forward a mapping 
> for the given tuple of {SU-PE, TU-PE, PW ID}
> becomes unsuitable for repeating this operation. 
> So more that one set of stored information can match
> a given tuple (used as a key).
> 
> In this case. when the backward label mapping for this tuple 
> is received, how does the S-PE decide which item should be
> retrieved and progressed along the backwards path?
> (Note that the rest of mappings should be released to avoid
> leakage...)

himanshu> There are two things here. A local policy on S-PE
himanshu> dictates whether it would allow propagation of more
himanshu> than one copy of same LM of the same tuple - perhaps
himanshu> from the different upstream PE. 
himanshu> However, we do allow duplicate copy to pass through,
himanshu> in order to create a backup PW path which may partially
himanshu> overlap with primary PW path. Again, local policy may
himanshu> prevent this, causing backup PW be path-negate of 
himanshu  primary PW path.
himanshu> We have introduced a Peer PW-ID concept. Hope we could
himanshu> have clarified this a bit more. The 'Peer PW-ID' is 
himanshu> dynamically allocated and represents a specific instance
himanshu> of LM message. So in a two-dimensional data structure, 
himanshu> (SU-PE, TU-PE, MS-PW-ID) tupple fetches the main structure
himanshu> and Peer PW-ID an instance of LM record within it.
himanshu> Note that downstream PE always uses peer PW ID of the
himanshu> sender of the LM, in LR msg.

> 
> 2. How can TU-PE Select the Path?
> =================================
> 
> When a TU-PE receives the first forward label mapping
> for a given MS-PW, it cannot know, whether this
> is the only label mapping it can use, or more mappings
> are to follow. So the obvious way for the TU-PE to react
> seems to "accept the first offer" and release all the
> others. 
> 
> IMHO this is the ONLY method really available to the TU-PE
> since the label mappings it receives do not carry any
> information about the MS-PW path they represent (well,
> the last segment is known, but this is not much since in
> many cases it will be the same for all mappings).
> Overcoming this with, say, recording each S-PE on the 
> forward path in an appropriate TLV in the label mapping
> message could probably help (and also could help
> to prevent paths with loops), but smacks too strongly
> of RSVP-TE to me.

himanshu> Here again we have introduced "forwarding priority index"
himanshu> construct in the MS-PW TLV. TU-PE may set FPI value based on
himanshu> FCFS, TTL, available QOS TLV, etc when advertising LM in the reverse
himanshu> direction. If another LM was to arrive at TU-PE, a different
himanshu> FPI value can be set. We do not recommed that TU-PE to refuse
himanshu> first LM message to arrive in the forward direction because there
himanshu> may not be other. However, TU-PE may apply selection criteria for
himanshu> the subsequent ones.
himanshu> As I mentioned abve, we took the IP address list TLV construct out
himanshu> from the first version for simplicity sake. But we did envision
himanshu> use of S-PE address list as one of the criteria for selection
himanshu> as well as setting FPI.
himanshu> True, this sounds similar to RSVP-TE, but RSVP-TE has a lot of other
himanshu> baggage and don't forget it requires some TE routing protocol
himanshu> to go along with it.

> 
> Hopefully these comnments will be useful.
> 

himanshu> Yes Indeed.

regards,
himanshu

> Regards,
>                                   Sasha Vainshtein
> email:                         [email-masked] 
> <mailto:[email-masked]> 
> phone:                       +972-3-7569993 (office)
> fax:                            +972-3-6487779
> mobile:                      +972-52-8674833 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, March 08, 2005 8:34 AM
> > To: [email-masked]
> > Subject: [PWE3] draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
> > 
> > 
> > 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