Subject: RE: draft-raggarwa-rsvpte-pw-01.txt

From: [email-masked]
Date: Wed, 23 Mar 2005 21:13:55 -0000

> We already have  two PW setup protocols, and there  has been 
> no demonstrated need for a third.
NH=> Why do 'PW set-up protocols' have to be different?
> 
> Anyone who  thinks that  this draft is  even worth 
> considering  should first attempt to attain consensus on  the 
> requirements for the traffic engineering of multi-segment  
> pseudowires.  Then they should be  prepared to demonstrate 
> that the requirements cannot be met with the existing model.
NH=> We can roll back much further than this and ask WHY we have created
PWs in the 1st place.  And why is IP or MPLS over MPLS not also a valid
consideration (this is supposed to be 'multi-protocol' right?)
> 
> Neither one of these efforts has taken place.
NH=> Nor has the above above, which is even more fundamental 'effort'
IMO. 
> 
> To take  this a  bit further, I  would say  that with the  
> existing protocol model, traffic engineering of PWs
NH=> I have to object to this woolly 'TE' excuse.  What the heck is TE
anyway?  If you mean setting up server layer trails to carry (in a
directed sense) some client layer traffic then fine....but what is this
strictly to do with TE?  The nearest there is to TE in the IP layer is
ECMP (unless one can make real-time IGP load balancing work).  MPLS LSPs
exist in a separate layer network....well, they should....and the fact
they don't is the fundamental reason we are having all these nebulous
issues raised.  The underlying problem here is MPLS has never been
designed as a layer network in its own right.....and yet PWs expose the
need for this, and so instead we are now creating a new PW layer
network....well just how daft is that!

> therein  reduces 
> to the traffic engineering of the PSN  tunnels through which  
> the PWs  travel. 
NH=> No it doesn't. See above and below.

> The  tunnel setup  protocol is independent 
> of  the PW setup protocol, and  RSVP-TE could be used  to set 
> up the tunnels.  I don't see what's  lacking in this model, 
> but perhaps someone can provide a detailed example  in which 
> some putative requirement cannot be met with this  model.
NH=> OK, let me have a go.  In a client/server relationship how many
server layer trails are needed to carry the client?  Answer is 1.  So
why don't we carry the client directly over a single MPLS LSP then?  The
answer is simple....if the server is LDP with merging we can't resolve
the client directly.  The top level (targeted LDP) LSP is there for the
key reason of demerging to resolve who the client source is.  So the
real culprit is LDP mp2p merging (and its merging PHP bedfellow)....not
very nice is it?  So, I conclude here, that past arch violations are now
being used to justify further support of these same protocols.  We have
seen through this a long time ago.

regards, Neil

> That would help us to  understand whether the claimed need  
> for a new  protocol is  based on  facts, or  is just  another 
> tiresome "let's have another protocol war" effort.
> 
> If it  turns out that  the only shortfall  with existing 
> procedures  is that existing PW setup protocols need to  
> carry some opaque parameters to pass to the tunnel setup  
> parameters, I would not  say that that is a  defect in the 
> existing model.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>