[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Switching technologies requiring bidirectional asymmetric LSPs?
Good point Alan. I've also managed to discuss this topic briefly this morning with Andy Reid. He largely agrees with what I have already said, and thinks the signalling should be able to cater for the majority case of symmetric BW/routing as a bi-directional set-up/tear-down operation.....which is the general case for client/server network builder situations, ie construction of a client layer topology. However, the signalling should also be able to cater for unidirectional set-up when we need to provide asymmetry in BW and/or routing....usually a non-network builder situation, ie no higher layer network topology being constructed.
Hope that helps.
regards, Neil
> -----Original Message-----
> From: Mcguire,A,Alan,XGH51 R
> Sent: 20 April 2007 10:51
> To: Attila.Takacs@ericsson.com; IBryskin@advaoptical.com;
> Harrison,N,Neil,JCGA1 R; lberger@labn.net
> Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> adrian@olddog.co.uk; ccamp@ops.ietf.org
> Subject: RE: Switching technologies requiring bidirectional
> asymmetric LSPs?
>
>
> Attila,
> PONs are a good example of asymmetry at the edge
> Alan
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs (IJ/ETH)
> Sent: 20 April 2007 10:33
> To: Igor Bryskin; Harrison,N,Neil,JCGA1 R; lberger@labn.net
> Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> adrian@olddog.co.uk; ccamp@ops.ietf.org
> Subject: RE: Switching technologies requiring bidirectional
> asymmetric LSPs?
>
> Hi Igor, Neil, and all,
>
> I think it is quite useful to have this discussion on
> networking modes, topology builder services and the relations
> to GMPLS LSPs.
>
> I agree with Neil that the answer is context sensitive.
> One can have Ethernet LSPs operating in different modes:
> co-ps and cl-ps irrespective to what these are used for, i.e,
> being a server layer and building a client layer topology, or
> being at the top of the layers and directly supporting
> services. However, while the former requires co-ps mode to
> operate properly, as pointed out by Neil, the latter can be
> build on co-ps and cl-ps modes primarily depending on the
> requirements of the service. Hence, I think (and I assume
> this is referred to as context sensitive by Neil) asymmetry
> may be useful for LSPs residing higher in the layer stack
> regardless of co-ps or cl-ps mode of operation.
>
> Additionally, very much related to the layering/hierarchy,
> LSPs nearer to the edges of the network will likely
> experience asymmetry imho, compared to LSP in the core.
>
> Regards,
> Attila
>
> Ps.: well it seems I have just repeated what has been said
> already, sorry!
>
> > -----Original Message-----
> > From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> > Sent: Thursday, April 19, 2007 10:51 PM
> > To: neil.2.harrison@bt.com; lberger@labn.net
> > Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> > Attila Takacs (IJ/ETH); adrian@olddog.co.uk; ccamp@ops.ietf.org
> > Subject: RE: Switching technologies requiring bidirectional
> asymmetric
> > LSPs?
> >
> > Neil,
> >
> > Let's assume you've got clean co-ps connections(e.g. Ethernet
> > connections). My understanding is that you believe that the
> bandwidth
> > asymmetricity is useful for p2mp such connections, but not for p2p
> > connections. Is that correct?
> >
> > Thanks,
> > Igor
> >
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> > Behalf Of neil.2.harrison@bt.com
> > Sent: Thursday, April 19, 2007 12:28 PM
> > To: lberger@labn.net
> > Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> > Attila.Takacs@ericsson.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
> > Subject: RE: Switching technologies requiring bidirectional
> asymmetric
> > LSPs?
> >
> > Lou Berger asked 19 April 2007 15:05
> >
> > >
> > >
> > > Neil,
> > > I agree with Igor, much thanks for your input.
> > >
> > > In reading your response, it's clear that you see a place for
> > > bidirectional asymmetric-bandwidth *service*. I think
> > there is (and
> > > has been) general agreement on this.
> > >
> > > What's not clear to me is if you think there is any
> requirement for
> > > bidirectional asymmetric **LSPs**. Do you have an
> opinion on this?
> > NH=> Well, it depends what you mean by an LSP. As I've
> tried to point
> > out in the past there are very good scientific reasons why we are
> > forced to deal with 3 network modes...cl-ps, co-ps and
> co-cs...and why
> > all technologies map to one of these. Moreover the modes are
> > fundamentally different...and you cannot apply the same
> treatment to
> > them all. We've done lots of work in explaining this within SG15
> > unified modelling based on Information Theory considerations of how
> > both the labelling AND resource assignment work in space, freq and
> > time dimensions. The space and freq dimensions always
> force a co-cs
> > mode behaviour. However, it is how one slices up the time
> dimension
> > that generates either the (TDM spin of the) co-cs mode or the co-ps
> > mode. Without getting into too much detail, when the time
> slices are
> > regular (ie fixed in BOTH start datum AND duration) then labelling
> > (which is also implicit) and resource assignment are
> coupled/fixed and
> > the co-cs mode results. However, when the time slices are
> irregular
> > then labelling (which now has to be explicit) and resource
> assignment
> > are decoupled the co-ps mode results.
> >
> > The co-cs mode is extremely robust to arch misuse. For example, one
> > cannot violate the rules of a connection (ie single source, no
> > internal routing) in the co-cs mode...and a connection is a crucial
> > pre-requiste for all manner of things that one oftens wants
> > determinsism on, like OAM and resource assignment per se
> for SLAs. The
> > co-cs mode also has other desirable properties (like must have OOB
> > control/management, no QoS classes, etc) which are highly
> beneficial
> > and make networking simple...esp for network builder services (ie
> > constructing the topology of other layer networks).
> >
> > Now the co-ps is not so robust to arch misuse. One can create mp2p
> > merging constructs for example, as we find in MPLS. These
> cannot have
> > simple OAM nor can they provide deterministic resource
> > assignment/management.
> >
> > So, when you says LSPs you have to (i) be clear on the network mode
> > you are referring to and (ii) if the co-ps mode whether or
> not the LSP
> > respects the requirements of a connection...as not all LSPs
> do here.
> > Aside => One can clearly not construct client layer topoplogy from
> > mp2p server layer constructs!
> >
> > If I am providing (or indeed procuring) a network builder
> service (ie
> > I want to construct the topology of some higher client layer
> > network....be this a public service network or indeed a
> private (VPN)
> > network) then I would want 'LSPs' that respect the
> requirements of a
> > connection...because I want to see some strong SLAs associated with
> > that service. In the general case these would be based on p2p BW
> > symmetric constructs. However, in the case of end-system
> applications
> > supporting specific services like the ones I referred to in my
> > response to Igor then the requirement may not indeed be
> > symmetric....the p2mp *connection* being a case in point for say TV
> > dist (residential) or financial data distribution
> (business/private).
> >
> > Not sure if that helps Lou, but its the best I can offer for now.
> >
> > regards, Neil
> >
> >
> > >
> > > (if you already stated this, my apologies that I didn't
> > understand you
> > > ...)
> > >
> > > Thanks,
> > > Lou
> > >
> > > At 09:18 AM 4/19/2007, neil.2.harrison@bt.com wrote:
> > >
> > > >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=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > > WN
> > > > > >>> 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=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
> FncwRzbGsDbmV3LWNhcnM->new
> > >cars at Yahoo! Autos.
> >
> >
> >
> >
>
>