[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Switching technologies requiring bidirectional asymmetric LSPs?
I would caution against the observation that because traffic flows a->b and b->a are invariably asymmetric (wrt resource consumed at any epoch) their *routings* can also be asymmetric....this does not follow at all. This observation applies to all layer networks (any mode/technology).
regards, Neil
> -----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->
> >
>
>