Subject: RE: decisions on L2 solutions documents

From: "Vasile Radoaca" <[email-masked]>
Date: Sun, 1 Jun 2003 16:39:14 -0400

Vach,

  See my comments below - 

Cheers
 Vasile

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: Friday, May 30, 2003 12:50 PM
To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh [CAR:1A11:EXCH]; Ppvpn;
Rick Wilder
Subject: RE: decisions on L2 solutions documents

Vasile, Dinesh,

Some comments below.  I've tried to identify Rick's, Vasile's and my
comments. Outlook may mess the whole thing up, so apologies in advance.

-Vach

.. clipped
Rick>> Here are the questions/requests-for-clarification that came up.
Rick>>     a) how do the discovery and signaling parts of the document
Rick>>        relate to those described in the other solutions documents 
Rick>> and
which
Rick>>        of them are suggested to be mandatory to implement

VR> > vasile
VR> There are couple of assumptions that need to be taken in 
VR> consideration:
VR> 1)
VR> The GVPLS model, as a distributed model, needs to have a signaling
mechanism
that allows PW to be
VR> identified by VPN-ID, and the End Points together. The
pwe3-control-protocol-02.txt draft, with
VR> Rosen's extensions to the PW Signaling mechanism address this 
VR> problem.

Vach>> As a matter of fact, Rosen's signaling separately identifies the 
Vach>> PW and
the VPN.  Think of the
Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between 
Vach>> a pair
of PEs as the PW
Vach>> identifier.  So, if you want to use the Rosen model, why write 
Vach>> your own
draft?

>> Vasile
Rosen's draft presents only the extensions to the Martini's PW model, for
the control plan in order to accommodate more general models, like the
distributed model. The new GVPLS draft would be based on Rosen signaling
[PWE3-Control 02.txt]. 
So, the GVPLS has his own role as solution draft.

.. clipped

Vach>> There are two issues here.  The first is whether we need a 
Vach>> separate model for distributed VPLS or
Vach>> not.  The second is whether we need a VPN ID.

Vach>> To the first point, Ali and Eric have described how to use p2p 
Vach>> PWs in conjuction with a learning
Vach>> bridge in the position of the MTU to make a distributed VPLS 
Vach>> node.  don't think we need to have
Vach>> another way to create a distributed VPLS node.

>> Vasile
The draft-rosen-ppvpn-l2siganling-03.txt, section 5.5 represents an example
how a distributed model can be built using the Generalized signaling method
[PWE3-Control]. However, such model doesn't scale at all, and it covers only
point-to-point type connections between U-PE devices and N-PE devices. In a
more general and useful case, is when an Ethernet access network is used
between U-PE and N-PE devices. Also, such model needs to be presented in and
end-to-end solution.
We have here a typical two extreme cases: 
1) VPLS/HVPLS [your solution] where the MAC learning is done in PE - in this
repsect the scalability is very limited because of MAC explosion
2) "Rosen's model ,section 5.5, where everything is built using PW [access
and core], which doesn't scale because of the number of PWs.

GVPLS is a third way, where  is balance between MAC learning and forwarding
and the number of PWs built in the core [and eventual in the access].

... clipped 

Vach>> To the second point, the primary difference between the Rosen 
Vach>> draft and the HVPLS draft is in
Vach>> naming the PWs, not in naming the VPN ID.  The issue of using a 
Vach>> globally unique name for the VPLS
Vach>> has been discussed.  In an attempt to keep the signaling 
Vach>> compatible with draft-martini, we agreed
Vach>> on using a VCID.  However, there was an intent all along to 
Vach>> somehow make that identifier a
Vach>> globally unique.  Suggestions were made such as adding a VPN ID 
Vach>> in the optional parameters field,
Vach>> etc.  My last proposal was to have a bona fide VPN ID TLV in the 
Vach>> FEC.
Vach>> Again, you mention that you would do draft-rosen.  Why are you 
Vach>> specifying a different protocol
Vach>> then?
Vach>> If LDP is mandatory, why do you feel it is necessary to describe 
Vach>> BGP signaling in your draft?
Vach>> What is different about your BGP signaling and draft-kompella?

