Subject: Is IP Layer 2 Interworking useful?

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 25 Apr 2002 12:48:56 -0400

I am not entirely sure if IP L2 interworking is out of scope for
PPVPN working group charter. At last IETF, we had one or two opinions
that claimed that heterogeneous configurations are not useful.

We had other opinion who wanted not just IP but interworking
for everything. And then there were many opinions in between
which definitely believed IP L2 interworking to be a very useful
feature.

I am copying this mail to PPVPN group, because my understanding
(as was Giles) that this issue needs to be resolved in the
PPVPN mailing list.

regards,
himanshu

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 12:14 PM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: RE: Network Interworking Only in PWE3 (was: RE: 
> [PWE3] Proposed
> c hang es to draft kamapabhava-01)
> 
> 
> On Thu, 2002-04-25 at 15:13, Sasha Vainshtein wrote:
> [snip]
> > > I think yes, the PWE3 assumption is that you have the same L2 
> > > at either
> > > side.
> > > 
> > > But of course this doesn't preclude the use of an IWF at 
> > > either side (so
> > > e.g. ATM<===>FR<===>PW<===>FR is possible).
> > > 
> > Sure. But should the fact that you have FR over AAL5 over ATM 
> > at one end of the PW affect behavior of a FR-carrying PW in any way?
> > I would say not; and, luckily, none of the FR-related 
> drafts does not
> > say anything else.
> 
> The PW should be unaware of any service interworking.  Or 
> another way of
> putting it is that the far end PWES should be unaware of it...
> 
> > Not all the services are that lucky, though. I would say that many
> > problems with ATM AAL5 mentioned by Neil stem from its 
> interpretation as 
> > inherently related to ATM instead  a (more or less generic) 
> frame-carrying 
> > service. The latter approach would result in emulation that 
> is far from
> > perfect
> > from the ATM point of view but, hopefully, very simple and 
> sufficient for
> > lots of applications, while the former (the hybrid one) is 
> (to my taste)
> > results in a lot of complications - and the simplest way to 
> avoid them would
> > be to switch to a true Cell Relay (= AAL0) PW. 
> 
> To me the AAL5 mode is just an optimisation that you can make if you
> know you will be carrying AAL5 traffic only.
> 
> It also interoperates with existing SAR chips (or at least 
> the SDU mode
> does - personally I don't see much benefit in the PDU mode).
> 
> > > And of course there is a draft or two in PPVPN on 
> > > X<===>PW<===>Y for the
> > > case where X and Y both carry IP.
> > >
> > I can only say that one such draft (on ARP mediation) has been
> > explicitly rejected at the PPVPN WG meeting in MPLS because
> > the subject was declared "not in the charter". (Personally I think
> > that this is a very useful document provoding a nice solution of
> > a highly relevant problem, and I hope that the PPVPN WG will
> > reconsider). 
> 
> I wasn't there, but from my reading of the minutes Scott said 
> it was out
> of scope of the current charter and should be discussed on 
> the list.  Is
> that the same as "explicitly rejected"?  I suppose it may be!
> 
> I'm not entirely sure why ARP mediation is out of scope.  It 
> isn't FR to
> ATM interworking, it is IP interworking.  Surely IP VPNs are in scope
> for PPVPN?
> 
> > I do not have anything against "service interworking" or 
> "peer-to-peer"
> > trail relationships. I just am not sure that the PWE3 WG is a
> > suitable place for these discussions and that service interworking
> > considerations are valid arguments in these discussions.
> 
> agreed.  Service interworking is outside the PWE3 scope (and 
> may or may
> not be out of scope for PPVPN).
> 
> Giles
> 
> > >
> > > Giles
> > > 
> > > > ... snipped ...
> > > > > 
> > > > > regards, Neil  
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > -- 
> > > =================================================================
> > > Giles Heron    Principal Network Architect    PacketExchange Ltd.
> > > ph: +44 7880 506185              "if you build it they will yawn"
> > > =================================================================
> > > 
> > 
> -- 
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 25 Apr 2002 20:17:39 +0200

Himanshu and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 6:49 PM
> To: 'Giles Heron'; Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
> Subject: Is IP Layer 2 Interworking useful?
> 
> 
I would say that "useful" and "out of scope of the WG charter"
are two different issues.

Personaly I am pretty well sure that IP Layer 2 Interworking is
useful. I assume this position is shared by the co-authors of 
draft-kompella-ppvpn-l2vpn-01.txt that introduced (AFAIK) the
notion and, by implication, by some SPs.

I am also pretty well sure that ARP mediation is MUST for
IP-only L2 Interworking in configurations involving Ethernet
interface at one point and non-Ethernet interface at the other
point. I also think that these configurations are relevant. 
Other people may have (and do have) different opinions regarding
relevance of these configurations. However, I have not met anyone
who, on one hand, accepts relevance of IP-only L2 interworking and
"partially Ethernet" configurations but, on the other hand, explicitly 
denies the need for ARP mediations.

Being "in" or "out of scope" of the WG charter is an issue for
the WG chairs and ADs to rule upon. If they decide that, in order to accept 
the ARP mediation document, the charter must be modified first, I would
say that supporters of this proposal should try to convince the list and,
consequently, the chairs and ADs that such a change is really needed. 
> which definitely believed IP L2 interworking to be a very useful
I hope that I understand what IP-only L2 interworking means and,
based on this understanding I think that the PPVPN WG is the right
place to discuss all the issues related to it.

Unfortunately I do not know what exactly "interworking for everything"
means. Hence I am not sure where this issue should be discussed.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 25 Apr 2002 16:11:14 -0400

IP L2 interworking is where IP packets from the
CE device are propagated by ingress PE over
Layer 2 VPN infrastructure (Martini, Kompella) using
circuit information (such as VLAN, DLCI, ATM PVC, etc).

In Interworking case, ingress PE decapsulates data link
header and dispatches the IP packet as payload across
PSTN. Egress PE, in turn re-encapsulates the appropriate
data link header before dispatching to CE. This decap - encap
on the edges allows heterogenous circuits to cross-connect.
Note again, that packet forwarding is strictly based on circuit info
and NOT destination IP address (hence "L2")

hope this clears up,
himanshu

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 1:18 PM
> To: Shah, Himanshu
> Cc: 'Giles Heron'; Sasha Vainshtein; [email-masked];
> [email-masked]; Joe Touch; [email-masked]
> Subject: Re: Is IP Layer 2 Interworking useful?
> 
> 
> Hi,
> 
> Shah, Himanshu wrote:
> could you explain a bit more what you mean by "IP L2 internetworking"?
> 
> Since IP is layer 3, do you mean "an IP overlay deployed on an L2 
> infrastructure"? Isn't that just provisioning? Or do you mean "an L2 
> overlay deployed over IP"?
> 
> Thanks,
> Lars
> -- 
> Lars Eggert <[email-masked]>           USC Information 
> Sciences Institute
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 25 Apr 2002 17:33:29 -0400

Mark> In this  way, the specific  conversion from the various  circuit types
Mark> (conversion which in this case  is essentially the extraction of an IP
Mark> packet and throwing everything else away) may then simply be punted to
Mark> the NSP function, without affecting the PW per se. 

But doing  the ARP mediation requires  that both PEs  cooperate in executing
procedures such as  those specified in the draft,  using information that is
signaled  as specified  in the  draft.  This  part does  affect the  PW, and
cannot be thought of as purely  an NSP function.  Also, the PW encapsulation
will  not be  the data  link  encapsulation of  either end,  which seems  to
require a new PW type.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 26 Apr 2002 00:04:34 +0200

Eric Rosen wrote:
> cannot be thought of as purely  an NSP function.  

My text was in direct response to Himanshu's discussion regarding encap and
decap, not the arp mediation.

Which is why I explicitly qualified my statement with "From an encapsulation
perspective," which you left out of the quote above, so I will assume you just
missed it.

> Also, the PW encapsulation

That was the point I was trying to make.

- Mark

---

From: [email-masked]
Date: Fri, 26 Apr 2002 12:55:22 +0100

OK.....but what you are describing here Himanshu is where there is a 'known'
IP end-end client for different client/server relationships with a lower L2
server layer.  And in fact, as you have described it, the L2 networks form
peer-peer relationships.

Nothing wrong with this, and its exactly what you see out there today when
connecting routers.  The key point is that the link-connections, formed by
some arbitrary lower level technology at L1/2, between adjacent routers are
formed from end-end trails in that server layer and, most importantly, those
trails are *terminated* at the routers.

Now this is quite different to (arbitrary) XoverMPLS, eg ATMoverMPLS,
FRoverMPLS, SDH(various)overMPLS.....here the client/server relationship is
formed between X and MPLS......if IP is a client of the X that is incidental
in this case.

In the 2 cases the defect handling behaviour required is quite different.

regards, Neil

> Sent: 25 April 2002 21:11
> To: 'Lars Eggert'
> Subject: [PWE3] RE: Is IP Layer 2 Interworking useful?
> 
>

---

From: [email-masked]
Date: Fri, 26 Apr 2002 12:55:24 +0100

Mark Townsley wrote 25 April 2002 23:05
<snip> 
> That was the point I was trying to make.
NH=> Mark....I think this needs a bit more clarification.

If we have 3 peer L2 server trails X, MPLS and Y say supporting 1 'known'
end-end client L3/IP connection, then these are all simple/standard
peer-peer L2 trails relevant to their technology.  Each of these L2 trails
is terminated before passing the client L3 traffic to the next L2 trail.

If however we are doing arbitrary XoverMPLS, where X is not IP directly
(though IP could be a client of X), this is not the case.  Here we have an
end-end trail of X with an intermediate server layer trail of MPLS.  So here
we have 2 L2 server trail *partitions* of X, either side of an intermediate
MPLS server layer.  Now the really important aspect here wrt to the point
you are raising, is that the *top-level* MPLS trail cannot be a
simple/standard LSP any longer.  Why?  Because it has to support an extra
overhead capability to supply functions that are not present in the standard
LSP overhead, eg seq. nos.  Any further lower MPLS trails that form a
client/server relationship with this top-level trail however are 'standard'
LSPs, and only have normal LSP overhead functions.

Hope this helps...it is a very important point.

regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Apr 2002 10:09:16 -0400

Yushun> My question  is, when you have  different L2 protocols  at the ends,
Yushun> isn't it  time to try L3  solutions? I just don't  see going through
Yushun> all this troubles  and inventing new protocols justify  what you can
Yushun> simply do with L3 (i.e., IP). 

Perhaps there are some service providers who think that the trouble involved
in providing the  necessary ARP mediation is possibly  less than the trouble
involved in providing an L3VPN service. 

>From the customer perspective, if the  customer wants an L2VPN, I doubt that
the SP will be willing to say "look,  since we can't give you the same L2 at
both ends, you need to use an  L3VPN service; after all, you don't expect us
to go to any extra trouble for you, do you?"

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Apr 2002 10:23:10 -0400

The  best  way to  solve  the  problem  in the  CE  router  is to  have  the
non-ethernet attached CE use an encapsulation of ethernet on whatever the L2
attachment is.  (E.g.,  there's a standard way to  encapsulate ethernet over
FR, ATM, PPP, etc.) 

But this  is not transparent to the  customer, and some SPs  will be serving
customers who don't want to change their CE configs, or whose CE routers are
not capable of doing the necessary encapsulations.

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Apr 2002 07:26:37 -0700

> attachment is.  (E.g.,  there's a standard way to  encapsulate ethernet over

Sure (that's what I just posted, except I also hinted that it might be 
useful to deploy an L3VPN underneath.)

> not capable of doing the necessary encapsulations. 

Why not do the translation at the PE? (this whole CE/PE thing really has 
to go - change it where you can. period).

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Apr 2002 07:40:50 -0700

Eric Rosen wrote:
> Joe> Why not do the translation at the PE? 
> 
> If you do the  translation at the PE, you need to  do the ARP mediation, and
> there's not  much point in doing  any more of a  translation than extracting
> the IP packet and reencapsulating it at the other end. 

For unicast, yes. For other ethernet behavior, there's more to do, though.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Apr 2002 10:17:54 -0700

Hi,

Thanks,
Lars
-- 
Lars Eggert <[email-masked]>           USC Information Sciences Institute

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Apr 2002 07:39:59 -0700

Eric Rosen wrote:
> Joe> this  whole  CE/PE  thing really  has  to  go  -  change it  where  you
> Joe> can. period
> 
> My comment on this is that it reflects a fundamental misunderstanding of the
> relationship between a Service Provider and its customers. 

Exactly.

If you have to use the words "service provider" and "customers", you're 
NOT talking about a protocol. (find those words ANYWHERE in ANY of the 
STDs, e.g.)

Joe

---

From: Dave McDysan <[email-masked]>
Date: Fri, 26 Apr 2002 11:39:16 -0400

In my opinion, the PPVPN working group is the right place to discuss this
(potential) service requirement. I think that this unecesarily complicates
the notion of a pseudo wire. After all, in a real wire, what one puts in on
one end comes out on the other, does it not?

I have had some discussions with our marketing people on this subject and
share the following comments from them with these lists.

First, it is difficult to determine what the mix of network layer protocols
are that are carried over legacy L2 networks (e.g., FR, ATM). The belief is
that a large majority of the traffic is IP, but there are some non-IP
network layer protocol applications as well.

The motivation for a network-based L2 VPN is to allow suppor for an arbitary
network layer protocol network. This is implemented in many FR, ATM, or
hybrid bridged or routed networks using the multiprotocol encapsulation and
(in)ARP mapping specified in RFCs 2684 and RFC 2427. At a high-level, the
interest is if Ethernet interfaces could be (easily) added to such networks,
then this would be of great interest.

Finally, if the support in an IP-only context in the environment of FR, ATM
and Ethernet access connections, a network-based L2 PPVPN solution that was
considerably simpler than an L3 PPVPN solution could be of interest. I
believe that Eric Rosen published a similar thought on this thread.

Dave

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
> Vainshtein
> Sent: Thursday, April 25, 2002 2:18 PM
> To: 'Shah, Himanshu'
> Cc: [email-masked]; [email-masked]; 'Giles Heron'; Eric
> Rosen (E-mail)

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Fri, 26 Apr 2002 13:29:05 -0400

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 10:18 AM
 
<snip>
> In order to have an L2VPN you must have the same L2 at the endpoints, 
> otherwise the semantics of the L2 are necessarily undefined. 

<snip>

Do you mean what draft-Martini has so far defined to be an L2VPN, or what
the market thinks of as L2VPNs?

If you meant the market, may I remind you there are thousands of 
enterprise networks that connect using Frame Relay at their branch
offices and ATM at their headquarters (where the network performs
FRF.8.1).  

> Joe

Prabhu

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 26 Apr 2002 16:07:36 -0400

Yushun,

I think you are misunderstanding what we are proposing.
There are quite a few people who believe that the 
accomodating heterogenity with simplicity of L2VPN
(even though it is limited to IP) is very useful.
ARP mediation draft simply fills some gaps for such
configurations. Nothing more, nothing less and rather
very straight forward.

I don't think it is necessary to debate the usefulness of
L2VPN vs L3VPN because of this draft.

/himanshu

BTW, IP address space is not compromised, nor are the MAC
addresses distributed across SP network. Please read the 
draft for clarifications.

> From: Yu-Shun Wang [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 2:47 PM
> To: [email-masked]
> Cc: Shah, Himanshu; 'Lars Eggert'; 'Giles Heron'; Sasha Vainshtein;
> [email-masked]; [email-masked]; Joe Touch
> Please see comments & questions inline.
> 
> Eric Rosen wrote:
> Ok, I agree that's debatable. But one purpose of IP is to 
> have a global
> naming/addressing space, and there's actually a working 
> routing architecture
> established for IP. Don't get me wrong, I am not saying it's 
> perfect, but it
> works. By introducing the ARP mediation, the effect is to 
> broker locally
> scoped (whether intentionally so or just a artifect of 
> deployment) address
> space across the Internet, and you still need to perform 
> packet encap-decap
> *just like what IP & ARP already do*.
> 
> Why go through the process of distributing more L2/MAC 
> address globally
> when one (IP) is already in place?
> 
> Since you brought up the "provider-client" dialog, I'll play 
> along. :-)
> The provider should say: "Listen, we know what you want, and 
> we can do it.
> But there's another solution that is already in place and 
> working (hint: IP).
> We can just build the VPN on top of that (and it's call L3VPN.)"
> If the marketing people can not do that, then I'd say the 
> provider(s) have
> a bigger problem and it's not technical.
> 
> The clients can ask for anything, but that doesn't mean as an 
> engineer,
> we need to comply all their requests or there isn't room to negotiate.
> (Or do we?)
> 
> yushun.
> ______________________________________________________________
> ______________
> Yu-Shun Wang <[email-masked]>               Information 
> Sciences Institute
>                                             University of 
> Southern California
> 
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 28 Apr 2002 08:40:56 -0700

> offices and ATM at their headquarters (where the network performs

Widescale deployment does not imply that a solution warrants 
standardization. It is often a symptom of the lack of an appropriate 
alternative, or at least the lack of appreciation or knowledge of 
existing, more generic and more capable alternatives.

Joe

---

From: Yu-Shun Wang <[email-masked]>
Date: Fri, 26 Apr 2002 13:32:02 -0700

Hi, Himanshu,

> L2VPN vs L3VPN because of this draft.

No. I am not saying L2VPN is less useful than L3VPN. That's a big
flame war to get into. Although I personally don't necessarily
agree to run L2 over WAN in anyway, if people want to use it,
I am not getting in their way now that it's in PPVPN's charter. :-)

My point is that, in the case you have the same L2 at different
sites, it's *NOT as complex* and you don't need to go further
steps to do ARP mediation. *When you have different L2*, then
why bother with the extra steps & protocols when you can simply
solve the problems with L3?

> addresses distributed across SP network. 

Actually, I didn't say IP address space is compromised by the
proposal. It's more like IP address space is being ignored
in the L2 ARP mediation process. I apologize if I misled you
in anyway, please point it out and I'll explain.

> Please read the draft for clarifications.

Sounds fair. I'll read it.

yushun.

>>>Yushun> My question  is, when you have  different L2 
>>
>>protocols  at the ends,
>>
>>>Yushun> isn't it  time to try L3  solutions? I just don't  
>>
>>see going through
>>
>>>Yushun> all this troubles  and inventing new protocols 
>>
>>justify  what you can
>>
>>>Perhaps there are some service providers who think that the 
>>
>>trouble involved
>>
>>>in providing the  necessary ARP mediation is possibly  less 
>>
>>than the trouble
>>
>>>>From the customer perspective, if the  customer wants an 
>>
>>L2VPN, I doubt that
>>
>>>the SP will be willing to say "look,  since we can't give 
>>
>>you the same L2 at
>>
>>>both ends, you need to use an  L3VPN service; after all, 
>>
>>you don't expect us
>>

-- 
____________________________________________________________________________
Yu-Shun Wang <[email-masked]>               Information Sciences Institute
                                            University of Southern California

---

From: Tony Tauber <[email-masked]>
Date: Fri, 26 Apr 2002 15:39:37 -0400 (EDT)

> > Yushun> simply do with L3 (i.e., IP).

After your first post I thought "Bingo!" and this one just brings
out more wisdom.  When will people stop this madness?

I'm a Service Provider and I think I can boil down the *reasonable*
requirements I see to these:

--Support for overlapping IP address space.

--The ability to move traffic with a different policy than the global
  routing table and hop-by-hop routing, ie. policy routing.
  This feature serves the overlapping address space and should also
  provide the capability to "plug stuff in here and get it to come out
  there" arbitrarily.

--The ability to keep other clients of the network from attacking that
  traffic via spoofing or source-routing.

Encapsulating in IP such as with GRE or IPsec (maybe L2TP also?)
would, I believe, mostly fit the bill (modulo possible security
nits with GRE?).  Now one hurdle to doing those on a PE, would appear
to be scaling and speed.  MPLS might have the benefit of already being
done in hardware and keeping less peer-to-peer state in some cases.
(Not so sure about that, I'll defer to the real MPLS experts in the
audience.)  Also, encapsulating in IP allows for global reach;
MPLS, being L2 itself, shouldn't cross Provider boundaries.

I don't know that there's really that much demand for passing traffic
that isn't really, at the customer level, IP.  I'd argue that
customers who are using those better really understand from their SP
what the capabilities of the network are in terms of ordering, etc.

Tony

> > trouble involved in providing the  necessary ARP mediation is
> > possibly  less than the trouble involved in providing an L3VPN
> > service.
>
> Ok, I agree that's debatable. But one purpose of IP is to have a
> global naming/addressing space, and there's actually a working
> routing architecture established for IP. Don't get me wrong, I am
> not saying it's perfect, but it works. By introducing the ARP
> mediation, the effect is to broker locally scoped (whether
> intentionally so or just a artifect of deployment) address space
> across the Internet, and you still need to perform packet
> encap-decap *just like what IP & ARP already do*.
>
> Why go through the process of distributing more L2/MAC address
> globally when one (IP) is already in place?
>
> > From the customer perspective, if the  customer wants an L2VPN, I
> > doubt that the SP will be willing to say "look,  since we can't
> > give you the same L2 at both ends, you need to use an  L3VPN
> > service; after all, you don't expect us to go to any extra trouble
> > for you, do you?"
>
> Since you brought up the "provider-client" dialog, I'll play along.
> :-) The provider should say: "Listen, we know what you want, and we
> can do it.  But there's another solution that is already in place
> and working (hint: IP).  We can just build the VPN on top of that
> (and it's call L3VPN.)" If the marketing people can not do that,
> then I'd say the provider(s) have a bigger problem and it's not
> technical.
>
> engineer, we need to comply all their requests or there isn't room
> to negotiate.  (Or do we?)
>
> yushun.

---

From: Ali Sajassi <[email-masked]>
Date: Sun, 28 Apr 2002 23:25:28 -0700

One of the underlying premises of routed interworking (aka IP L2 
interworking) is that we can do the interworking between disparate 
Attachment VCs (the circuits between CEs and PEs) without touching the CEs 
(e.g., any config. changes). If this was true and if we could apply the ARP 
mediation mechanism to different L3 protocol other than IP, then it would 
have justify its complexity. However, it falls short of that. And Besides 
this mechanism introduces additional complexity to the PEs and still there 
are situations that can not be handled or requires special configuration at 
CE (e.g., OSPF and IS-IS as described in the draft).

In scenarios where one Attachment VC is Ethernet and the other is ATM or 
FR, then Bridged interworking is a simpler approach and doesn't require any 
ARP mediation and passing of IP addresses over the network and it should be 
considered first. However, it would required the CE to be configured to 
support bridged encap instead of routed encap over their Attachment VCs. By 
using Bridged encap, we don't need to perform any ARP mediation in the PEs. 
It also handles different L3 protocols and makes them transparent to the PEs.

-Ali

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Mon, 29 Apr 2002 10:14:29 -0400

Which point are you trying to make?  
	
* You tried to make a point that all endpoints of an L2VPN must be
  the same.  
	* I pointed out that FRF.8.1 allows one endpoint to be
	  FR and the other to be ATM.
* You tried to make a point that widescale deployment does
  not warrant standardization.
	* I point out that FRF.8.1 is considered a standard and
  	  has many interoperable versions in deployment.

* Perhaps you are making the point that L3VPNs are superior to L2VPNs and
  therefore the PPVPN working group should focus primarily on standards
  efforts to promote L3VPNs over efforts to extend IP over L2VPNs.
	* I respond to that by stating, all academic arguments on IETF
	  mailing lists aside, the best measure of whether something is
	  useful is whether end customers buy the service.  If you have
	  data showing that the majority of enterprise customers are 
	  dumping their L2VPNs since L3VPN services are now available,
please
	  enlighten me.

Prabhu

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Mon, 29 Apr 2002 10:14:28 -0400

There is a comfort level that enterprises have with L2VPN services that
most simply do not have with L3VPN services today.  They vote with their
pocketbooks for L2VPN services to the tune of $18B/year worldwide.  

So you are stating that rather than accomodate these enterprises with
a fairly simple (and to the enterprises a rather transparent) extension,
that the enterprises should completely change their intranet model
just to accommodate what some believe is a better VPN model?  

Prabhu

> Subject: [PWE3] Re: Is IP Layer 2 Interworking useful?
> 
> 
> Hi,
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 29 Apr 2002 10:43:54 -0400

Irrespective of that, I think the point remains.

The simplicity of L2VPN is perhaps far more
attractive for some SPs over L3VPN. It is rather
unfortunate to force the user to move to a more
complex solution when it is possible to provide
a  solution wih the simplicity the user prefers. 

I believe Eric did make this point in 
this thread earlier.

It is fruitless to argue L2VPN vs L3VPN. Both has
equal merits and ARP mediation draft does not
displace one over other.

/himanshu

> From: Jim Guichard [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 10:23 AM
> To: Kavi, Prabhu; Joe Touch
> Cc: Yu-Shun Wang; Shah, Himanshu; 'Lars Eggert'; 'Giles Heron'; Sasha
> Vainshtein; [email-masked]; [email-masked]
> Subject: RE: [PWE3] RE: Is IP Layer 2 Interworking useful?
> 
> 
> Prabhu,
> 
> I cannot provide you with independent sources of data to support the
> migration of Enterprise networks to a L3VPN. However, I can 
> tell you that
> many of the large SPs I deal with are seeing an aggressive 
> move on the part
> of their customers toward a L3VPN and indeed in many cases are losing
> business if they do not provide the service. Jim
> 
> > >From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Kavi,
> > >Prabhu
> > >Sent: Monday, April 29, 2002 10:14 AM
> > >To: Joe Touch; Kavi, Prabhu
> > >Cc: Yu-Shun Wang; Shah, Himanshu; 'Lars Eggert'; 'Giles 
> Heron'; Sasha
> > >Vainshtein; [email-masked]; [email-masked]

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Mon, 29 Apr 2002 11:03:11 -0400

Jim,

I am not against L3VPNs.  For customers that want it, great.  

I am only responding to those that state L3VPN standards should be promoted 
to the detriment of L2VPNs, and that L2VPNs were only bought because
there were no other alternatives available.  Both will exist, and both
should be supported.

Prabhu

---

From: Ajay Simha <[email-masked]>
Date: Mon, 29 Apr 2002 11:09:05 -0400 (Eastern Daylight Time)

On Mon, 29 Apr 2002, Shah, Himanshu wrote:

SH>Irrespective of that, I think the point remains.
SH>
SH>The simplicity of L2VPN is perhaps far more
SH>attractive for some SPs over L3VPN. It is rather
SH>unfortunate to force the user to move to a more
SH>complex solution when it is possible to provide
SH>a  solution wih the simplicity the user prefers.

Again there are two perspectives here:
 - From SPs point of view
 - From SPs customers' point of view

IMHO the SP will do whatever is needed to sell services to their customers.
There seem to be quite a few customers who'd rather not deal with their own
routing and at the same time they don't want to deal with outsourcing their
WAN routing to someone else. These folks are going to continue to be prime
candidates for L3VPNs and not L2VPNs. The counter argument holds good for
L2VPNs.

-ajay

SH>
SH>I believe Eric did make this point in
SH>this thread earlier.
SH>
SH>It is fruitless to argue L2VPN vs L3VPN. Both has
SH>equal merits and ARP mediation draft does not
SH>displace one over other.
SH>
SH>/himanshu
SH>
SH>> -----Original Message-----
SH>> From: Jim Guichard [mailto:[email-masked]]
SH>> Sent: Monday, April 29, 2002 10:23 AM
SH>> To: Kavi, Prabhu; Joe Touch
SH>> Cc: Yu-Shun Wang; Shah, Himanshu; 'Lars Eggert'; 'Giles Heron'; Sasha
SH>> Vainshtein; [email-masked]; [email-masked]
SH>> Subject: RE: [PWE3] RE: Is IP Layer 2 Interworking useful?
SH>>
SH>>
SH>> Prabhu,
SH>>
SH>> I cannot provide you with independent sources of data to support the
SH>> migration of Enterprise networks to a L3VPN. However, I can
SH>> tell you that
SH>> many of the large SPs I deal with are seeing an aggressive
SH>> move on the part
SH>> of their customers toward a L3VPN and indeed in many cases are losing
SH>> business if they do not provide the service. Jim
SH>>
SH>> > >-----Original Message-----
SH>> > >From: [email-masked] [mailto:[email-masked]]On
SH>> Behalf Of Kavi,
SH>> > >Prabhu
SH>> > >Sent: Monday, April 29, 2002 10:14 AM
SH>> > >To: Joe Touch; Kavi, Prabhu
SH>> > >Cc: Yu-Shun Wang; Shah, Himanshu; 'Lars Eggert'; 'Giles
SH>> Heron'; Sasha
SH>> > >Vainshtein; [email-masked]; [email-masked]
SH>> > >Subject: [PWE3] RE: Is IP Layer 2 Interworking useful?
SH>> > >
SH>> > >
SH>> > >Which point are you trying to make?
SH>> > >
SH>> > >* You tried to make a point that all endpoints of an L2VPN must be
SH>> > >  the same.
SH>> > >	* I pointed out that FRF.8.1 allows one endpoint to be
SH>> > >	  FR and the other to be ATM.
SH>> > >* You tried to make a point that widescale deployment does
SH>> > >  not warrant standardization.
SH>> > >	* I point out that FRF.8.1 is considered a standard and
SH>> > >  	  has many interoperable versions in deployment.
SH>> > >
SH>> > >* Perhaps you are making the point that L3VPNs are
SH>> superior to L2VPNs and
SH>> > >  therefore the PPVPN working group should focus primarily
SH>> on standards
SH>> > >  efforts to promote L3VPNs over efforts to extend IP over L2VPNs.
SH>> > >	* I respond to that by stating, all academic arguments on IETF
SH>> > >	  mailing lists aside, the best measure of whether something is
SH>> > >	  useful is whether end customers buy the service.  If you have
SH>> > >	  data showing that the majority of enterprise customers are
SH>> > >	  dumping their L2VPNs since L3VPN services are now available,
SH>> > >please
SH>> > >	  enlighten me.
SH>> > >
SH>> > >Prabhu
SH>> > >
SH>> > >
SH>> > >>
SH>> > >> Kavi, Prabhu wrote:
SH>> > >> >>-----Original Message-----
SH>> > >> >>From: Joe Touch [mailto:[email-masked]]
SH>> > >> >>Sent: Friday, April 26, 2002 10:18 AM
SH>> > >> >
SH>> > >> >
SH>> > >> > <snip>
SH>> > >> >
SH>> > >> >>In order to have an L2VPN you must have the same L2 at the
SH>> > >> endpoints,
SH>> > >> >>otherwise the semantics of the L2 are necessarily undefined.
SH>> > >> >
SH>> > >> > <snip>
SH>> > >> >
SH>> > >> > Do you mean what draft-Martini has so far defined to be an
SH>> > >> L2VPN, or what
SH>> > >> > the market thinks of as L2VPNs?
SH>> > >> >
SH>> > >> > If you meant the market, may I remind you there are
SH>> thousands of
SH>> > >> > enterprise networks that connect using Frame Relay at
SH>> their branch
SH>> > >> > offices and ATM at their headquarters (where the
SH>> network performs
SH>> > >> > FRF.8.1).
SH>> > >>
SH>> > >> Widescale deployment does not imply that a solution warrants
SH>> > >> standardization. It is often a symptom of the lack of an
SH>> appropriate
SH>> > >> alternative, or at least the lack of appreciation or knowledge of
SH>> > >> existing, more generic and more capable alternatives.
SH>> > >>
SH>> > >> Joe
SH>> > >
SH>> > >
SH>> > >_______________________________________________
SH>> > >pwe3 mailing list
SH>> > >[email-masked]
SH>> > >https://www1.ietf.org/mailman/listinfo/pwe3
SH>>
SH>>
SH>

--

---

From: Tony Tauber <[email-masked]>
Date: Mon, 29 Apr 2002 16:16:54 -0400 (EDT)

>  - From SPs customers' point of view

You forgot:
- From SPs Marketing Department
- From SPs Equipment Vendor's Marketing Department

The fact that those last two do frequent end-runs around
SPs Engineering Department is part of what contributes to the brokenness.

Seriously, the feedback is far from perfect.
Don't assume that a real-world need is necessarily in evidence.

> IMHO the SP will do whatever is needed to sell services to their
> customers.  There seem to be quite a few customers who'd rather not
> deal with their own routing and at the same time they don't want to
> deal with outsourcing their WAN routing to someone else. These folks
> are going to continue to be prime candidates for L3VPNs and not
> L2VPNs. The counter argument holds good for L2VPNs.
>
> -ajay

The SP want's to make a profit (yeah, that'll happen).  A "solution"
to bring in some amount of revenue has to be balanced against not only
the cost of the solution (to ensure profitability) but the long-term
strategy of being able to scale to maximize profits for all services
into the future.  Starting with something that might (and I'm not
saying for sure it's the case here) not scale to the necessary size
and may endanger other customers' services is a bad move.

I'm not commenting on the ARP mediation or whatever draft brought
the discussion to this point; nonetheless, I think the larger
critique is germane.

Tony

---

From: "Khalid Ahmad"<[email-masked]>
Date: Tue, 30 Apr 2002 12:16:34 -0400

Hi Maarten,

could you explain what means "ethernet MAC trail" or "IP trail" in your
description below ?

I always assumed these were connectionless mechanisms and therefore do not
require the concept of a connection (or trail as the transport people want
to say).

I also notice you classify ATM as a L1 protocol in you interesting diagram
below.  I was always assuming it was treated as a L2 mechanism.  Is this
just a typo, or did something change ?

In any case, it is nice to see you are continuing to try to inject some
order in this chaotic protocol layering business !

Regards,
Khalid

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 4:35 AM
To: [email-masked]; [email-masked]
Subject: [PWE3] Re: Is IP Layer 2 Interworking useful?

In my understanding, a layer X VPN provides transparent transport of layer X
information elements. E.g. an Ethernet VPN provides transparent transport of
Ethernet MAC frames between between the N access points of a customer. An IP
VPN
provides transparent transport of IP packets between the N access points of
a
customer.

Both Ethernet VPN as well as IP VPN use an underlying transport layer to
provide
an access link to the first Ethernet [IP] switching element in the network.
For
the case of IP VPN, the IP access link can be supported by an Ethernet MAC
trail
(but it can also be an MPLS trial, SDH VC-n trail, etc.). For the case of
Ethernet, the access link can be supported by an Ethernet PHY trail (but it
can
also be an MPLS trail, SDH VC-n trail, IP trail, etc.).

Access link technology may differ; e.g. access point 1 may use technology A,
while access point 2 may use technology B, etc.

So in case an Ethernet MAC technology is used to connect a customer to an IP
router/switch, and transparency is at IP packet layer level, then we should
refer to this as an IP VPN (of which one or more IP access links are
supported
by Ethernet MAC layer trail(s)).

And in case an Ethernet PHY technology is used to connect a customer to an
Ethernet MAC bridge/switch, and transparency is at the Ethernet MAC layer
level,
then we should refer to this as an Ethernet (MAC) VPN (of which one or more
Ethernet (MAC) access links are supported by Ethernet PHY layer trail(s)).

Regards,

Maarten
PS. the use of L2, L2.5, L3 gets cumbersume these days as we are carrying
Ethernet MAC (L2) over MPLS (L2.5) or over IP (L3), and we carry MPLS
(L2.5), IP
(L3), E1/T1 (L1), etc over Ethernet MAC (L2), and we will carry SDH/SONET
over
MPLS, PDH over Ethernet and ...

  --------  ------------
  |  IP  |  | SDH VC-n |
  | (L3) |  |   (L1)   |
  -----------------------  --------  ----------------
  |        MPLS         |  |  IP  |  | PDH E1/T1/.. | 
  |       (L2.5)        |  | (L3) |  |   (L1)       |
 
----------------------------------------------------------------------------
--
  |                            ETH MAC
|
  |                             (L2)
|
 
----------------------------------------------------------------------------
--
  | ETH PHY |  | MPLS |  |  IP  |  | SDH VC-n |  | OTN ODUk |  | ATM VC | 
  |  (L1)   |  |(L2.5)|  | (L3) |  |  (L1)    |  |   (L1)   |  |  (L1)  |
  -----------  --------  --------  ------------  ------------  ----------
       |       | XXX  |  | XXX  |  |   XXX    |  |   XXX    |  |  XXX   |

Similar figures can be made with MPLS as focus layer, or IP as focus layer,
or
SDH VC-n as focus layer, etc.

What we see is that what traditionally is referred to as L3 and L2.5 is
being
used as L1. Also what is traditionally referred to as L1 is becoming
transported
over L3, L2.5 and L2 technologies. I.e. the numbering is getting very
arbitrary
and as such I would prefer to simply use the layer names (instead of some
arbitrary numbers representing those layers).

"Joel M. Halpern" wrote:
> 
> I would disagree.
> What is being discussed is a VPN with two properties that are relevant to
> this part of the debate:
> 1) It has dissimilar access media at different points
> 2) At the IP routing layer, it is transparent to the customer.  He sees a
> set of connections among his sites.
> This is something customer want and find useful.
> It is most similar in behavior o a L2 VPN.  But sure, call it something
> different if you want.  Call it an L2+ or L2.5 or L3- or anything else
that
> makes you happy.  Sure, it is a hybrid.  But it meets a real need.
> 
> Yours,
> Joel M. Halpern
> 
> At 09:58 AM 4/29/2002 -0700, Joe Touch wrote:
> >An L2VPN with different endpoint protocols is, IMO, NOT an L2VPN
> >(marketing alone does not make it so). It's an L3VPN that tries to get
> >around looking at the L3 header by translating L2 headers.
>

---

From: [email-masked]
Date: Tue, 30 Apr 2002 17:37:49 +0100

Maarten......nice attempt at sanity, but the issue is architecturally more
fundamental.

1st, there is no such thing as L1,2,3 'networks' or whatever, this
nomenclature is meaningless at best and confuses at worst.  They are *all*
networks if they have unique access point addresses and connectivity can be
established between these access point addresses....IMO if you want to
impose some network classifications there are only 3, viz  cnls, co pkt-sw
and co cct-sw, and each has various technology flavours.

The main gripe I have with this thread is that there seems to be no common
grasp/understanding of the architectural difference/significance between
addresses, names and link-connection identifiers.....I get the feeling
people are using them in any expedient way that suits an immediate problem
at the expense of the risk of bigger problems later (this has a very familar
ring to it for other threads/topics I've tracked).  

In summary:
-	Addresses identify access points of layer networks....addresses
carry semantics of location (and this property can be used for aggregation
*if* you allocate addresses wisely).
-	Names identify objects *external* to a network.....names carry no
semantics of location, they just identify the object.
BTW - Mac addresses are actually *not* addresses...they are strictly names
-	link-connection identifiers are emphemeral local (single-hop)
identifiers that only exist, and strictly only have meaning within the
context of, a co trail object when this is created between the addressable
access points of layer network X, eg labels, dlcis, vpis/vcis.

Arp/InArp are protocols that are used to bind external named objects to
addressable access points......you should not be binding addresses (or
names) to link-connection identifiers in some arbitrary *peer networking*
sense....when I read the Arp mediation draft this is the feeling I get from
it.

Having said that, a trail in layer network N (ie between addressable access
points in layer network N) is used to create a link-connection in layer N-1,
and this is indeed how we create recursive network topologies (aka
TE)....note that this is a *client/server* relationship and not a peer
relationship.  However, in this latter case what we have is a
link-connection (of the client layer) being bound to an addressable access
point of the server layer.....so in this case the client link-connection is
*external* to layer network N and in a strict arch sense should only now
have the semantics of a Named object.

It's my view that unless we are all clear on these key arch differences,
then people will continue to have confusion as to what is actually going on
in the Arp mediation draft...however, experience tells me I should not be
optimistic on this happening.

regards, Neil

> Sent: 30 April 2002 09:35
> Ethernet MAC frames between between the N access points of a 
> customer. An IP VPN
> provides transparent transport of IP packets between the N 
> access points of a
> customer.
> 
> Both Ethernet VPN as well as IP VPN use an underlying 
> transport layer to provide
> an access link to the first Ethernet [IP] switching element 
> in the network. For
> the case of IP VPN, the IP access link can be supported by an 
> Ethernet MAC trail
> Ethernet, the access link can be supported by an Ethernet PHY 
> trail (but it can
> refer to this as an IP VPN (of which one or more IP access 
> links are supported
> Ethernet MAC bridge/switch, and transparency is at the 
> Ethernet MAC layer level,
> Ethernet MAC (L2) over MPLS (L2.5) or over IP (L3), and we 
> carry MPLS (L2.5), IP
> (L3), E1/T1 (L1), etc over Ethernet MAC (L2), and we will 
> carry SDH/SONET over
> --------------------------------------------------------------
> ----------------
>   |                            ETH MAC                        
>                  |
>   |                             (L2)                          
>                  |
>   
> --------------------------------------------------------------
> ----------------
> Similar figures can be made with MPLS as focus layer, or IP 
> as focus layer, or
> What we see is that what traditionally is referred to as L3 
> and L2.5 is being
> used as L1. Also what is traditionally referred to as L1 is 
> becoming transported
> over L3, L2.5 and L2 technologies. I.e. the numbering is 
> getting very arbitrary
> > different if you want.  Call it an L2+ or L2.5 or L3- or 
> anything else that

---

From: [email-masked]
Date: Tue, 30 Apr 2002 18:42:33 +0100

Hi Khalid,
 
Ethernet is based on names.  It has no strict concept of addresses (unlike
IP say).  Ethernet is therefore not even cnls...its a broadcast medium.  And
Vlan tags in such a context are a 'group of names'
 
IP is truly cnls and has proper addressing..........there is no such thing
as a cnls trails so I agree with you on this.
 
L1,2,3 mean nothing....see my last posting.
 
regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 30 April 2002 17:17
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: Is IP Layer 2 Interworking useful?

Hi Maarten, 

Regards, 
Khalid 

-----Original Message----- 
From: Maarten Vissers [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, April 30, 2002 4:35 AM 
To: [email-masked]; [email-masked] 
Subject: [PWE3] Re: Is IP Layer 2 Interworking useful? 

Regards, 

Maarten 

  --------  ------------ 
  |  IP  |  | SDH VC-n | 
  | (L3) |  |   (L1)   | 

that 
> >around looking at the L3 header by translating L2 headers. 
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "Khalid Ahmad"<[email-masked]>
Date: Tue, 30 Apr 2002 14:09:17 -0400

Hi Neil,
 
I have been following you comments on the pwe3 list and elsewhere with great
interest, and appreciate your clarifications !
 
While I understand the distinction you are trying to make between addresses
and names in your earlier email, I am not sure what you say for ethernet is
entirely valid.  I was led to understand a MAC address is a globally unique
address, as specified by IEEE.  I never heard of it as MAC name, and it
identifies a host irrespective of location.
 
I understand ethernet as connectionless because MAC frames are transmitted
without prior need to establish any connection on the physical medium,
whether broadcast or switched.
 
As regards L1, L2, etc., I think these still have meaning in the context of
OSI modeling and standards descriptions generally.  Perhaps I'm
old-fashioned, but I think these concepts are still useful from protocol
architecture point of view.  Of course people can misuse these concepts for
their own ends, but that does not detract from their utility for convenient
grouping of protocol functionality.
 
Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 1:43 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PWE3] Re: Is IP Layer 2 Interworking useful?

Hi Khalid,

 
 
regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 30 April 2002 17:17
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: Is IP Layer 2 Interworking useful?

Hi Maarten, 

Regards, 
Khalid 

-----Original Message----- 

Regards, 

Maarten 

  --------  ------------ 
  |  IP  |  | SDH VC-n | 
  | (L3) |  |   (L1)   | 

that

---

From: John Drake <[email-masked]>
Date: Tue, 30 Apr 2002 10:47:20 -0700

Snipped

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 10:43 AM
To: [email-masked]; [email-masked]; [email-masked];

[John Drake]  You sound like a French existentialist 
 
regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 30 April 2002 17:17

Hi Maarten, 

Regards, 
Khalid 

-----Original Message----- 

Regards, 

Maarten 

  --------  ------------ 
  |  IP  |  | SDH VC-n | 
  | (L3) |  |   (L1)   | 

that

---

From: [email-masked]
Date: Tue, 30 Apr 2002 23:18:59 +0100

Khalid Ahmad  wrote 30 April 2002 19:09

 <snip>
 While I understand the distinction you are trying to make between addresses
and names in your earlier email, I am not sure what you say for ethernet is
entirely valid.  I was led to understand a MAC address is a globally unique
address, as specified by IEEE.  I never heard of it as MAC name, and it
identifies a host irrespective of location. 
NH=> Well your last sentence is actually a good definition of a Name...it
identifies a host (ie something that connects to a network) irrespective of
location......whereas location identifiers define Addresses.  Have a think
about it....or maybe have a chat to Dave Allan in your org....he is pretty
clued on these type of matters.
 
I understand ethernet as connectionless because MAC frames are transmitted
without prior need to establish any connection on the physical medium,
whether broadcast or switched. 
NH=> An ethernet pkt is indiscriminately sent to everyone on the local media
(bit like shouting someone's name in a crowd), but only the Named target is
supposed 'act' on hearing their name.  Cnls pkts are not normally broadcast
to everyone, but they have a specific target network access point....the
named individual attached to that access point might be determined by a MAC
identifier.  Further, across a network cnls pkts are normally sent as a
hop-by-hop routing sequence, where each hop is memoryless/independent of
previous/future hops.  These are quite distinct behaviours and I am
surprised you are confusing them.
 
As regards L1, L2, etc., I think these still have meaning in the context of
OSI modeling and standards descriptions generally.  Perhaps I'm
old-fashioned, but I think these concepts are still useful from protocol
architecture point of view.  Of course people can misuse these concepts for
their own ends, but that does not detract from their utility for convenient
grouping of protocol functionality. 
NH=> Its nothing to do with being old-fashioned, its about being precise.
These terms are being used by many people to mean the wrong things.  For
example, what if I have a network stack of
IP->FR->ATM->MPLS-ethernet->SDH->MPLS->-IP (I could go on, and up/down other
concatenated client/server stacks till the cows come home......and this is
another problem, if there are no bounds/restrictions on the number/type of
these relationships the end-end application may not even work!).  This is
allowable in theory...so who is L1/2/3 here?  L1/2/3 classifications mean
absolutely nothing....surely you must see this?  The trite OSI model assumes
there is only *ever* one L3 network....it makes no judgement on whether this
L3 network is cnls, co pkt-sw or co cct-sw.....it is *us* who place that
(incorrect) interpretation on it, and most seem to assume L3~cnls which is
not true.  The only place I have ever seen this correctly described was in a
book written by a colleague of mine, Andy Reid (and Mike Sexton) where each
layer network (ie true L3 network) had the full OSI stack at its trail
termination point........but that layers 4-7 of the OSI model are
effectively null at these points.   The OSI model has almost no real world
use......L3 networks are multifold and nested.

Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 1:43 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked]; [email-masked];

Hi Khalid,

 
 
regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 30 April 2002 17:17
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: Is IP Layer 2 Interworking useful?

Hi Maarten, 

Regards, 
Khalid 

-----Original Message----- 

Regards, 

Maarten 

  --------  ------------ 
  |  IP  |  | SDH VC-n | 
  | (L3) |  |   (L1)   | 

that

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 01 May 2002 09:23:35 +0200

Khalid,

> Khalid Ahmad wrote:
> require the concept of a connection (or trail as the transport people want to
> say).

To be fully compliant with the specifications in draft Rec. G.cls (Functional
architecture of connectionless layer networks) I should have used "ethernet MAC
connectionless trail" and "IP connectionless trail". My wording was a bit
sloppy; sorry for the confusion.

>From G.cls:
3.12	Connectionless trail: A "transport entity" responsible for the transfer of
information from the input of a flow termination source to the output of a flow
termination sink. The integrity of the information transfer may be monitored. It
is formed by combining flow termination functions and a flow. A connectionless
trail is only valid for individual datagrams.

E.g. when router X with MAC flow termination A is connected to a router Y with
MAC flow termination B there exists an ethernet MAC connectionless trail between
MAC flow termination A and MAC flow termination B which supports an IP Link
carrying IP packets between routers X and Y.

> below.  I was always assuming it was treated as a L2 mechanism.  Is this just
> a typo, or did something change ?

It's not a true typo... when typing I wrote "L1" and when rereading the email
text I noticed the L1 and considered this with respect to the reference to ATM
as "L2" in the PWE3 correspondence... as layer numbering is arbitrary I didn't
change the original L1 indication I typed... but if people feel better when ATM
is referred to as L2, there is no objection to modify the figure...

> 
> In any case, it is nice to see you are continuing to try to inject some order
> in this chaotic protocol layering business !

And with some success last week in the Metro Ethernet Forum, where we agreed to
a 3 layer basic model for ethernet networks (application layer(s), ethernet MAC
layer, transport layer(s))... the focus for the MEF will be the ethernet MAC
layer with the application layers as second priority...

On Thursday there will be an Ethernet layer network architecture discussion in
Q.12/15 (ITU-T SG15 meeting is ongoing), to support the ethernet over transport
(SDH/OTN) work that is ongoing in the industry. As the "Ethernet link" is an
abstraction of the underlying transport layer trails, the ethernet layer network
model also supports ethernet links supported by MPLS trails, IP connectionless
trails, ATM VC trails, etc.

Yesterday it was agreed to start also work on MPLS layer network architecture
within Q.12/15 correspondence after this SG15 meeting. As MPLS is a connection
oriented technology we can base this work on G.805 and I.326.

Support for this work is more than welcome... 

Regards,

Maarten

> provides transparent transport of IP packets between the N access points of a
> customer.
> 
> refer to this as an IP VPN (of which one or more IP access links are supported
> 
> Ethernet MAC (L2) over MPLS (L2.5) or over IP (L3), and we carry MPLS (L2.5),
> IP
> (L3), E1/T1 (L1), etc over Ethernet MAC (L2), and we will carry SDH/SONET over
> 
> ------------------------------------------------------------------------------
> 
>   |                            ETH MAC
> |
>   |                             (L2)
> |
> 
> ------------------------------------------------------------------------------
> 
> Similar figures can be made with MPLS as focus layer, or IP as focus layer, or
> 
> What we see is that what traditionally is referred to as L3 and L2.5 is being
> > different if you want.  Call it an L2+ or L2.5 or L3- or anything else that

---

From: Giles Heron <[email-masked]>
Date: 01 May 2002 16:59:46 +0000

> sloppy; sorry for the confusion.

I'm not sure that the IETF bases its work on G.cls?

> trail is only valid for individual datagrams.

this sounds a bit like trying to push a square peg into a round hole... 
Or rather if the only tool you have is a trail then every network entity
starts to look like a trail (to change analogy mid-paragraph).

> carrying IP packets between routers X and Y.

but didn't you just say the connectionless trail was only valid for
individual datagrams?  in which case each IP packet rides its own trail?

[snip]
> layer with the application layers as second priority...

the 3 layer model for Ethernet (i.e. everything above Ethernet, Ethernet
MAC and Ethernet PHY) seems self-evident.

But I thought the Ethernet MAC was finished (and has been for years). 
Guess I'm wrong again :(

> oriented technology we can base this work on G.805 and I.326.

Sounds like another round of the "MPLS is just another layer network",
"oh no it isn't" wars :(

Giles

---

From: Brijesh Kumar <[email-masked]>
Date: Tue, 30 Apr 2002 10:55:52 -0700

Joe,

I think both of you made a very similar and valid points.

A VPN should be classified by the type of service that it offers to its
customer. This clearly defines L2-VPNs and L3 VPNs as separate well
understood technologies. It has been undoubtedly proven that both types of
VPNs are useful, and each has certain benefits over others in some specific
scenarios. This thread started because the original thread creator wrongly
tried to classify the VPNs based on the forwarding mechanism used in the
core network.

Cheers,

--brijesh
Corona Networks Inc.

> From: Joe Touch [mailto:[email-masked]]
>
> 
> Joel M. Halpern wrote:
> > I would disagree.
> > What is being discussed is a VPN with two properties that 
> are relevant 
> > to this part of the debate:
> > 2) At the IP routing layer, it is transparent to the 
> customer.  He sees 
> > a set of connections among his sites.
> anything else 
> > that makes you happy.  Sure, it is a hybrid.  But it meets 
> a real need.
> 
> Agreed. We seem to be continuing to confuse the service 
> offered with the 
> method used to offer the service.
> 
> In this case, the service offered is L2VPN.
> 
> That service can (and perhaps should, IMO) be offered by an L3VPN, so 
> that the translation of service is handled by extant IP 
> protocols. This 
> avoids reinventing these IP protocols within the VPN.
> 
> Joe
> 
> 
>