Subject: issue in draft-martini-ethernet-encap-mpls-00.txt

From: "Claude Kawa"<[email-masked]>
Date: Wed, 17 Apr 2002 10:31:45 -0400

I will ask my same question referencing
draft-martini-ethernet-encap-mpls-00.txt this time.

It is unspecified in draft-martini-ethernet-encap-mpls-00.txt) what piece(s)
of protocol control information received in an Ethernet frame from a CE, a
PE  will use to select the right PE-PE LSP.

We can use:
1-IP addresses carried in ethernet frames from a CE to PE to select the
right PE-PE LSP, 
2-we can also use ethernet MAC addresses with or without the VLAN id to
select the LSP, 
3-we can also use just a VLAN id as a local id between a CE and PE for the
LSP selection, 
4-finally, the PE can use other control information carried in the ethernet
frame received by the PE to select the VC LSP.

It is important that Etherent/PW draft specifies which method(s) is/are used
so that the CE and PE are in sync in terms of what is required to select the
right LSP to avoid incompatibilities between CE and PE implementations.

claude kawa

---

From: Giles Heron <[email-masked]>
Date: 17 Apr 2002 15:43:16 +0000

> right LSP to avoid incompatibilities between CE and PE implementations.

The WG charter says:

"The basic idea of this working group is to develop standards for the
encapsulation and service emulation of pseudo wires: encapsulating
service-specific PDUs arriving at an ingress logical port and carrying
them across a tunnel, managing their timing, order or other aspects
entering and leaving the tunnel, to emulate the behavior and
characteristics of the service as well as possible. Applicability
statements for each service will describe expected shortfalls of the
emulation's faithfulness."

it seems that you are asking how we standardise the selection of a
logical port?  I think this is out of scope?

(BTW - I'm not saying this isn't important, I'm just saying it is out of
scope for the WG as chartered...)

Giles

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

---

From: Giles Heron <[email-masked]>
Date: 17 Apr 2002 17:06:24 +0000

On Wed, 2002-04-17 at 15:44, Claude Kawa wrote:
> 
> Giles
> 
> By analogy with frame relay or ATM, in the case of FR, the DLCI used between
> the CE and PE allows the PE to select a PE-PE LSP. Same thing with ATM, the
> VPCI and VCI are used to select the LSP. Now in the case of Ethernet what is
> the equivalent piece of information we use to select the LSP?

Physical port or VLAN typically.  other things are possible - as you
yourself have suggested.

> I have identified a number of ways. Consistency between CE and PE is
> important.

agreed.

> In the following figure for example how PE1 selects LSP1 vs. LSP2 for
> ethernet frames coming from CE1 and destined to either CE2 or CE3?. What
> information in the ethernet frame coming from CE1 PE1 should use? 

it can use whatever it is configured to use.  VLAN is most likely if
there is a single physical connection from CE1-PE1.  That's certainly
how my network operates :)
 
> Should not the draft provide a method to ensure we have consistent
> implementations between CE and PE?

The CE shouldn't need to know anything about PWE3 and its protocols in
order to use the service.

All we need is something that the CE *does* know about and that the PE
can act on.  Ports, VLANs, MAC addresses would all seem to be examples
of this.  While it may be worth specifiying what some of these are, you
need to be careful not to say (for example) "if you are doing VLAN
encapsulation then you MUST use the VLAN ID to distinguish between
differenet PWs".  We don't want to pin this service down so that it
can't be used for anything beyond what we envisage today.

in any case, to repeat myself, this appears to be out of scope for PWE3
as chartered.

Giles

> CE1----PE1....LSP1....PE2----CE2
>         .
>         .
>        LSP2
>         .
>         .
>        PE3
>         |
>         |
>        CE3
> 
> 
> Claude
> 
> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 11:43 AM
> To: Kawa, Claude [CAR:CS49:EXCH]
> Cc: [email-masked]'
> Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt
> 
>

---

From: "Claude Kawa"<[email-masked]>
Date: Wed, 17 Apr 2002 11:44:33 -0400

Giles

 

Claude

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 11:43 AM
To: Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]'
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt

The WG charter says:

Giles

---

From: Shahram Davari <[email-masked]>
Date: Wed, 17 Apr 2002 10:14:08 -0700