>> Vasile
BGP signaling needs to be done - and we would do in a separate draft. 

... clipped

Vach>> Then define BGP in a separate draft.  There is a claim that the
informational model is the same
Vach>> for BGP and LDP.  However, there are a lot of different fields in 
Vach>> the signaling that are
Vach>> described in the LDP signaling.  I don't know how you are going 
Vach>> to add them to the BGP signaling.
Vach>> Are the BGP signaling components such as label blocks and VE IDs 
Vach>> or site identifiers part of the
Vach>> informational model?  Are the LDP signaling components

Vach>> If draft-rosen is your model for LDP signaling, how are you going 
Vach>> to keep gvpls interoperable
Vach>> with HVPLS?

Vasile >> this is up to VPLS/HVPLS solution - I think VPLS/HVPLS should also
adopt Rosen's signaling method. VPLS/HVPLS draft is to narrow solution to
solve the current market issues. It is one of the possibility. 

[clipped]

Vach>> Some conclusions:
Vach>>   - GVPLS says LDP is the signaling protocol of choice
Vach>>   - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls
Vach>>   - one can construct a distributed VPLS node using ethernet PWs and
VPLS
Vach>>   - MAC-in-MAC is clearly outside the scope of the IETF
Vach>>   - at the Yokohama IETF we were told MAC-in-MAC was not 
Vach>> currently in any IEEE charter
Vach>>   - the BGP in GVPLS is too similar to draft-kompella-vpls to 
Vach>> warrant a
separate draft
Vach>>   - the claim to identical information models between BGP and LDP
signaling is not borne out
Vach>>   - GVPLS uses different encaps from the ones being defined in 
Vach>> PWE3

Vach>> Can you stil justify the GVPLS draft?

>> Vasile
As is today, it is not any other solution draft that described the VPLS
distributed model [Rosen's attempt is just an example].  GVPLS is trying to
complete this role.
A VPLS network can be composed via complex access  and core networks. It
would be to simplistic to consider the distributed model just with the PWs
on the access [the cost and the scalability do not reflect the customer's
requirements and the market direction]. From scalability point of view, we
just move the VPLS/HVPLS scalability problems from Mac learning to the
VC-labels.

Also, we need to a  have model that is flexible to accommodate new protocols
on the access networks, and M-in-M is one of the possibility. Probable, by
the time that VPLS/HVPLS solution would move forward, it's scalability and
the performance model would be already history, and M-i-M would be part of
the IEEE (who knows?).
 
A solution can be justifiable form political, market and theoretical
aspects.  Yes we recognize that VPLS/HVPLS doesn't scale but we would make
some special assumptions like no CE as L2 switching, no IP VPN or legacy
inter-working, no replication taken in consideration, no more than 1000 VPLS
and so on. It's obvious - from just mathematical\theoretical considerations
- that the VPLS/HVPLS doesn't scale.
If we just look to the real problems (without political clout), and where
GVPLS solutions is standing, we can realize  the VPLS system has a very fine
tunning aspects/parameters in order to scale and to perform well.   

Our product proofed already, that such systems, easily can scale beyond 5000
VPLS as is standing today. This is the reason the distributed model was
taken serious in consideration by the SPs - the draft it self is just an
expression of a solution that is working today, and it scales pretty well.

As simple answer, to your question - yes, I believe that GVPLS is needed. 

VR> Cheers
VR>    Vasile

-Vach

---

From: Eric Rosen <[email-masked]>
Date: Mon, 02 Jun 2003 10:21:29 -0400

Vach> I would suggest  that the full name  of a PW is {VPNID  (PE1, VC type,
Vach> VCID, PE2)}.

Vach> draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2)

Whether the VC type is part of the name is orthogonal; either proposal could
decide to use it or not, as it is always present. 

In my  proposal, you've  left out  the AGI above,  and the  AGI is  really a
VPNID.  The SAII and TAII are really VCids, so I'd say the difference is:

Vach: <VPNid, PE1, PE2, Vcid>

Eric: <VPNid, PE1, PE2, VCid at PE1, VCid at PE2>

That is, the only difference is whether to have a VCid which is unique for a
given pair of PEs, and have  that VCid provisioned at both ends, vs. whether
to allow each end to use a different VCid. 

By  allowing each  endpoint to  have  a different  VCid, it  is possible  to
accommodate  both  the  "auto-discovered  VPWS  full mesh"  scheme  and  the
"distributed VPLS" scheme,  as well as some possible  future extensions such
as switched VCs. 

Vach> Finally,  draft-rosen says the  SAII and  TAII are  0 for  VPLS.  That
Vach> means that there is  no name for the PW between a  pair of VPLS nodes.
Vach> That may generally be ok since the  full name of a PW is {VPNID, (PE1,
Vach> 0, 0, PE2)} and  we generally have only a single PW  between a pair of
Vach> nodes in a VPLS.

Yes, when there is only a single PW between a pair of nodes in a VPLS, there
is no need to assign a name to the PW, other than the VPNid. 

Vach> However, in a regulated environment, the  PE may have to host the FIB.
Vach> We have then  two spokes from the PE  to the MTU, one for  CE1 and one
Vach> for CE2.

Vach>    CE1------------\    /-----------\
Vach>                     MTU             PE
Vach>    CE2=============/  \=============/

Vach> I want to be able to name each spoke.  On the PE side, I have a FIB.  In
Vach> draft-rosen, the PE would name the SAII 0.  The PE would have to know the
Vach> name of the TAII on the MTU going to CE1.  The PE would have to know the
Vach> name of the TAII on the MTU going to CE2.  Otherwise, there would be no
Vach> names for these two PWs. 

In this case, I  would just have the MTU assign different  SAIIs to the PWs,
e.g., 1 and 2.  The two PWs would be <VPNid, MTU, PE, 1, 0> and <VPNid, MTU,
PE, 2, 0>.  I think this is exactly the same as in your proposal. 

So in my view, the two  proposals are semantically exactly the same for VPLS
and HVPLS,  it's just that  one is able  to handle additional cases  and the
other isn't. 

Vach> In summary:
Vach>  - my proposal would remove the  limited use Group ID field (actually,
Vach>    Eric pointed out I had no use for it)

Both proposals agree on this. 

Vach>  - my proposal requires a VPN ID that groups PWs across the network that
Vach>    belong to the same VPN

Both proposals agree on this. 

Vach> - my proposal uses the VCID field to name a PW within the VPN

Both proposals agree on this. 

Vach>  - the  delta between  existing fec  type 128  in pwe3-control  and my
Vach>    proposal is minimal

Eliminating the group id and adding a VPNid is "minimal"?

Vach>  - I  feel  that draft-rosen  suggests  a  much  broader change  (with
Vach>    additional benefits, but do we need them?) 

We could  compromise by  allowing a one-name  format and a  two-name format,
keeping  the one-name  format for  VPLS and  HVPLS, and  using  the two-name
format only where  is it really required.  However,  I think that compromise
would result in something which is more complicated than it needs to be. 

Another possible difference between the proposals has to do with whether the 
setting up of an LSP in one  direction can trigger the setting up of the LSP
in the  other direction,  or whether the  two directions  need to be  set up
independently.

---

From: [email-masked]
Date: Mon, 2 Jun 2003 22:30:32 +0100

Hamid Ould-Brahim wrote 02 June 2003 18:35

Peter, 
> 
> 
> Wouldn't it be kind of cool if we could use the same 
> addressing format for 
> what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to 
> say we always 
> identify the end-point of an LSP/PW/tunnel with a unique 
> address (I mean 
> unique for the LSP/PW/tunnel so no 2 PWs share the same address)? 
> 
But it that case how about pw created for l2vpns.
NH=> Hamid why do you think you need PWs at all?  The only reasons PWs exist
is as follows:
-	to fix the problems caused by mp2p LSPs.....if you want any-any
connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp
constructions make any arch sense....mp2p leads to problems and kludges;
-	to keep the pretence-up that MPLS =~ IP.....if true why do we need
MPLS then?  Use the right mode for the right application....both are
required;
-	to squeeze a bit of the server-layer BW via client compression (a
total non-issue IMO when other technolgies squander BW).

