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.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->