Claude,
 
I think either manual configuration or signaling is required for selecting the index.
 
Yours,
-Shahram

-----Original Message-----
From: Claude Kawa [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 11:45 AM
To: 'Giles Heron'
Cc: [email-masked]'
Subject: RE: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt

Giles 

By analogy with frame relay or ATM, in the case of FR, the DLCI used between the CE and PE allows the PE to select a PE-PE LSP. Same thing with ATM, the VPCI and VCI are used to select the LSP. Now in the case of Ethernet what is the equivalent piece of information we use to select the LSP?

I have identified a number of ways. Consistency between CE and PE is important. 

In the following figure for example how PE1 selects LSP1 vs. LSP2 for ethernet frames coming from CE1 and destined to either CE2 or CE3?. What information in the ethernet frame coming from CE1 PE1 should use? 

Should not the draft provide a method to ensure we have consistent implementations between CE and PE? 

Claude 

-----Original Message----- 
From: Giles Heron [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, April 17, 2002 11:43 AM 
To: Kawa, Claude [CAR:CS49:EXCH] 
Cc: [email-masked]' 
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt 

The WG charter says: 

Giles

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 17 Apr 2002 11:14:39 -0700

I kind of agree with Eric.  However, the martini draft does not allow this
flexibility.  Otherwise there would be no need to define a VLAN-aware and a
VLAN-unaware encap.

Suppose customer A has two sites connected via an L2 ethernet PW.  At one end,
the customer comes in through an aggregation device, and has to be distinguished
by VLAN.  At the other end, the customer is assigned a physical port.  Now,
should the *signaling* have to be aware of this difference?  I would say, no.
With the martini signaling the way it is, we have to either define it as VLAN at
both ends or Ethernet at both ends, and signal the PW accordingly.  And since
the VLAN tag is necessary on the one end, it is imposed at the other end too.

The VLAN tag is only locally significant when used as a customer service
delimiter.  So I would rather see the encap behavior be: strip the (locally
significant) VLAN tag off, and send the ethernet frame without preamble or FCS,
and re-generate at the far end.  That gives the flexibility to either use a
customer specific tag or a physical port at either end without regard to what
happens at the either end.

Note that I am not talking about VLAN tags used by the customer for internal
reasons.  These should be passed through untouched.

-Vach

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
> Rosen
> Sent: Wednesday, April 17, 2002 9:26 AM
> To: Claude Kawa
> Cc: [email-masked]'
> Claude> It is  unspecified in draft-martini-ethernet-encap-mpls-00.txt) what
> Claude> piece(s)  of protocol  control information  received in  an Ethernet
> Claude> frame from a CE, a PE will use to select the right PE-PE LSP.
>
> This must definitely NOT be specified.
>
> When a  PE receives a frame  from a CE, it  clearly must use  some method to
> determine the  pseudowire on  which that frame  should be  transmitted.  The
> method  used is  a matter  of  agreement between  a service  provider and  a
> customer, and must not be specified by the protocol.
>
> The use of pseudowires to provide  various kinds of service is really within
> the province  of the L2VPN work being  done by the PPVPN  WG.  For instance,
> ethernet service pseudowires can be  used to provide either a point-to-point
> service or a transparent LAN service.  This difference is really a matter of
> just how to  determine the PW for a particular  frame.  PWE3 mechanisms must
> support both services.
>
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Claude Kawa"<[email-masked]>
Date: Wed, 17 Apr 2002 18:23:57 -0400

I am not sure I understood Vach proposal entirely. There are various VLAN id
in a PWE3 environment. We need to clarify a couple of things about VLAN and
VID first:

According to 802.1Q, VLAN id have a significance within one bridged LAN. In
the case of PWE3 architecture, where the bridged LAN terminates? 

With PWE3 architecture we can have:

customer network 1 (e.g.
LAN1)----CE1---PE1-------PSN-------PE2---CE2----customer network 2

With this architecture we can have the following LANs:

1-One bridged LAN behind CE1
2-Another bridged LAN behind CE2
3-A LAN between CE1-PE1
4-A LAN between CE2-PE2

If CE1 and CE2 are not bridges/switches (e.g. if they are routers), they
terminate the (bridged) LANs and the VLAN id used behind CE1 or CE2 do not
have to be propagated from one CE to the other.  

Therefore between a CE and PE we can use VLAN id as a local identifier. A PE
will use the VLAN id carried in the frames it received from a CE to select
the correct PE-PE LSP for shipping Ethernet/PW frames to the other PE-CE
pair. This use of VLAN id is not specified in any standard to my knowledge
and the behavior of routers with regard to VLAN ID reception and
transmission is not specified anywhere too.  

However if CE1 and CE2 are considered to be bridges/switches and the
PE1-PSN-PE2 is used for remote bridging, the VLAN id used behind the CEs
have to be propagated from one LAN to the other. What does a PE use in this
case to select the LSP? VLAN ID used in the customer networks?

It is important to understand and solve this complicated issue so that CEs
and PEs behave correctly. We cannot say this is an issue between the
customer and provider and not subject to standardization. Different vendors
may do different things. We need to provide at least minimum information
addressing this issue in ethernet/PWE3 draft.

Claude Kawa

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 2:15 PM
To: [email-masked]; Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]
Subject: RE: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt 