Would these 
addresses be required to be always unique or can be 
overlapping?  
NH=> PWs are *not* a layer network....they are actually a set of
encapsulation functions that belongs in the client->server adaptation
process (network-interworking case).  Client->server adaptation should be a
minimalist mapping with (ideally) no functions that need management (eg
sequence number aberrations).  PWs don't need addresses, ie PWs are not
switched network entities like LSPs...its MPLS that needs access point
addresses in its own right since MPLS creates a layer network.  Further,
when one considers mixed partition service-interworking between technologies
belonging to the *same* network mode (eg FR_access<=>MPLS_core<=>ATM_access)
PWs simply disappear anyway.  I know service-interworking is not on IETF's
(PWE3) agenda, but speaking as an operator its very high on ours to drive
down capex/opex so we can have a common core per network mode.....so please
(as a vendor) don't ignore it.

Its the above issues that sit behind Peter's original comments.

regards, Neil

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 2 Jun 2003 17:59:42 -0400

Neil,

> NH=> Hamid why do you think you need PWs at all?  

Actually I don't need them :-). I see them as a tool
for l2vpns (among others)...and Peter mentioned addresses
for pw...so I asked :-)...

>The only 
> reasons PWs exist
> process (network-interworking case). 

Isn't control/signaling, establishment of pws part of pwe3 work 
besides just encapsulation... 

> Client->server 
> adaptation should be a

Not at all ignoring it. I am actually in favor of addressing
interworking case and I don't see all l2vpn problems need to be solved
only through pwe3 to be taken as a complete package. In fact BGP 
signaling is an example that pwe3 encaps can be useful without pw 
signaling scheme (that's maybe a different topic)...

> Its the above issues that sit behind Peter's original comments.

Okay. Not sure I understand the client-server terminology 
and mpls/pwe3 layer subtleties...I guess this topic is more appropriate with
PWE3 layer discussions and MPLS layer debate going on
in pwe3 wg.

Hamid.

---

From: [email-masked]
Date: Mon, 2 Jun 2003 23:56:30 +0100

Hi Hamid,  thanks for the comments.  Please see in-line.  regards, Neil

Hamid Ould-Brahim wrote 02 June 2003 23:00
Neil, 
> NH=> Hamid why do you think you need PWs at all?  

Actually I don't need them :-).
NH=> Yes I know that too ;-)

I see them as a tool 
for l2vpns (among others)...and Peter mentioned addresses 
for pw...so I asked :-)...
NH=> You are right....this was an oversight on Peter's case.  He/I and many
others here are of the same view as the one I expressed.

Isn't control/signaling, establishment of pws part of pwe3 work 
besides just encapsulation...
NH=> Yes.  But think about TCP (or any other 2-point session-like protocols)
these need 'control' but they are not 'networked entities'.  The mere reason
this is being done does not justify PWs existence.  Their existence is
justified in other less technical ways....my prior comments indicate what I
mean by this.

