Hi,
I'm a bit surprised that there was no follow-up to Lou's
email.
Does silence indicate that this was put to bed in Prague and
no-one is
interested in these LSPs?
[at] well, as Lou mentioned at least a few of us continue an offline
discussion on the topic.
> So a few of us
have been having been discussing the asymmetric work
> presented in
Prague and it seems to me we have an open question on
>
requirements.
>
> It's clear that at least one switching
technology (i.e., ethernet/PBB-TE)
> requires support for
bidirectional asymmetric LSPs.
Is this clear? I continue to hear talk
of service requirements, but not so
much of how those services are
required to be supported.
The benefits I have heard are:
1. Fewer
control plane messages
2. Ease of enforecement of
fate-sharing
IB>> Adrian, you enumerated here the benefits of
bidirectional LSPs, and BTW you forgot to mention the most important one.
Ethernet OAM is designed, as I understand, on assumption that the
trafic takes the same paths in both directions. So, if we want
to preserve the Ethernet native OAM (which we certainly do , because this is
half of Ethernet functionality) we must map a bidiretcional service on
either a single bidirectional LSP or two unidirectional LSPs using the same
path. This is different form MPLS where there are no such OAM
requirements.
Lou is talking about asymetrical bi-directional LSPs, and
what is not clear (at least for me) whether we need asymetrical p2p Ethernet
services.
[at] Adrian's points are related to the single session vs.
multiple session discussions we had, which is generally true for any
bidirectional LSP.
The bidirectionality of Ethernet comes basically from two aspects
imho: (1) in any case, as Igor pointed out, most of the CFM functions will
only operate properly if there are symmetrical paths. (2) on the other
hand, if a GMPLS LPS is essentially a VLAN within which MAC learning is
operating one will need symmetric paths in order the learning functions
properly.
I
had the impression that we already converged before Prague to a single
remaining question: do we need the >>asymmetric bw<<
extension for a single session bidirectional LSP. There were
some possible cases for asymmetric bw LSPs mentioned by Don, Diego and
myself but these seemed not to convince everybody. Imho we should focus
on this question not to loop into the discussion we had already.
If
we agree on that bidirectional services over Ethernet need symmetrical paths
than we could conclude that using a single session to setup the
bidirectional LSP would be the preferred way at least over Ethernet. In this
case, imho it is quite reasonable to assume that asymmetrical services that
require a dedicated LSP would also use a single signaling exchange to setup
the LSP, hence there would be a need for the asymmetric bw extension.
Following this thinking, the question turns into the
aggregation/hierarchy discussion that was bought up by Dimitri earlier.
That is, do we have the need of LSPs per service. My two
cents: generally not but there are certain services where it is indeed
a reasonable assumption, e.g., IPTV or private
services.
These are significant, but not
dramatic, requirements.
> The question is:
>
> Is the
*requirement* for bidirectional asymmetric LSPs:
> (a) a technology
specific requirement, or
> (b) one that is common (this is CCAMP after
all!) to multiple switching
> technologies?
CCAMP deals in
transport networks. As far as I can see the service
requirements would
be pretty much the same all transport networks and would
certainly be
applicable to packet, L2, and TDM (the latter because TDM will
be called
on to support L2).
IB>> See my comment above: there is a
differnce between MPLS and Ethernet services. Also there are certainly
differences between MPLS and lambda services (use of the same lambda in both
directions, for example). So each transport technology may have distinct
requirements WRT bidirectional services and connections on which the
services are mapped.
> Please keep in mind that service
requirements are not the same thing as
> switching technology
requirements. For example, we have long built
> bidirectional
asymmetric services on unidirectional MPLS LSPs.
Well,
exactly!
Perhaps someone can explain why the Ethernet hardware is forced
to require
bidirectional asymmetric LSPs when MPLS is happy
without?
IB>> Again, IMO the answer is to be able to use native
Ethernet OAM.
Igor
> The answer to this question will help
determine if we should have a
> technology specific solution or a
generic CCAMP solution (as well as the
> complexity of the
solution.)
We should not take any action that deliberately precludes
or makes more
complex the genericisation (is that an American word?) of
the solution
unless there is a significant difference in simplicity of
solutions.
But we should take no action at all unless there is some
more evidence of
support for this work!
Adrian