Suppose customer A has two sites connected via an L2 ethernet PW.  At one
end,
the customer comes in through an aggregation device, and has to be
distinguished
by VLAN.  At the other end, the customer is assigned a physical port.  Now,
should the *signaling* have to be aware of this difference?  I would say,
no.
With the martini signaling the way it is, we have to either define it as
VLAN at
both ends or Ethernet at both ends, and signal the PW accordingly.  And
since
the VLAN tag is necessary on the one end, it is imposed at the other end
too.

The VLAN tag is only locally significant when used as a customer service
delimiter.  So I would rather see the encap behavior be: strip the (locally
significant) VLAN tag off, and send the ethernet frame without preamble or
FCS,
and re-generate at the far end.  That gives the flexibility to either use a
customer specific tag or a physical port at either end without regard to
what
happens at the either end.

-Vach

---

From: "Claude Kawa"<[email-masked]>
Date: Thu, 18 Apr 2002 07:43:31 -0400

John

You are right, definitely we need to specify something about the mapping
between VLAN ID used between CE and PE and the pseudo-wire used between
PE-PE otherwise it will be a mess when we have different vendors used as CE
and PE and different vendors for the PEs. What is the value of writing
incomplete (draft) standards requiring further vendor to vendor additional
private negotiation on items a good standard should have addressed?

Claude

-----Original Message-----
From: John Fischer [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 11:29 AM
To: [email-masked]'
Cc: Kawa, Claude [CAR:CS49:EXCH]
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt

Hi Claude,
I believe that only one of two mappings are used to offer
the Ethernet port and Ethernet VLAN pseudowires described
in the martini transport draft:
- a VLAN Id maps to a pseudowire, or
- entire port maps to a pseudowire
I agree that the draft describing the ethernet
encapsulation should specify this mapping.
John

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 10:13:24 -0400

Vach> Suppose customer A has two sites  connected via an L2 ethernet PW.  At
Vach> one end, the customer comes  in through an aggregation device, and has
Vach> to  be distinguished  by  VLAN.  At  the  other end,  the customer  is
Vach> assigned  a physical  port.  Now,  should the  *signaling* have  to be
Vach> aware  of  this  difference?   I  would say,  no.   With  the  martini
Vach> signaling the way it  is, we have to either define it  as VLAN at both
Vach> ends or  Ethernet at  both ends, and  signal the PW  accordingly.  And
Vach> since the VLAN tag  is necessary on the one end, it  is imposed at the
Vach> other end too.

I think you're saying:

- the PW  should be able to carry whatever frame  the customer has produced,
  whether it has a VLAN tag or not;

- in the case  where a VLAN tag is used as  a customer service delimiter, it
  is entirely a local matter to remove the VLAN tag before sending the frame
  on the PW, and  to add it after received the frame on  the PW (so that the
  signaling should not know anything about it). 

This makes sense to me. 

I think  the implication  then is that  we only  need one ethernet  PW type,
rather than two. 

I  note that  some of  the  VPLS proposals  in PPVPN  specify additional  PW
types for use in VPLS.  I suspect we don't need those either.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 10:58:31 -0400

Giles> I think  the reason for the additional  type in VPLS was  so that the
Giles> PEs know to implement split-horizon on these VCs. 

In a  hierarchical VPLS,  the PEs do  have to  know which PWs  lead upwards,
which  lead downwards,  and which  lead  sideways.  But  his distinction  is
specific to  the VPLS service  rather than to the  pseudowire functionality.
So  I'm  not sure  the  circuit  type is  the  right  mechanism  to use  for
indicating  this  distinction.   It   might  be  better  to  signal  another
parameter, so as to preserve the  layering between PW and VPLS.  (Of course,
this is the wrong WG for that particular discussion.)

---

From: Giles Heron <[email-masked]>
Date: 18 Apr 2002 17:14:49 +0000

> this is the wrong WG for that particular discussion.) 

