Thanks Igor....I think the answer is context sensitive. For example:
- are we dealing with a client/server network
builder private service?...which may contain a
large number of aggregate end-system client application traffic flows
- are we dealing with a single 'end system to
1st layer network adaptation' service?...which
may be a public or private service
In the former case, and increasingly so as one
moves towards the duct, there is (of necessity)
a lack of detailed information of higher client
BW requirements. So here there is a natural
case to want to provide symmetric BW
resources....and the atomic building block for
such services are p2p constructs.
However, when we look towards specific
end-system services there is more scope for BW
resource asymmetry.......a video streaming
service would probably be like this. Further,
it may not be simply p2p but p2mp. I can also
imagine some creative thinking wrt to using a
co-ps mode with proper p2mp *connections*
providing the service in one direction (ie root
to leaves) ....because we want some strong
resource assignment and SLA guarantees, eg
distributing financial information to
traders.....but a cl-ps mode return network
(leaves to root) providing 'control signals'
(where strong resource assignment may not be so
important). The return direction could however
be a set of N p2p connections (probably
congruently routed wrt to the other direction)
if strong resource assignment and SLAs were also
required in the return direction. The former
case here could be considered quite novel as the
overall service is using 2 network modes and, by
definition, 2 different layer networks....so
here there is large degree of asymmetry here.
So, as one moves towards the duct (and in
general for network builder services) there is,
IMO, a strong requirement for symmetry in all
aspects, but as one moves towards the
application there are cases where asymmetry is more appropriate.
regards, Neil
-----Original Message-----
From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: 19 April 2007 13:36
To: Harrison,N,Neil,JCGA1 R;
martin.vigoureux@alcatel-lucent.fr;
Attila.Takacs@ericsson.com; adrian@olddog.co.uk; lberger@labn.net
Cc: ccamp@ops.ietf.org
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Neil,
I consider your input very important to this discussion.
My question is: Do you see use cases for
bidirectional p2p services which are
asymmetrical from the bandwidth reservation
point of view (that is, in S=>D direction you
need bandwidth B1, while in D=>S direction you
need bandwidth B2, and B1 is significantly
different from B2), but fully symmetrical in all
other aspects (i.e. routes, protection capability, etc.)
Thanks,
Igor
neil.2.harrison@bt.com wrote:
Thanks Martin,
Most applications generate asymmetric (wrt time)
information flows in each direction, ie the rate
of information flow in each direction is neither
constant nor directly proportional to the rate
of information flow in the other
direction....just think about a voice
conversation if not obvious....or even a file transfer.
However, for an arbitrarily meshed network we
generally require symmetric routings of traffic
flows, ie if one direction passes the nodes
a->b->c->d in one direction then the other
direction should follow d->c->b->a in both this
and lower layer networks (to the duct).
Moreover, we usually require (under failure free
conditions) that such routings do not change
over the lifetime of a traffic flow.......this
is particularly important for connections (ie
co-ps and co-cs modes), and especially when they
are supporting a network builder service (a VPN
if you like), which may be a large aggregate of
all kinds of end-system application traffic
flows, for some other party. Note that if we add
nodes/links to a co mode layer network we should
not change existing connection routings. This is
not always the case with a cl-ps mode network,
ie because we do not have connections adding new
nodes/links can allow traffic flows to change routing.
Is that more clear now wrt what I meant?
regards, Neil
> -----Original Message-----
> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.fr]
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; Attila.Takacs@ericsson.com;
> i_bryskin@yahoo.com; adrian@olddog.co.uk; lberger@labn.net
> Cc: ccamp@ops.ietf.org
> Subject: Re: Switching technologies requiring bidirectional
> asymmetric LSPs?
>
>
> Neil,
>
> for clarification purposes, the asymmetry I was referring to
> was in terms of bandwidth not path/route or other TE
> parameter, but maybe I did not catch what you meant by *routings*.
>
> regards,
>
> martin
>
> neil.2.harrison@bt.com a écrit :
> > 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 /* 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://autos.yahoo.com/new_cars.htm
> >>
> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> >>> hcnM->
> >>>
> >>
> >
>
Ahhh...imagining that irresistible "new car" smell?
Check out
<http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->new
cars at Yahoo! Autos.