[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] PWE3 question
Sasha,
DU LDP can't provide the level of QoS and connectivity needed for ATM VCs,
unless massive over provisioning is done.
-Shahram
> -----Original Message-----
> From: Sasha Vainshtein [mailto:Sasha@axerra.com]
> Sent: Thursday, May 16, 2002 6:25 AM
> To: 'Maarten Vissers'
> Cc: 'pwe3@ietf.org'
> Subject: RE: [PWE3] PWE3 question
>
>
> Maaten,
> Thank you for a very nice explanation.
> Please see some comments inline.
> Hopefully they clarify my position.
>
> With best regards,
> Sasha Vainshtein
> email: sasha@axerra.com <mailto:sasha@axerra.com>
> tel: +972-3-7659993 (office)
> +972-8-9254948 (res.)
> +972-58-674833 (cell.)
>
>
>
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Thursday, May 16, 2002 10:14 AM
> > To: 'pwe3@ietf.org'
> > Subject: Re: [PWE3] PWE3 question
> ...snipped...
> > To support PWE3 services, a specific fully meshed PWE3-PSN
> > (sub)layer network is to be created (within the boundaries
> of a general
> purpose
> > MPLS layer network), in which PSN-tunnels (which are MPLS (sub)layer
> network
> > trails) support the PWE3-PSN links (G.805 terminology).
> > These PWE3-PSN links terminate in the PEs,
> > in which the individual PWE3-PSN link connections (i.e. the
> > PWs) are connected to PWE3-PSN trail termination
> > functions (i.e. the MPLS VC termination points).
> >
> Alternatively, one could use the full mesh of PE-to-PE LSPs
> created by LDP in the DU mode and, if necessary, enhance it
> using, say preconfigured EXP<-->PHB mappings (if the number
> of PHBs to be supported is low) to make this sub-layer
> DiffServ-enabled.
> >
> > As layer network topology should typically not be changed on
> > individual connection requests, the PWE3-PSN (sub)layer
> network topology
> > must connect a PE to all other PEs before first user
> traffic is accepted
> > (assumption is that more than one user will be connected to a PE).
> >
> The alternative mentioned above complies with this.
> >
> > In a typical transport network in Europe with some 7500
> > offices to which users connect, this implies about 28 million
> PWE3-PSN links (i.e. PSN-tunnels) are to
> > be set up. Most likely however this number can not be handled
> > administratively,
> >
> I agree. But this number, presumably, can be handled by LDP
> in DU mode (noted, the LSPs thus produced would be
> most probably p2mp, and would not guarantee any resource
> allocation).
> >
> > and additional grooming points in the middle of the network
> > are required.
> >
> This is another alternative. I would be interesting to compare it
> with the previous one regarding level of guarantees that can be
> provided.
> >
> > The single-hop-PE-to-PE approach can be maintained when a
> > hierarchy of PSN-tunnels is deployed, or a multi-hop-PE-to-PE
> > approach is to be introduced in which PSN-tunnels (PWE3-PSN links)
> > terminate at intermediate nodes (P) and MPLS VC
> > signals are cross connected/routed from an ingress PSN-tunnel
> > to an egress PSN-tunnel. The MPLS VC label will not longer
> be a fixed
> > label however, as translation is to be supported at those points.
> >
> IMHO this approach reflects one of the fundamental problems with
> G.805: the client trail-to-server trail relationship is many-no-many
> and not many-to-one. The resulting complexity (from my former
> experience
> with SONET/SDH network management systems) is enormous even if,
> in some cases, you cannot do better.
> So far, the PWE3 approach has been to normalize this relationship to
> many (client trails = PWs)-to-one (server trail = PSN tunnel).
> It would be really challenging to understand the limitations of this
> approach regarding solid traffic guarantees etc.
> >
> > This latter shouldn't impact the specific PWE3 work. PWE3
> defines the
> > encapsulation/mapping methods, which should be independent of
> > the transport of this signal through the PSN.
> >
> >
> I agree.
> >
> > Regards,
> >
> > Maarten
> >
> > Shahram Davari wrote:
> > >
> > > Sasha,
> > >
> > > > -----Original Message-----
> > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com]
> > > > Sent: Wednesday, May 15, 2002 11:14 AM
> > > > To: 'Rutemiller, John'; 'pwe3@ietf.org'
> > > > Subject: RE: [PWE3] PWE3 question
> > > >
> > > >
> > > > John,
> > > > Thank you for a prompt response.
> > > > Please see some more comments inline.
> > > > Hopefully they will be useful.
> > > >
> > > > With best regards,
> > > > Sasha Vainshtein
> > > > email: sasha@axerra.com <mailto:sasha@axerra.com>
> > > > tel: +972-3-7659993 (office)
> > > > +972-8-9254948 (res.)
> > > > +972-58-674833 (cell.)
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rutemiller, John [mailto:John.Rutemiller@marconi.com]
> > > > > Sent: Wednesday, May 15, 2002 3:58 PM
> > > > > To: 'pwe3@ietf.org'
> > > > > Subject: RE: [PWE3] PWE3 question
> > > > >
> > > > >
> > > > > There are many ways to build a network.
> > > > >
> > > > > The virtual "network" you describe is one way, in which case
> > > > > the tunnel is not created explicitly for PW transport. But
> > > > > others may choose to create a tunnel explicitly for PW
> > transport.
> > > > >
> > > > No problem with that. But, IMHO, there is a difference between
> > > > creating a tunnel to b used by a (still unknown) group of PWs
> > > > and creating a tunnel per PW.
> > > > In the 1st case, there is no casual connection between creation
> > > > of any specific PW and the state of P routers; in the 2nd one,
> > > > there would be.
> > >
> > > OK, how about this: I have my PSN and don't have any PW yet, but I
> > > expect to have N*PW (N is small) between to PEs. I could create
> > > N*LSP between the two PEs. Now After I receive a PW
> > request, I choose
> > > one of the LSPs that best fits that PW.
> > >
> > > If no suitable LSP is found, then I either will change the
> > attributes
> > > of that LSP (by signaling) or create a new LSP. This last
> part is no
> > > different in tunneled or non-tunneled solution, because
> even in case
> > > of tunneled solution, if the tunnel is not suitable you
> need to take
> > > exactly the same actions.
> > >
> > > > >
> > > > > In the later case, the tunnel is closely tied to the
> PW. No, the
> > > > > tunnel is not created in direct response to any PW stream.
> > > > >
> > > > IMHO this means that setup/teardown of PWs do not exert any
> > > > control over the state of P routers, so it's OK.
> > >
> > > What if all PWs are tear downed, do you still keep the tunnel?
> > > if so why?
> > >
> > > > >
> > > > > But it is still created directly for the PW service.
> > > > >
> > > > My English may be faulty, but I would say that the tunnel is
> > > > created to be used by the (multiple and currently
> > non-existing) PWs,
> > > > not "for the (specific) PW service". If I install new
> > > > interface cards in
> > > > my
> > > > P routers and connect them over a new fiber with the intent to
> > > > use new capacity thus created for (yet non-existent) PWs,
> > > > these PWs still do not exert any control over my PSN!
> > >
> > > But PWs can't use those links either, unless you modify the
> > > FIBs on those routers.
> > >
> > > -Shahram
> > >
> > > > >
> > > > > Same goes with the choice of whether to use an E-LSP. Network
> > > > > design decision.
> > > > >
> > > > > Clearly, using a common LSP for all traffic between two nodes
> > > > > and using E-LSPs has certain scaling and restoration
> advantages
> > > > > (fewer restore faster for the entire network).
> > > > >
> > > > > But, some carriers may want to seperate the fate of the
> > different
> > > > > traffic. For example, the carrier may want to restore
> > PW services
> > > > > before voice services because the PW users pay more for the
> > > > bandwidth.
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> > > > > > Sent: Wednesday, May 15, 2002 10:11 AM
> > > > > > To: 'Rutemiller, John'
> > > > > > Cc: 'pwe3@ietf.org'
> > > > > > Subject: RE: [PWE3] PWE3 question
> > > > > >
> > > > > >
> > > > > > John,
> > > > > > Please see some comments/responses inline.
> > > > > > Hopefully they will clarify my position.
> > > > > > With best regards,
> > > > > > Sasha Vainshtein
> > > > > > email: sasha@axerra.com <mailto:sasha@axerra.com>
> > > > > > tel: +972-3-7659993 (office)
> > > > > > +972-8-9254948 (res.)
> > > > > > +972-58-674833 (cell.)
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Rutemiller, John
> [mailto:John.Rutemiller@marconi.com]
> > > > > > > Sent: Wednesday, May 15, 2002 12:12 PM
> > > > > > > To: 'pwe3@ietf.org'
> > > > > > > Subject: RE: [PWE3] PWE3 question
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> > > > > > > > Sent: Friday, May 10, 2002 2:57 AM
> > > > > > > > To: 'Shahram Davari'
> > > > > > > > Cc: 'pwe3@ietf.org'; Danny McPherson (E-mail);
> 'Andrew G.
> > > > > > > > Malis'; Neil.
> > > > > > > > 2. Harrison (E-mail)
> > > > > > > > Subject: RE: [PWE3] PWE3 question
> > > > > > > >
> > > > > > > >
> > > > > > > > Shahram and all.
> > > > > > > > Please see a brief comment inline.
> > > > > > > >
> > > > > > > [SNIP]
> > > > > > > >
> > > > > > > > I would suggest a very simple criterion regarding
> > exertion or
> > > > > > > > non-exertion of control over PSN: if
> > setup/teradown of a PW
> > > > > > > > requires modification of the FIB in at least one PSN
> > > > node that
> > > > > > > > does not act as the PE for this PW, it means that
> > > > control over
> > > > > > > > this router has been exerted.
> > > > > > > >
> > > > > > > > This criterion does not depend on the protocol
> being used
> > > > > > > > (static,LDP, RSVP or else).
> > > > > > > >
> > > > > > > > The single-label model requires allocation of a new
> > > > label per PW
> > > > > > > > in each interior node on the path fromingress to
> > > > > egress, and hence
> > > > > > > > means exertion of control over the PSN unless the
> > the pair of
> > > > > > > > PEs are adjacent (the "single hop" case mentioned
> > by Neil).
> > > > > > > >
> > > > > > > > Can we agree on that?
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Creation of a Pseudo wire requires a tunnel label.
> > > > > > >
> > > > > > Correct. You must associate every direction of a PW
> > > > > > over an MPLS network with an LSP leading from the
> > > > > > ingress PE (for this direction) to egress PE.
> > > > > > >
> > > > > > >The creation of this tunnel must be configured.
> > > > > > >
> > > > > > It can be created regardless of any specific PW that
> > would use it.
> > > > > > And it could be created in many ways, including hop-by-hop
> > > > > forwarding
> > > > > > provided by the vanilla LDP.
> > > > > > Once created, such a tunnel can be used by - and, for
> > scalability
> > > > > > reasons, SHOULD be used - by more than one PW between the
> > > > > > same pair of PEs.
> > > > > >
> > > > > > And it could be created in many ways, including
> "vanilla" LDP
> > > > > > in DU mode.
> > > > > > >
> > > > > > >The establishment of the tunnel will affect the
> FIB if the P
> > > > > > routers.
> > > > > > >
> > > > > > Correct. However, as I said above, creation of the tunnel
> > > > > (to be used
> > > > > > by multiple PWs) is not caused by creation of the
> > PWs. Creation
> > > > > > of PWs using an already existing tunnel would not affect
> > > > FIB in the
> > > > > > P routers, only in PEs.
> > > > > > >
> > > > > > >Furthermore, the tunnel must be created with a
> > forwarding class
> > > > > > >that is sufficient to carry the desired pseudo
> wire traffic.
> > > > > > >
> > > > > > There are many ways to associate a certain
> forwarding behavior
> > > > > > with the EXP bits across an LSP. E.g., one can use
> > > > > > Preconfigured EXP<-->PHB Mapping in LSPs that have been
> > > > > > created by LDP in DU mode.
> > > > > >
> > > > > > Such an method cannot be used if reservation of resources
> > > > > > must be associated with an LSP. But even then nothing
> > > > > > prevents creation of a "planned" network of DiffServ-enabled
> > > > > > LSPs with BW reservation beforehand regardless of any
> > > > > > specific PW, and then creation of PWs that use available
> > > > > > capaity on this "network".
> > > > > > >
> > > > > > > If traffic classes are to be separated (e.g, ATM
> > CBR gets EF and
> > > > > > > ATM UBR gets best effort), then multiple tunnels
> > must be created
> > > > > > > across the network.
> > > > > > >
> > > > > > Not necessarily. A single E-LSP will may support up
> > to 8 different
> > > > > > traffic classes. And this can be done by using preconfigured
> > > > > > EXP<-->PHB mappings, too.
> > > > > > >
> > > > > > >
> > > > > > > Therefore, the PW has in some way exerted control over
> > > > > the P routers
> > > > > > > even with the tunnel creation.
> > > > > > >
> > > > > > This would only happen if you apply the "One PW = One
> > > > Tunnel" model
> > > > > > that originated this thread. And that is exactly why I said
> > > > > > that, IMHO,
> > > > > > this model is beyound the chartered PWE3 scope. The
> model that
> > > > > > separates creation of transport tunnels from creation
> > of PWs is
> > > > > > within this scope.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > pwe3 mailing list
> > > > > > > pwe3@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > pwe3@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > >
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > pwe3@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3