RE: [PWE3] PWE3 question

[neil.2.harrison@bt.com]

Thanks Andy,

Well I am only half-convinced by your answer for the following reasons:
-	AFAI can tell, the top-layer (bottom label) LSP is a single-hop MPLS
trail (in all cases).....since architecturally what it is doing is proxying
for a link-connection in whatever client layer technology trail it is
carrying.  Hence, it is only using the extended/targetted LDP p2p
behaviour........which I am at least thankful for because the mp2p behaviour
of full-blown LDP does cause many problems IMO.
-	Given this, if the MPLS network has multiple nodes between IW
devices then one is forced to run some further server layer LSP underneath
this.  Which in itself is fine, as this is nothing more than a true
client/server approach which we will see recurse many times here before we
hit the duct layer.  But if we are to imbue this LSP with
enforeceable/measureable QoS/survivability attributes and fault-management
behaviour (for whatever the ultimate XoverMPLS technology client is being
carried), then this LSP needs to be ER p2p also IMO.
-	Hence, we have not avoided the need to provide an ER p2p LSP at
all....and architecturally you strictly only need a single proper
client/server relationship.

However, I do agree that a consistent approach is useful......so from this
perspective, and ignoring the strict arch relationships, then I can
understand why you may argue for keeping things as some have already decided
to do them.  All I want to show is that it is not a forced architecture.

regards, Neil

> -----Original Message-----
> From: Andy Malis [mailto:Andy.Malis@VivaceNetworks.com]
> Sent: 10 May 2002 01:10
> To: neil.2.harrison; Shahram_Davari; Sasha
> Cc: pwe3
> Subject: RE: [PWE3] PWE3 question
> 
> 
> Neil,
>  
> The point is that LDP used in extended discovery mode for this
> application works perfectly and has great scaling properties.  So why
> specify the necessary changes to anything else?  Interoperability is
> enhanced by choosing one way to do things, especially when it 
> just works
> so well - this reduces implementation and testing costs for 
> vendors, and
> also reduces both capital and operational costs for service providers.
> Capital costs are obvious - operational costs because there's less
> interoperability testing the SPs have to do in their own 
> labs, and fewer
> protocols they have to learn how to provision, operate, and
> troubleshoot.
>  
> Cheers,
> Andy
> 
> 	-----Original Message----- 
> 	From: neil.2.harrison@bt.com 
> 	Sent: Thu 5/9/2002 18:49 
> 	To: Shahram_Davari@pmc-sierra.com; Sasha@axerra.com; Andy Malis 
> 	Cc: pwe3@ietf.org 
> 	Subject: RE: [PWE3] PWE3 question
> 	
> 	
> 
> 	Interesting point Shahram.....I'd also like to know why LDP
> seems to be the
> 	only signalling prtocol that seems to be sanctioned by
> some......for example
> 	draft-martini-l2circuit-trans-mpls-09.txt says 'static' MAY be
> used, but if
> 	signalled it MUST be via LDP.  I can see the VC_LSP is just
> 1-hop = single
> 	link-connection of the client trail, so is it just 'because it
> might be
> 	easiest/cheapest'....or are there any other reasons for this?
> And
> 	specifically, *why* is any other form of VC LSP signalling
> postively
> 	disallowed?
> 	
> 	regards, Neil
> 	
> 
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3