RE: Switching technologies requiring bidirectional asymmetric LSPs?

[<neil.2.harrison@bt.com>]

Thanks Lou,

who wrote 20 April 2007 00:38

> 
> At 12:27 PM 4/19/2007, neil.2.harrison@bt.com wrote:
> >[...]
> >So, when you says LSPs you have to (i) be clear on the network mode 
> >you are referring to and (ii) if the co-ps mode whether or not the 
> >LSP respects the requirements of a connection...as not all
> LSPs do here.
> >[...]
> 
> Neil,
>          As you know LSP is a technology independent term used in
> MPLS and GMPLS.
NH=> Yes I know.  But GMPLS != MPLS as the network mode is a critical
parameter and places constraints on behaviour.  However, this is not to
say there is plenty of scope for functional component re-use (quite the
contrary in fact)....but I do fundamentally object to the notion that
one can have the *same* instance of functional component (any, but
routing is the most obvious one) running IP to Optics.  This just won't
work for a whole raft of reasons (technical, commercial and regulatory).

>  The original question (requirement for bidirectional 
> asymmetric-bandwidth *TE* LSPs) was intended to identify which 
> network modes the WG considered important.  The motivation for the 
> question was the discussions on  bidirectional asymmetric-bandwidth 
> TE LSPs for co-ps, specifically Ethernet/PBB-TE, see 
> draft-takacs-asym-bw-lsp.  Some have asked if we should define a 
> mechanisms that supports other co-ps and co-cs technologies.  Others 
> have said that we should not define mechanisms for any technology.
> 
> Does this help clarify the question?
NH=> Yes it does.....and I have raised this internally for discussion as
I thought your initial question to the list deserved some answer...still
awaiting colleagues comments.  I will look at Attila's draft as soon as
I get time and see what additional comments I can provide.  But in
general, and as I have already observed, if we are using layer N to
create the topology of a higher layer network then p2p symmetric
constructs are the natural building block...however, if we are at the
top of the network stack and directly supporting some external
application/service, then there is more scope for asymmetry.
> 
> Lou
> 
> PS
> 
> >Aside => One can clearly not construct client layer topoplogy from
> >mp2p server layer constructs!
> 
> and I'd claim that the current definition of mp2p is cl-ps...
NH=> And I'd agree with you, though I would observe that a cl-ps traffic
unit MUST have network significant DA/SA labels....this is not forced in
the co-ps mode.  Moreover, there is more to networking than simply
labelling considerations, and the partitioning of resource is
fundamental to many important operational and service related
behaviours/requirements.  One can gain some important insights and
benefits form a better understanding of how labelling and resource
partitioning work and generate the 3 network modes.  PBB-TE, that you
mention in a prior paragraph, was indeed a spin-off from our unified
modelling work.

regards, Neil
> 
> 
>