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

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 17 Jan 2006 15:52:01 -0500

Hi Stewart,

Thanks for the review and comments.
Response in line.

/himanshu

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Stewart Bryant
> Sent: Thursday, January 12, 2006 7:38 AM
> To: Shane Amante
> Cc: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt
> 
> 
>         
>      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?

HCS> 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. 
>                             
> 

HCS> You seem to be recommending adding appropriate text and reference
HCS> to L2TP based PW. Will do. 

>     
> 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?
>                                                            
>

HCS> Yes.
    
>     
> 11.0 IP Protocols 
>     
>    The solution described in this document offers IPLS 
> service for IPv4 
>    traffic only. 
> 
> SB> Why?

HCS> We discussed this in one of the WG meetings.
HCS> It was agreed that IPv6 support can be added as follow on.

> 
> 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?

HCS> See above. As for IS-IS which uses 802.3 encap, there needs to be
HCS> some mechanism such that egress PE can correctly encapsulate the
HCS> Ethernet header.

> 
>  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.

HCS> Agreed. It is only presented as one option albeit not a desirable
HCS> one.

> 
> , or pass protocol information in the "control word" 
> 
> SB> sort of PW-ACH with 0000 in the first nibble?

HCS> Yes. This would be a desirable option. 

> 
>    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?

HCS> See above.

> 
>    [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

HCS> Thanks for catching this. Will add it at the appropriate place
HCS> in the draft.

> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 18 Jan 2006 10:23:41 +0000

Himanshu

I think that it would also be a good idea if you asked for a
review by the RTGWG or the routing area directorate.

I am concerned about breaking shared fate assumptions particularly
with regard to the sending of  multicast packets down one PW, and
various types of unicast packets down other PWs. Now we can unify the
the unicast packets and emulated muticast packets over a single
PW using a CW and maybe that is what we have to do. However
I am having concerns as to the consequence of moving on to the
use of a MP PW - which would increase bandwidth efficiency
but might have serious consequences for the client layer
routing algorithm.

- Stewart