Subject: RE: [PWE3] PWE over Alternative networks

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 21 Mar 2007 22:31:46 +0200

Yaakov (and all),
Thank you for the clarification of your intention. 

Can you please explain what you mean when you say that the two cases
you've mentioned are "completely
understood from the addressing point of view"?

To the best of my recollection, the Y.1731 "addressing scheme" includes:
- A Source MAC address that must be used in the Ethernet header of the
OAM messages. The recommendation does not
  explain how it is allocated or used 
- A globally unique Maintenance Entity Group (MEG) ID. While this can
use many formats, the only one really defined 
  in Y.1731 uses the so-called ITU Carrier Code (ICC) (up to 6 ASCII
characters) and a Unique (within this carrier)
  Maintenance Entity Code (UMC) (also up to 6 ASCII characters)
- A Maintenance Entity End Point (MEP) - a 13-bit number that is unique
within the given MEG.

Now let's suppose that I am running an Ethernet PW over MPLS (as per RFC
4448) that is terminated on a pair of 
Virtual Switching Instances (VSI) in the appropriate PEs (i.e. it is
part of a VPLS instance).
Let's also assume that this VPLS has been set up using LDP as per RFC
4762? To me this RFC defines an addressing scheme for the Ethernet PW
end points is an ordered triple comprised of:
- The VPLS ID. It can be represented by the AGI (if generalized PWid FEC
as been used) or VCID (as described in 
  Annex A of the said RFC) and is unique within the given administrative
domain.  
- IP address of the PE containing the endpoint and used in the Targeted
LDP session between this PE and the PE
  containing its remote end point
- IP address of the PE containing the remote end point of the Ethernet
PW in question. Again, IP address used in the
  Targeted LDP session between the two PEs must be used

At the same time, the VSI in each PE does not have any specific MAC
address to speak of. Among the other things,
the VSI does not possess a System ID MAC (because it is not a real
bridge).

Can you please explain how to map the PWE3 /VPLS addressing scheme to
that used in Y.1731?

IMHO if such a mapping is not defined and well understood, the results
produced by running Ethernet OAM over VCCV over such a PW cannot be
reasonably used in the VPLS context. 

Did i miss something?

Regards,
                   Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 8:02 PM
To: Sasha Vainshtein; [email-masked]
Cc: [email-masked]; David Allan
Subject: RE: [PWE3] PWE over Alternative networks

Sasha

I want to claim  arbitrary over arbitrary although I am not sure my
co-authors will go along with this.

Certainly  Ethernet over arbitrary   and 
              arbitrary over Ethernet
are completely understood from the addressing point of view, and can
thus be implemented immediately.

Y(J)S

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 18:11
To: Yaakov Stein; [email-masked]
Cc: [email-masked]; David Allan
Subject: RE: [PWE3] PWE over Alternative networks

Yaakov, Dinesh and all,
One of the issues I have with draft-mohan-pwe3-vccv-eth-00/01.txt is
that it is really difficult to understand what is its intended scope:
- PWs over an Ethernet PSN?
- Ethernet PWs over MPLS and/or IP PSN?
- Arbitrary PW over an arbitrary PSN?

Regards,
            Sasha

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 5:22 PM
To: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] PWE over Alternative networks

Hi Yaakov:

<snipped>
 
> although this discussion was motivated by
draft-mohan-pwe3-vccv-eth-00.txt,
> this draft is not limited to Ethernet PSNs.  I would not want this
draft to be held up
> until Ethernet PSNs are admitted.

Agreed, both to applicability and desired outcome...

Dave

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 22 Mar 2007 14:25:10 +0200

Luca, Yaakov and all,
This is not what the spec says (see Section 6.2.1). It is publicly
available via the link I've sent to you.

Regards,
                Sasha

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 1:05 PM
To: Sasha Vainshtein
Cc: [email-masked]; David Allan; Yaakov Stein
Subject: Re: [PWE3] PWE over Alternative networks

Sasha Vainshtein wrote:
> Luca and all,
> A minor comment:
>  
> While the MEF CESoETH looks very much like an MPLS PW, it uses  an 
> EtherType value that differs from Unicast MPLS.
According to Yaakov it can also use the MPLS ethertype.
( I do not have the document here so i cannot look ) Luca

>  Hence I am not sure if
> the Emulated Circuit ID (ECID) used in this spec can be really treated

> as a label stack comprised of a single entry and containing the PW 
> label in spite of the fact that the ECID itself has been designed to 
> be fully compatible with RFC 3032.
>  
> The CESoETH spec (MEF.8)  can be found at:
> http://www.metroethernetforum.org/PDFs/Standards/MEF8.doc
>  
> Regards,
>              Sasha
>  
>  
>
> ________________________________
>
> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 9:37 AM
> To: David Allan
> Cc: [email-masked]
> Subject: Re: [PWE3] PWE over Alternative networks
>
>
> Dave,
>
> The fact that we might use PHP when the MPLS PEs are adjacent does NOT

> mean that there is no PSN  or that the PSN is Null.
> Nowhere in the architecture do we specify a Null PSN. 
>
> How ever I am unclear of what you are requesting. Here is a quote form
> rfc4447:
>
> " To transmit the packet   from one pseudowire endpoint to another,
the
> packet may need to
>    travel through a "Packet Switched Network (PSN) tunnel"; this will
>    require that an additional header be prepended to the packet."
>
> Also note that the do not always need a tunnel label as stated in
> rfc4447:
>
> "However, if the pseudowire endpoints are immediately adjacent and 
> penultimate hop popping behavior is in use, the MPLS tunnel may not be

> necessary.  Any sort of PSN tunnel can be used, as long as it is 
> possible to transmit MPLS packets through it.  "
>
> So it is perfectly fine to have 2 adjacent nodes and use no MPLS 
> tunnel label. In which case the label stack will consist of only one
label.
> By coincidence this is what the MEF has already used for MEF8
> (CEoEthernet) .
>
> So the fact that we might not have a tunnel label under certain 
> circumstances does not mean that there is no PSN.
>
> Luca
>
>
>
> David Allan wrote: 
>
> 	Hi: <<Microsoft PowerPoint - PWE3 and Alternative PSNs.ppt.pdf>>
>
> 	
> 	Did not get to this on the agenda today and we agreed to go to
the
> 	list....
> 	
> 	I had put together some charts to advocate for a charter update
on 
> the
> 	subject, which I've attached.
> 	
> 	For the time impaired, the assertion is that there is no
difference
> 	between a PWE MPLS label and a PSN MPLS label, therefore a PWE
label 
> can
> 	run "naked" anywhere an MPLS label can run similarly inheriting
the
> 	transfer properties of the underlying network, and the charter
should
> 	simply acknowledge the case where the MPLS PSN is NULL....
> 	
> 	Comments?
> 	Dave
> 	
> 	  
> 	
> ________________________________
>
>