Sasha Vainshtein | 1 Feb 09:24 2006

RE: 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)
  • 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:andymalis <at> comcast.net]
    Sent: Tuesday, January 31, 2006 7:25 PM
    To: Sasha Vainshtein
    Cc: 'Stewart Bryant'; Danny McPherson (E-mail); benjamin.niven-jenkins <at> bt.com; pwe3 <at> ietf.org
    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:stbryant <at> cisco.com]
    Sent: Tuesday, January 31, 2006 4:54 PM
    To: benjamin.niven-jenkins <at> bt.com
    Cc: pwe3 <at> ietf.org
    Subject: Re: [PWE3] Generic PW - Is there a need?

    benjamin.niven-jenkins <at> bt.com 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
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    Shah, Himanshu | 1 Feb 16:09 2006

    RE: Generic PW - Is there a need?

    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: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org]On Behalf Of Sasha Vainshtein
    Sent: Wednesday, February 01, 2006 3:24 AM
    To: 'Andrew G. Malis'
    Cc: benjamin.niven-jenkins <at> bt.com; Danny McPherson (E-mail); pwe3 <at> ietf.org; '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)
  • 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:andymalis <at> comcast.net]
    Sent: Tuesday, January 31, 2006 7:25 PM
    To: Sasha Vainshtein
    Cc: 'Stewart Bryant'; Danny McPherson (E-mail); benjamin.niven-jenkins <at> bt.com; pwe3 <at> ietf.org
    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:stbryant <at> cisco.com]
    Sent: Tuesday, January 31, 2006 4:54 PM
    To: benjamin.niven-jenkins <at> bt.com
    Cc: pwe3 <at> ietf.org
    Subject: Re: [PWE3] Generic PW - Is there a need?

    benjamin.niven-jenkins <at> bt.com 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
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    Thomas D. Nadeau | 1 Feb 16:24 2006
    Picon

    Re: Generic PW - Is there a need?


    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


    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: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org]On Behalf Of Sasha Vainshtein
    Sent: Wednesday, February 01, 2006 3:24 AM
    To: 'Andrew G. Malis'
    Cc: benjamin.niven-jenkins <at> bt.com; Danny McPherson (E-mail); pwe3 <at> ietf.org; '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:andymalis <at> comcast.net]
    Sent: Tuesday, January 31, 2006 7:25 PM
    To: Sasha Vainshtein
    Cc: 'Stewart Bryant'; Danny McPherson (E-mail); benjamin.niven-jenkins <at> bt.com; pwe3 <at> ietf.org
    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:stbryant <at> cisco.com]
    Sent: Tuesday, January 31, 2006 4:54 PM
    To: benjamin.niven-jenkins <at> bt.com
    Cc: pwe3 <at> ietf.org
    Subject: Re: [PWE3] Generic PW - Is there a need?

    benjamin.niven-jenkins <at> bt.com 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

    _______________________________________________
    pwe3 mailing list
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    The IESG | 1 Feb 20:31 2006
    Picon

    Last Call: 'PWE3 Fragmentation and Reassembly' to Proposed Standard

    The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG 
    to consider the following document:
    
    - 'PWE3 Fragmentation and Reassembly '
       <draft-ietf-pwe3-fragmentation-10.txt> as a Proposed Standard
    
    The IESG plans to make a decision in the next few weeks, and solicits
    final comments on this action.  Please send any comments to the
    iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-02-15.
    
    The file can be obtained via
    http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-10.txt
    
    Internet-Drafts | 2 Feb 00:50 2006
    Picon

    I-D ACTION:draft-ietf-pwe3-enet-mib-07.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.
    
    	Title		: Ethernet Pseudo Wire (PW) Management Information Base
    	Author(s)	: D. Zelig, T. Nadeau
    	Filename	: draft-ietf-pwe3-enet-mib-07.txt
    	Pages		: 25
    	Date		: 2006-2-1
    	
    This memo defines an experimental portion of the Management 
      Information Base (MIB) for use with network management protocols in 
      the Internet community.  In particular, it describes managed objects 
      for modeling of Ethernet Pseudo Wire (PW) services.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-07.txt
    
    To remove yourself from the I-D Announcement list, send a message to 
    i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
    You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
    to change your subscription settings.
    
    Internet-Drafts are also available by anonymous FTP. Login with the username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
    	"get draft-ietf-pwe3-enet-mib-07.txt".
    
    A list of Internet-Drafts directories can be found in
    http://www.ietf.org/shadow.html 
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    
    Internet-Drafts can also be obtained by e-mail.
    
    Send a message to:
    	mailserv <at> ietf.org.
    In the body type:
    	"FILE /internet-drafts/draft-ietf-pwe3-enet-mib-07.txt".
    	
    NOTE:	The mail server at ietf.org can return the document in
    	MIME-encoded form by using the "mpack" utility.  To use this
    	feature, insert the command "ENCODING mime" before the "FILE"
    	command.  To decode the response(s), you will need "munpack" or
    	a MIME-compliant mail reader.  Different MIME-compliant mail readers
    	exhibit different behavior, especially when dealing with
    	"multipart" MIME messages (i.e. documents which have been split
    	up into multiple messages), so check your local documentation on
    	how to manipulate these messages.
    		
    		
    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.
    
    Attachment: message/external-body, 136 bytes
    Attachment (draft-ietf-pwe3-enet-mib-07.txt): message/external-body, 68 bytes
    _______________________________________________
    I-D-Announce mailing list
    I-D-Announce <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/i-d-announce
    
    Internet-Drafts | 2 Feb 00:50 2006
    Picon

    I-D ACTION:draft-ietf-pwe3-pw-mpls-mib-08.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.
    
    	Title		: Pseudo Wire (PW) over MPLS PSN Management Information Base
    	Author(s)	: D. Zelig, T. Nadeau
    	Filename	: draft-ietf-pwe3-pw-mpls-mib-08.txt
    	Pages		: 28
    	Date		: 2006-2-1
    	
    This memo defines an experimental portion of the Management 
      Information Base (MIB) for use with network management protocols in 
      the Internet community.  In particular, it describes a MIB module 
      for PW operation over Multi-Protocol Label Switching (MPLS) Label 
      Switch Router (LSR).
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-08.txt
    
    To remove yourself from the I-D Announcement list, send a message to 
    i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
    You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
    to change your subscription settings.
    
    Internet-Drafts are also available by anonymous FTP. Login with the username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
    	"get draft-ietf-pwe3-pw-mpls-mib-08.txt".
    
    A list of Internet-Drafts directories can be found in
    http://www.ietf.org/shadow.html 
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    
    Internet-Drafts can also be obtained by e-mail.
    
    Send a message to:
    	mailserv <at> ietf.org.
    In the body type:
    	"FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-08.txt".
    	
    NOTE:	The mail server at ietf.org can return the document in
    	MIME-encoded form by using the "mpack" utility.  To use this
    	feature, insert the command "ENCODING mime" before the "FILE"
    	command.  To decode the response(s), you will need "munpack" or
    	a MIME-compliant mail reader.  Different MIME-compliant mail readers
    	exhibit different behavior, especially when dealing with
    	"multipart" MIME messages (i.e. documents which have been split
    	up into multiple messages), so check your local documentation on
    	how to manipulate these messages.
    		
    		
    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.
    
    Attachment: message/external-body, 139 bytes
    Attachment (draft-ietf-pwe3-pw-mpls-mib-08.txt): message/external-body, 68 bytes
    _______________________________________________
    pwe3 mailing list
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    Internet-Drafts | 2 Feb 00:50 2006
    Picon

    I-D ACTION:draft-ietf-pwe3-pw-mib-07.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.
    
    	Title		: Pseudo Wire (PW) Management Information Base
    	Author(s)	: D. Zelig, T. Nadeau
    	Filename	: draft-ietf-pwe3-pw-mib-07.txt
    	Pages		: 56
    	Date		: 2006-2-1
    	
    This memo defines an experimental portion of the Management 
        Information Base for use with network management protocols in the 
        Internet community.  In particular, it describes managed objects 
        for modeling of Pseudo Wire Edge-to-Edge services carried over a 
        general Packet Switched Network.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-07.txt
    
    To remove yourself from the I-D Announcement list, send a message to 
    i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
    You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
    to change your subscription settings.
    
    Internet-Drafts are also available by anonymous FTP. Login with the username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
    	"get draft-ietf-pwe3-pw-mib-07.txt".
    
    A list of Internet-Drafts directories can be found in
    http://www.ietf.org/shadow.html 
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    
    Internet-Drafts can also be obtained by e-mail.
    
    Send a message to:
    	mailserv <at> ietf.org.
    In the body type:
    	"FILE /internet-drafts/draft-ietf-pwe3-pw-mib-07.txt".
    	
    NOTE:	The mail server at ietf.org can return the document in
    	MIME-encoded form by using the "mpack" utility.  To use this
    	feature, insert the command "ENCODING mime" before the "FILE"
    	command.  To decode the response(s), you will need "munpack" or
    	a MIME-compliant mail reader.  Different MIME-compliant mail readers
    	exhibit different behavior, especially when dealing with
    	"multipart" MIME messages (i.e. documents which have been split
    	up into multiple messages), so check your local documentation on
    	how to manipulate these messages.
    		
    		
    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.
    
    Attachment: message/external-body, 134 bytes
    Attachment (draft-ietf-pwe3-pw-mib-07.txt): message/external-body, 68 bytes
    _______________________________________________
    I-D-Announce mailing list
    I-D-Announce <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/i-d-announce
    
    Internet-Drafts | 2 Feb 00:50 2006
    Picon

    I-D ACTION:draft-ietf-pwe3-pw-tc-mib-07.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.
    
    	Title		: Definitions for Textual Conventions and 
                              OBJECT-IDENTITIES for Pseudo-Wires Management
    	Author(s)	: T. Nadeau, D. Zelig
    	Filename	: draft-ietf-pwe3-pw-tc-mib-07.txt
    	Pages		: 10
    	Date		: 2006-2-1
    	
    This memo defines a Management Information Base (MIB) module  
      Which contains Textual Conventions to represent commonly used 
      Pseudo Wire (PW) management information.  The intent is that these 
      TEXTUAL CONVENTIONS (TCs) will be imported and used in PW related 
      MIB modules that would otherwise define their own representations.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-07.txt
    
    To remove yourself from the I-D Announcement list, send a message to 
    i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
    You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
    to change your subscription settings.
    
    Internet-Drafts are also available by anonymous FTP. Login with the username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
    	"get draft-ietf-pwe3-pw-tc-mib-07.txt".
    
    A list of Internet-Drafts directories can be found in
    http://www.ietf.org/shadow.html 
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    
    Internet-Drafts can also be obtained by e-mail.
    
    Send a message to:
    	mailserv <at> ietf.org.
    In the body type:
    	"FILE /internet-drafts/draft-ietf-pwe3-pw-tc-mib-07.txt".
    	
    NOTE:	The mail server at ietf.org can return the document in
    	MIME-encoded form by using the "mpack" utility.  To use this
    	feature, insert the command "ENCODING mime" before the "FILE"
    	command.  To decode the response(s), you will need "munpack" or
    	a MIME-compliant mail reader.  Different MIME-compliant mail readers
    	exhibit different behavior, especially when dealing with
    	"multipart" MIME messages (i.e. documents which have been split
    	up into multiple messages), so check your local documentation on
    	how to manipulate these messages.
    		
    		
    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.
    
    Attachment: message/external-body, 137 bytes
    Attachment (draft-ietf-pwe3-pw-tc-mib-07.txt): message/external-body, 68 bytes
    _______________________________________________
    pwe3 mailing list
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    Sasha Vainshtein | 2 Feb 10:48 2006

    RE: Generic PW - Is there a need?

    Himanshu and all,
    I see a certain problem with your proposal to limit the work in PWE3 to
     
    <quote>
    defining the PW encapsulation and setup of the PW
    <end quote>
     
    The problem is that, until now, the PWE3 specs commonly included not just the encapsulation format but also some description of the encap/decap (a.k.a. PW adaptation) procedures, e.g., see Section 4 "Generic Procedures" of draft-ietf-pwe3-ethernet-encap-11.txt, Section 7.5 "PW Packet Processing" in draft-ietf-pwe3-frame-relay-06.txt etc.
     
    Can we define any such procedures for a "generic packet PW"? I doubt that this can be done because:
    1. Discrimination of the types of packets coming from the local CE is AC-specific
    2. Specific examples of "generic packet PWs" would presumably pass only some of the  packets received from the local CE (based on their type)  while peering with the local CE for some other ones (this is what an IP PW with ARP mediation does, right?) And, when it comes to setup, the types of packets that are passed probably has to be coordinated between the two endpoints...
    I am also not sure if the "generic packet PW" would be the right thing for pre-wiring PW segments between S-PEs for MS-PWs because IMHO S-PEs should not add their own PW headers while "generic packet PWs presumably require some header to carry specific packet types.
     
    Regards,
                        Sasha
     
     
    -----Original Message-----
    From: Shah, Himanshu [mailto:hshah <at> ciena.com]
    Sent: Wednesday, February 01, 2006 5:09 PM
    To: Sasha Vainshtein; Andrew G. Malis
    Cc: benjamin.niven-jenkins <at> bt.com; Danny McPherson (E-mail); pwe3 <at> ietf.org; Stewart Bryant
    Subject: RE: [PWE3] Generic PW - Is there a need?

    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: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org]On Behalf Of Sasha Vainshtein
    Sent: Wednesday, February 01, 2006 3:24 AM
    To: 'Andrew G. Malis'
    Cc: benjamin.niven-jenkins <at> bt.com; Danny McPherson (E-mail); pwe3 <at> ietf.org; '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)
  • 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:andymalis <at> comcast.net]
    Sent: Tuesday, January 31, 2006 7:25 PM
    To: Sasha Vainshtein
    Cc: 'Stewart Bryant'; Danny McPherson (E-mail); benjamin.niven-jenkins <at> bt.com; pwe3 <at> ietf.org
    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:stbryant <at> cisco.com]
    Sent: Tuesday, January 31, 2006 4:54 PM
    To: benjamin.niven-jenkins <at> bt.com
    Cc: pwe3 <at> ietf.org
    Subject: Re: [PWE3] Generic PW - Is there a need?

    benjamin.niven-jenkins <at> bt.com 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
    pwe3 <at> ietf.org
    https://www1.ietf.org/mailman/listinfo/pwe3
    
    Shimshon.Lapushner | 2 Feb 13:51 2006

    Shimshon Lapushner/ECI Telecom is out of the office.

    I will be out of the office starting  02/02/2006 and will not return until
    05/02/2006.
    
    I could be reached by Mobile: +972 54 578-8113
    

    Gmane