-----Original Message-----
From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Martin Vigoureux
Sent: 19 April 2007 08:34
To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
Cc: ccamp@ops.ietf.org
Subject: Re: Switching technologies requiring bidirectional
asymmetric LSPs?
All,
I do believe in the need for asymmetric bidirectional LSPs.
Traffic is by nature asymmetric (for the vast majority of it
at least). We may argue that the sum of asymmetric traffic
could lead to symmetric traffic or that the above statement
is dependent on the network segment we are considering, but
it will remain true and we should definitely capitalize on
CCAMP prior work by taking benefit from the advantages of
bidirectional LSP setup.
Furthermore, I believe we should not restrict the work and
solution to Ethernet technology only.
martin
Attila Takacs (IJ/ETH) a écrit :
Hi all,
please see inline [at]
Regards,
Attila
--------------------------------------------------------------
----------
*From:* owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]
*On Behalf Of *Igor Bryskin
*Sent:* Tuesday, April 17, 2007 10:19 PM
*To:* Adrian Farrel; ccamp@ops.ietf.org; Lou Berger
*Subject:* Re: Switching technologies requiring bidirectional
asymmetric LSPs?
Adrian, Lou
Please,see in line.
*/Adrian Farrel <adrian@olddog.co.uk>/* wrote:
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
--------------------------------------------------------------
----------
Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=48245/> *http://autos.yahoo.com/new_cars.htm
l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
hcnM->