Not at all ignoring it. I am actually in favor of addressing 
interworking case and I don't see all l2vpn problems need to be solved 
only through pwe3 to be taken as a complete package. In fact BGP 
signaling is an example that pwe3 encaps can be useful without pw 
signaling scheme (that's maybe a different topic)...
NH=> I think so.  I think BGP is an excellent protocol for distributing
reachability information (all modes), esp in a client/server case for a VPN,
but I don't think its a good general signalling protocol.....this has to be
mode specific.

PWE3 layer discussions and MPLS layer debate going on 
in pwe3 wg. 
NH=> Agreed....but they are kind-of interwined as I am sure you know.  Have
a word with Dave Allen in your organisation on these topics....he has an
excellent grasp of the issues and they are very important to us anyway.

---

From: "Sylvia Sugar" <[email-masked]>
Date: Tue, 03 Jun 2003 10:30:08 +0000

>
>Wouldn't it be kind of cool if we could use the same addressing format for
>what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to say we always
>identify the end-point of an LSP/PW/tunnel with a unique address (I mean

What happens if one only knows the "next-hop" and the next-hop knows how to 
get to the next-hop and so on?

Is that a problem? Or is that "not nice"??

>
>Now I know the problem is IPv4 space isn't big enough to do this so why not
>use IPv6 addresses? Since you've got to implement IPv6 at the RFC 
>specification
>level anyway wouldn't it be good to use IPv6 to address LSPs/PWs/tunnels
>consistently? That way we'll have another incentive to move to IPv6 - it'll
>ease the management & implementation of LSPs/PWs/tunnels.

That would be nice too.

I wish we (the market) knew who already owns /8s of v6 addresses.......

Is the address distribution done by drawing out globe and saying "so and so 
latitude and longitude will have so and so address?"

-SylviaXO

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: Giles Heron <[email-masked]>
Date: 03 Jun 2003 13:02:49 +0000

> total non-issue IMO when other technolgies squander BW).
[rest snipped] 

Meanwhile, back in the real world, PWs (in the MPLS context) do the
following:

1) add a label to the stack to keep state out of the core (this may also
create a p2p LSP on top of an mp2p LSP, depending on whether you are
using LDP or RSVP-TE for your tunnel LSPs).
2) create a bidirectional p2p construct out of two unidirectional p2p
LSPs.
3) adapt the layer 2 protocol being carried to MPLS.  This involves
three things:
i.   stripping off the layer 2 header (aka "compression") in the cases
such as FR where the header may be different at each end.
ii.  sequence numbering, if required, for the case where the core
network may reorder packets.
iii. length checking, for the case where the core network's minimum PDU
is larger than that of the PW (this is required because MPLS has no
length field).

Giles 
 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: [email-masked]
Date: Tue, 3 Jun 2003 13:44:33 +0100

Giles,
> using LDP or RSVP-TE for your tunnel LSPs).
NH=> This is an LSP issue and belongs to the proper MPLS layer
network....nothing to do with PWs.

> 2) create a bidirectional p2p construct out of two unidirectional p2p
NH=> This is an LSP issue and belongs to the proper MPLS layer
network....nothing to do with PWs.
 
> 3) adapt the layer 2 protocol being carried to MPLS.
NH=> Now you have it....PW are about adaptation....with that I agree.

> This involves
NH=> Yep, bit of BW squeezing

> network may reorder packets.
NH=> Yep, there to fix lower layer MPLS problems.

> is larger than that of the PW (this is required because MPLS has no
NH=>Agreed, adaptation function should pad to minimum.

---

From: Giles Heron <[email-masked]>
Date: 03 Jun 2003 14:47:28 +0000

> Giles,
[snip]
> network....nothing to do with PWs.

of course there is no such thing as an MPLS layer network.  In an
architecturally pure parallel universe perhaps we'd have one ;-)  In any
case please let's not have that debate again...

but sure, label stacking is part of the MPLS architecture.   In this
case the PW label is signalled by the PWE3 control component.

> network....nothing to do with PWs.

last time I checked MPLS LSPs were unidirectional, and PWs required
bidirectional connectivity.

> NH=> Yep, bit of BW squeezing

BW squeezing is a side-effect of stripping the L2 header, not the
primary reason it was done AFAIK.

> NH=> Yep, there to fix lower layer MPLS problems.

not really.  It's just that some client protocols may be less tolerant
of re-ordering than others.  So some SPs may want to have the option of
building a network which does not guarantee strict ordering of packets
in all circumstances, and then have the adaptation function provide this
for any traffic which needs it.

> NH=>Agreed, adaptation function should pad to minimum.

at least we're agreed on something ;-)

Giles