Subject: RE: [PWE3] Generic PW - Is there a need?

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 1 Feb 2006 10:09:00 -0500

Hi Sasha,
I believe the work in PWE3 would be limited to defining the PW encapsulation and
setup of the PW. The interworking/arp-mediation or translation type of work is being
pursued in L2VPN WG. The current L2VPN drafts (IPLS, ARP-MEDIATION) uses
IP L2 Transport PW (i.e. IP PW). This constrains those drafts to support IS-IS (granted
that proper MAC learning mechanisms would have to be defined along with isis over pt-pt).
 
The generic PW mechanisms paves way for other possible functionalities such as,
1) pre-wiring PWs (especially between S-PEs for MS-PWs)
2) muxing diff types of PWs into a PW (as long as there is something else in the packet to demux)
3) backhauling PWs over infrastructure (i.e. generic) PW (using PW in PW)
etc etc
 
/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha Vainshtein
Sent: Wednesday, February 01, 2006 3:24 AM
To: 'Andrew G. Malis'
Cc: [email-masked]; Danny McPherson (E-mail); [email-masked]; 'Stewart Bryant'
Subject: RE: [PWE3] Generic PW - Is there a need?

Andy (and all)
Lots of thanks for a prompt response.
 
I agree with you that adapting the 2684 approach would be quite straightforward.
 
I would also like to note that, IMHO, such a generic packet PW would not, per se, solve the problem of carrying meaningful "IP pseudo-wires" between disparate Layer 2 attachment circuits (assuming that this is one of the objectives pursued). The following points needs special attention

1.	ARP: mediation vs. translation 

*	The latter could operate in the data plane but seems to be restricted to the case when the two ACs represent interfaces of the same type (P2P, NMBA or LAN) 

*	FRF8  can be adapted where where applicable 

*	IPCP translation for PPP-based AC requires special consideration

*	The former can operate between interfaces of different types but seems to involve dependency on the control plane (see draft-ietf-l2vpn-arp-mediation-04)

2.	IGP operation: forcing LAN interface to P2P operation should be considered (e.g., as in draft-ietf-isis-igp-p2p-over-lan-05.txt)

Hopefully these notes will be useful.
 
Regards,
                    Sasha

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, January 31, 2006 7:25 PM
To: Sasha Vainshtein
Cc: 'Stewart Bryant'; Danny McPherson (E-mail); [email-masked]; [email-masked]
Subject: RE: [PWE3] Generic PW - Is there a need?

Sasha,

Yes, I was about to send out an email with the same conclusion.  It should be relatively straightforward to adapt one of these two (probably 2684, given its header word alignment vs. header byte alignment in 2427) for this purpose.  I've always been of the opinion that we should have included a PID in the MPLS header way back when, but that was the minority opinion at the time.

Cheers,
Andy

-------------

At 1/31/2006 06:24 PM +0200, Sasha Vainshtein wrote:

Stewart, Danny and all,
Are we possibly speaking about something like "multiprotocol interconnect over PW" similar to multiprotocol interconnect over FR (RFC 2427/STD 55) or multiprotocol interconnect over AAL5 (RFC 2684)? 
 
Regards,
                    Sasha

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

From: Stewart Bryant [  <mailto:[email-masked]> mailto:[email-masked]]

Sent: Tuesday, January 31, 2006 4:54 PM

To: [email-masked]

Cc: [email-masked]

Subject: Re: [PWE3] Generic PW - Is there a need?

[email-masked] wrote:

Danny,

It is not entirely clear to me what the proposal you are making is

or

the motivation behind it.

Are you stating that to support IPLS, transport of MPLS PWs over a

PW

etc. that a new control word format/encapsulation is required and

this

document will specify such a control word format?  If so, what

is

deficient/missing in the current control word formats?

You need a standard method to multiplex a number of protocols over the 

PW. It's not always the case that the only protocol that needs to be

carried is IP. You might want to carry IP + ISIS, or IP + MPLS etc.

We could do this by defining a canonical data-link type, or by

adding a PID to the PW. How we do it is a WG decision.

Or is it to just essentially combine several PW types into a

single

document rather than a document per PW type?

No, we think that there is a need to carry multiple types over the same PW.

- Stewart

Or am I completely missing the point?

Thanks

Ben

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Feb 2006 10:24:11 -0500

That raises an important question. Are we going to handle
the interworking of OAM between this new generic
PW type and existing types in the PWE3 WG, and if so,
how? At present, the delimitation has been that PWE3
only handles the like-to-like case, while the L2VPN WG
(and the MFA) have taken on the definition of the any2any
case.  I think we need some guidance from the chairs/AD
on this issue if we are to proceed forward with having
OAM functions defined correctly for this new PW type.

	--Tom

> I would also like to note that, IMHO, such a generic packet PW  
> would not, per se, solve the problem of carrying meaningful "IP  
> pseudo-wires" between disparate Layer 2 attachment circuits  
> (assuming that this is one of the objectives pursued). The  
> following points needs special attention
> ARP: mediation vs. translation
> The latter could operate in the data plane but seems to be  
> restricted to the case when the two ACs represent interfaces of the  
> same type (P2P, NMBA or LAN)
> FRF8  can be adapted where where applicable
> IPCP translation for PPP-based AC requires special consideration
> The former can operate between interfaces of different types but  
> seems to involve dependency on the control plane (see draft-ietf- 
> l2vpn-arp-mediation-04)
> IGP operation: forcing LAN interface to P2P operation should be  
> considered (e.g., as in draft-ietf-isis-igp-p2p-over-lan-05.txt)
> Yes, I was about to send out an email with the same conclusion.  It  
> should be relatively straightforward to adapt one of these two  
> (probably 2684, given its header word alignment vs. header byte  
> alignment in 2427) for this purpose.  I've always been of the  
> opinion that we should have included a PID in the MPLS header way  
> back when, but that was the minority opinion at the time.
>
> Cheers,
> Andy
>
> -------------
>
>> Are we possibly speaking about something like "multiprotocol  
>> interconnect over PW" similar to multiprotocol interconnect over  
>> FR (RFC 2427/STD 55) or multiprotocol interconnect over AAL5 (RFC  
>> 2684)?
>>
>> Regards,
>>                     Sasha
>>
>>
>>
>>
>> From: Stewart Bryant [ mailto:[email-masked]]