yes, you're probably right that we should just have a single Ethernet
"wire" type and then use another mechanism for signalling the semantics
of the wire.

And yes - we should probably be discussing all this in PPVPN :)

Giles

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 18 Apr 2002 19:18:26 +0200

Vach,
One short comment below.

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

> Sent: Thursday, April 18, 2002 6:15 PM
> To: [email-masked]
> Cc: Claude Kawa; [email-masked]
... snipped ...
>
> Actually, the -01 version of the VPLS draft has dropped the 
> second type, reducing the behavior to just one VC type along the lines of 
> what I suggested above.  The variations in learning are specified in a 
> separate bit (qualified vs. unqualified) as they are properties of the
L2VPN and not 
> the PW.  The spoke vs. hub of a pipe is more of a "this is a pt2pt pipe
vs. a simulated
> pt2multipoint PW" attribute and currently is identified by 
> the VC type.  We would use a regular draft-martini VC type 4 or 5 for the 
> spoke and a VPLS VC type for the hub side.
>
This seems somewhat problematic since draft-martini requires the same VC
type
from both ends of the connection and uses VC type as part of the uniqueness
scope 
definition for VC ID (another part is the given pair of PEs).

---

From: "Claude Kawa"<[email-masked]>
Date: Thu, 18 Apr 2002 12:51:16 -0400

Why can't we include in the draft explanations similar  to those in Eric's
email so that the readers and implementators are aware of the different
possibilities. I did not try to be exhaustive in my email. 

One important thing to include is about the VLAN ID exchanged between a CE
and PE, is it a local identifier, is it sent to the PE-CE,  is it used
behind the CE in the customer network. This information will help a lot.  

claude

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 10:27 AM
To: Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]
Subject: Re: [PWE3] issue in draft-martini-ethernet-encap-mpls-00.txt 

Claude> If CE1 and CE2 are  not bridges/switches (e.g. if they are routers),
Claude> they terminate the (bridged) LANs and the VLAN id used behind CE1 or
Claude> CE2 do not have to be propagated from one CE to the other.

Claude> Therefore  between a  CE  and  PE we  can  use VLAN  id  as a  local
Claude> identifier.

Okay so far. 

Note that as the VLAN id in this case is a local identifier, its function is
subject to agreement between the customer and the service provider. 

Claude> A PE will use  the VLAN id carried in the frames  it received from a
Claude> CE to select  the correct PE-PE LSP for  shipping Ethernet/PW frames
Claude> to the other PE-CE pair. 

Not necessarily.   If a VPLS service is  being offered, the VLAN  id will be
used to select  a particular VPN's forwarding table;  the correct pseudowire
will then be selected by looking up the frame's DA in the forwarding table. 

If Internet access  is also being provided, then a  particular VLAN id value
might be interpreted  by the PE as meaning "extract the  IP packet from this
frame and forward it according to the Internet routing table".  

If L3VPN  service is also  being provided, then  a particular VLAN  id value
might be interpreted by the PE  as meaninng "extract the IP packet form this
frame and forward it according to a particular VRF". 

Claude> We cannot say this is an issue between the customer and provider and
Claude> not subject to standardization.  

I don't see how we can say anything else. 

Claude> Different vendors may do different things. 

I don't quite understand.   For a device to be useful as  a CE device it may
need to allow itself to be configured so that different VLAN ids are used to
represent different services.  What else needs to be said?