Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt

From: Shane Amante <[email-masked]>
Date: Wed, 11 Jan 2006 21:18:57 -0700

Folks,

FYI.  Last Call on IPLS ends this Friday, 1/13.  So far, we haven't  
seen any comments, or anyone respond with either an affirmation or  
objection to forward this I-D on to the IESG.  Please speak up by  
Friday.

Thanks,

-shane & Vach

On Dec 18, 2005, at 6:08 PM, Shane Amante wrote:
> Folks,
>
> This note starts a WG Last Call for comments on: draft-ietf-l2vpn- 
> ipls-05.txt, "IP-Only LAN Service (IPLS)".  It can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-05.txt
>
> Please thoroughly review the document and send any comments to the  
> list.  Also, please indicate whether you do or do not believe this  
> document is ready to go to the IESG.
>
> Due to the holidays, the WG Last Call will end on 13 Jan 2006 at  
> 1700 MST (UTC/GMT -7).
>
> -shane
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Jan 2006 12:37:33 +0000

3. Pseudowires for Multicast Traffic:  In addition, every PE 
        supporting a given IPLS instance will set up a special 
        "broadcast pseudowire" to every other PE in that IPLS instance.

SB> Is there any intention to use PSN multicast techniques here (either
SB> now or in the future?

     4. Signaling:  The necessary pseudowires can be set up and 
        maintained using the LDP-based signaling procedures described 
        in [PWE3-CONTROL].

SB> The only control protocol that gets referenced is PWE3-Control,
SB> but the draft (quite rightly) talks about L2TP as an alternate
SB> tunnel technology. I think that we need to be able to run this
SB> over any PSN type and use the PWs defined by both PWE3 and L2TPext
SB> WGs. 

3.0 Topology 
    
   The Customer Edge (CE) devices are IP nodes (hosts or routers) that 
   are connected to PE devices either directly, or via an Ethernet 
   network. We assume that the PE/CE connection may be regarded by the 
   PE as an "interface" to which one or more CEs are attached.  This 
   interface may be a physical LAN interface or a VLAN.  The Provider 
   Edge (PE) routers are MPLS Label Edge Routers (LERs) that serve as 
   pseudowire endpoints. 

   PE1, PE2 and PE3 are shown as connected via an MPLS network; 
   however, other tunneling technologies, such as GRE, L2TPv3, etc., 
   could also be used to carry the pseudowires.  

SB> This is where you talk about about L2TPv3

6.0 Pseudowire Creation 
 
6.1 Receive Unicast Multipoint-to-point Pseudowire 
    
   As the PE discovers each locally attached CE, a unicast multipoint-
   to-point pseudowire (mp2p PW) associated exclusively with that CE is 
   created by distributing the CE's IP address and MAC address along 
   with a PW-Label to all the remote PE peers that participate in the 
   same IPLS instance. Note that the same value of a PW-label SHOULD be 
   distributed to all the remote PE peers for a given CE. The mp2p PW 
   thus created is used by remote PEs to send unicast IP traffic to a 
   specific CE.  
    
   (The same functionality can be provided by a set of point-to-point 
   PWs, and the PE is not required to send the same PW-label to all the    
   other PEs.  For convenience, however, we will use the term mp2p PWs, 
   which may be implemented using a set of point-to-point PWs.) 

SB> Do we need to start work on mp PWs over in PWE3?

11.0 IP Protocols 
    
   The solution described in this document offers IPLS service for IPv4 
   traffic only. 

SB> Why?

For this reason, the MAC Header is not carried over 
   the unicast pseudowire. It is reconstructed by the PE when receiving 
   a packet from a unicast pseudowire and the Ethertype 0x0800 is used 
   in the MAC Header since IPv4 is assumed. 
    
   However, this solution may be extended to carry other types of 
   important traffic such as ISIS and IPv6 which are not encapsulated 
   in Ethernet with the use of Ethertype 0x0800.

SB> Surely these are needed day one?

 In order to permit the 
   propagation of such packets correctly, one may create a separate set 
   of pseudowires

SB> That is a very bad idea! The IGPs assume that there is shared
SB> fate between data and routing. If yo do this you break one
SB> of the IGP design invariants.

, or pass protocol information in the "control word" 

SB> sort of PW-ACH with 0000 in the first nibble?

   of a "multiprotocol" pseudowire, or encapsulate the Ethernet MAC 
   Header in the pseudowire. The selection of appropriate 
   multiplexing/demultiplexing scheme is the subject of future study. 
   The current document focuses on IPLS service for IPv4 traffic. 

SB> What is the IETF policy on standards that only support v4?
SB> Surely we really ought to support v6 on day one?

   [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire 
   Edge to Edge Emulation (PWE3)", February 2005, work in progress. 

SB> This does not seem to be called up in the body of the draft

Stewart

---

From: Jixiong Dong <[email-masked]>
Date: Fri, 13 Jan 2006 10:11:30 +0800

Stewart,

IMO, As you indicated, it is the time to start the study work on how to transport
the multicast traffic over the PW.
In PSN network, each layer has its own multicast technology in control plane.
In IP, the multicast technology is IGMP. In ethernet, the multicast technology is 
IGMP snooping/GMRP/native. In MPLS, mpls folks are working hard on
multicast LSP. So I think PWE3 folks should consider pw's multicast technology.
And L2VPN can use the PW multicast technology.IMO, L2VPN is not very efficient
when transporting multicast traffic or broadcast/flooding traffic.

Regards,
Dong

----- Original Message ----- 
From: "Stewart Bryant" <[email-masked]>
To: "Shane Amante" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 12, 2006 8:37 PM
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt

> SB> now or in the future?
<snipped>  

> SB> Do we need to start work on mp PWs over in PWE3?
<snipped>