Subject: [PWE3] Minneapolis Minutes

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 8 Dec 2008 17:22:04 +0100

Folks,

Please see below for the draft minutes from Minneapolis. Many thanks to
Dave Sinicrope for taking notes.

Please send any comments to Dave, copying the chairs.

Regards

Matthew

Monday, November 17, 2008 09:00 - 11:30
---------------------------------------------------------------

WG Status - Stewart Bryant and Matthew Bocci
--------------------------------------------------------------------
fiber channel draft in good shape could go for last call.

Should be structured in to two components a pw encap drive to encap the
transport for fc. And a second draft for reliability.  No changes to
technology, but clearer structure.  Could allow directed maintanence. 

Yaakov Stein: This may be confusing to someone who sees it later.
Should be in one document. 

David Black: Protocol is specific to PW.  Don't want to see protocol
taken over by transport.  Indifferent over one or 2 documents.

Stewart: Authors agree to split and preference of chairs

Draft ietf pwe3 mpls transport - on hold.  Differing opinions on how to
progress the document.  Need to figure out what to do with it.

Pwe3-ms-pw arch - need this document to be reviewed and some comments
posted to the list.  Any comments are welcome.

Standards Track slide

Many RFCs out there for a while, time to bring them to draft standard.

In particular the encapsulation drafts. 

Luca Martini: Much work to do this, e.g., LDP RFC.  Nice to do this, but
if we wait a year or two it may not make a difference.  No hurry.

Matthew Bocci: some of the modes in the drafts aren't used, we should
start to clean up the documents.

Luca Martini:  Agree it would be nice to clean the document up, but even
the clean up will cause a huge amount of discussion.  E.g., RFC5036 even
things that weren't implemented e.g., host FEC, caused a great deal of
discussion.

Andy Malis: some of these drafts are straight forward and easy, e.g.,
HDLC and FR

Stewart Bryant: continue on the list and volunteer for the ones
interested in

P2MP

Stewart: please read the drafts and comment on whether they are suitable
for WG draft and state how we would progress the documents i.e., what
strategy would we use?

Matthew: a poll was taken and there were a fair number of people who
read them.

Two new drafts

Stewart: Want to have some BCP guidelines on what is reasonable for
signaling to support the NSP.

Source Initiated P2MP PW Signaling -
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01.txt - Fred Jounay
&  Leaf Initiated P2MP PW Signaling -
draft-jounay-pwe3-leaf-initiated-p2mp-pw-01.txt - Fred Jounay
------------------------------------------------------------------------
------------------------
        - Cancelled due to illness, however, see Chair's Report.

VCCV-BFD Update - draft-ietf-pwe3-vccv-bfd-02.txt - Ben Niven-Jenkins
------------------------------------------------------------------------
------------------

Ben Niven-Jenkins presented

As soon as the chairs see the update they will initiate WG last call.

OAM Msg Mapping - draft-ietf-pwe3-oam-msg-map-08.txt - Peter Busschbach
------------------------------------------------------------------------
--------------

Peter Busschbach presented

Mustapha did editing of last version

Changes from Revision 07 slide

Restructured document to group topics together and read more smoothly.

Added a section to explain two models.

Single Emulated OAM Loop model Slide

Applicable to ATM Cell Mode, TDM

Coupled LAM Loop model Slide

Applicable to Frame Relay, ATM Packet Mode

Anticipate going to WG last call before the last meeting

Matsushima San: 1. Using PW messaging is convenient to use PW messaging
for MS PW and multi domain.

2. Nothing describing how to use segment OAM vs. end-end OAM.

Peter:  Agree on 2nd point. 1st point is more controversial.  If the
local attachment circuit sees AIS it is passed transparently to the
remote user in another network.  The remote user sees AIS and calls the
local carrier who has no knowledge of the issue.  This is corrected with
using the status message.  Will discuss this further with co-authors and
discuss solution

Luca Martini: can't you just send down status message to inform middle
providers?

Peter: Yes, but it isn't in the spec right now.  Need to be clear.  3
options: send AIS, send status, do both.

Yaakov Stein:  In ITU-T terms the AIS is at level of client.  Working as
intended, if the service provider doesn't see the AIS, then he knows the
problem is not his.

You know it isn't your problem if you didn't insert the AIS.

Italo Busi:  If you generated the AIS you have the root alarm. Perhaps
we need to examine how this multi provider model is managed.

Will solve proposal above, finish TDM part and anticipate an updated
draft for WG last call.

Ethernet-MPLS OAM Interworking Update -
draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt - Nabil Bitar
------------------------------------------------------------------------
------------------

Nabil Bitar presented

Publish as WG draft after Minneapolis.  Comments are welcome especially
on mandatory subset.

Florin Balus: The way we are trying to use the Ethernet AIS is the same
way as done for ATM.  Could use AIS the way we do in the message mapping
draft. Or could address similar to Y.1731. 

Heron?:  Creating a MEP and a MIP is too much for what we want to
achieve

Ali Sajassi: For the way that it uses AIS is consistent with Y.1731.  If
the current spec doesn't cover certain areas then we need to discuss.

Nabil Bitar: The proposition is that you must have at least one MEP or
MIP.

Italo Busi: This draft would be in the coupled OAM model introduced by
the message mapping draft.  We need to consider the cases and the
architecture in the main document to see how to progress this document.

ICCP - draft-martini-pwe3-iccp-01.txt - Luca Martini
-----------------------------------------------------------------------
<Requested to be removed from agenda.>

PWE3 Bonding - draft-stein-pwe3-pwbonding-01.txt - Yaakov Stein
------------------------------------------------------------------------
-----------------------

Yaakov request that the draft be made a WG draft.

No questions from the room.  Will take to list. 

Feeling on WG draft, minimal feelings one way or another (2 or 3 people
either way).  Please read the draft and provide input on whether should
be accepted or not.

Composite Transport Group Framework -
draft-so-yong-mpls-ctg-framework-requirement-00.txt - Ning So
------------------------------------------------------------

Need to determine which WG this draft belongs to.  Is there recharting
needed to consider draft?

Yaakov Stein:  First slide Issue when using multipl parallel links.
Please explain other than better efficiency on filling pipes, what
advantage is over and above hashing

Ning So: This draft is a complement to hashing.  Hashing is a non TE
based.  TE based not available.  Efficiency is a big reason to consider
this.  Traffic BW per flow varies greatly.

Yaakov Stein: If you don't have info on TE then you can base on
measurement.  Once the traffic is mapped to a link then you can't move
it so how do you do by measurement.

Ning So: you can measure via logical link and then move traffic to a
particular link.

Yaakov Stein: when moving you will get a reordering of packets even if
slight

Ning So: You will get a slight hit

Stewart: How is time traffic going to be affected by semi-random moving
of traffic.  Some traffic would like to stay where it is so end-end
delay doesn't need to be recalculated.

Ning So: moving the traffic has more to do with how you implement this.

Stewart: No, moving the traffic for some data applications is fine but
others it is catastrophic.

Ning So: can measure and consider this and consider the type of traffic
when

Stewart: OK, but put in draft.

Ning So: if IP is addressed then move to MPLS.

George:

Mark Townsley: When in a working group try to tailor presentation to
each particular working group to help folks decide on what WG to put it
into.

Ning So: Proposal is a solution proposal not sure what group

Mark: OK tailor to each group.

Andy Malis: Presentation was for information only will need further
discussion to determine placement.

 Transport Area Review Pseudowire Congestion Control Framework -
draft-ietf-pwe3-congestion-frmwk-01.txt - David Black
------------------------------------------------------------------------
------------------------------------------------------------------------
----------------

 David Black presented

Review Summary

Transport in this slide refers to "MPLS" transport.

Yaakov Stein:  Like this approach of separating the issues.  Don't like
use of policing.  Separation of transport networks from internet
networks is a good approach.

David: Design team will come up with another term for policing that
isn't congestion control

Dave McDysan: Current draft is difficult to follow.  Will need to work
through through the terminology. Are you saying if we have PWs for
customers of anticipated performance, and there is a problem in the
network that causes problems for the TCP users on the Internet, should
the PWE address this?

David Black:  What we do when an awful failure happens and we can't
carry PWs and other Internet traffic what is carried and not is a
carrier decision.

Stewart Bryant: Transport networks is not a good name.  Need a name to
describe the transport like networks for the PWE3 networks out there
that aren't traditional transport networks covered by MPLS-TP.  We are
trying to define mechanisms to detect catastrophic failure and handle.

David: Didn't mean to say OAM had no role

George Swallow: need to find a new term for Transport

Yaakov Stein: In a transport network there are protection paths to
handle the traffic.  Not a reduction of traffic.

Stewart: we are talking about the network returning to a healthy state
as soon as possible with keeping the important traffic.

Dave McDysan:  How many government agency PWs would be premptable?
Difficult if someone is paying a premium for strict availability on SLAs
to preempt them.  Is this what you had in mind?

David Black:  this is a policy issue.

Dave McDysan: Right, is policy included?

David Black: Yes, but not what the policy is, rather the tools.  Need to
figure how to carry 20lbs of traffic on a 10lb facility

Bruce Davie: PW congestion is needed and applicable to address the 20lb
vs. 10 lb issue.

Stewart: on design team are Ben, Bruce, Luca, Stewart and Yaakov (and
David as advisor). Draft by the next IETF.

Mark: ADs are happy with approach.  May be concerned with multilevel
security and applicability to IP and TCP stack for the governments. 

Stewart:If you have interest talk to the list or members of the design
team.

Stewart and Matthew ended the meeting at 10:35am.
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: David Sinicrope <[email-masked]>
Date: Mon, 15 Dec 2008 15:38:38 -0800

The minutes have been posted to the PWE3 meeting materials.
Please let me know if you have any corrections I need to make.
Thanks!
Dave

On 12/8/08 11:22 AM, "BOCCI Matthew" <[email-masked]> wrote:

Folks,

Please see below for the draft minutes from Minneapolis. Many thanks to Dave Sinicrope for taking notes.

Regards

Matthew

Should be structured in to two components a pw encap drive to encap the transport for fc. And a second draft for reliability.  No changes to technology, but clearer structure.  Could allow directed maintanence.

Yaakov Stein: This may be confusing to someone who sees it later.  Should be in one document.

David Black: Protocol is specific to PW.  Don't want to see protocol taken over by transport.  Indifferent over one or 2 documents.

Draft ietf pwe3 mpls transport - on hold.  Differing opinions on how to progress the document.  Need to figure out what to do with it.

Pwe3-ms-pw arch - need this document to be reviewed and some comments posted to the list.  Any comments are welcome.

Standards Track slide

Luca Martini: Much work to do this, e.g., LDP RFC.  Nice to do this, but if we wait a year or two it may not make a difference.  No hurry.

Matthew Bocci: some of the modes in the drafts aren't used, we should start to clean up the documents.

Luca Martini:  Agree it would be nice to clean the document up, but even the clean up will cause a huge amount of discussion.  E.g., RFC5036 even things that weren't implemented e.g., host FEC, caused a great deal of discussion.

Andy Malis: some of these drafts are straight forward and easy, e.g., HDLC and FR

Stewart Bryant: continue on the list and volunteer for the ones interested in

P2MP

Stewart: please read the drafts and comment on whether they are suitable for WG draft and state how we would progress the documents i.e., what strategy would we use?

Matthew: a poll was taken and there were a fair number of people who read them.

Two new drafts

Stewart: Want to have some BCP guidelines on what is reasonable for signaling to support the NSP.

Source Initiated P2MP PW Signaling - draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01.txt - Fred Jounay
&  Leaf Initiated P2MP PW Signaling - draft-jounay-pwe3-leaf-initiated-p2mp-pw-01.txt - Fred Jounay
------------------------------------------------------------------------------------------------
       - Cancelled due to illness, however, see Chair's Report.

VCCV-BFD Update - draft-ietf-pwe3-vccv-bfd-02.txt - Ben Niven-Jenkins
------------------------------------------------------------------------------------------

OAM Msg Mapping - draft-ietf-pwe3-oam-msg-map-08.txt - Peter Busschbach
--------------------------------------------------------------------------------------

Matsushima San: 1. Using PW messaging is convenient to use PW messaging for MS PW and multi domain.

Peter:  Agree on 2nd point. 1st point is more controversial.  If the local attachment circuit sees AIS it is passed transparently to the remote user in another network.  The remote user sees AIS and calls the local carrier who has no knowledge of the issue.  This is corrected with using the status message.  Will discuss this further with co-authors and discuss solution

Luca Martini: can't you just send down status message to inform middle providers?

Peter: Yes, but it isn't in the spec right now.  Need to be clear.  3 options: send AIS, send status, do both.

Yaakov Stein:  In ITU-T terms the AIS is at level of client.  Working as intended, if the service provider doesn't see the AIS, then he knows the problem is not his.

Italo Busi:  If you generated the AIS you have the root alarm. Perhaps we need to examine how this multi provider model is managed.

Will solve proposal above, finish TDM part and anticipate an updated draft for WG last call.

Ethernet-MPLS OAM Interworking Update - draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt - Nabil Bitar
------------------------------------------------------------------------------------------

Nabil Bitar presented

Publish as WG draft after Minneapolis.  Comments are welcome especially on mandatory subset.

Florin Balus: The way we are trying to use the Ethernet AIS is the same way as done for ATM.  Could use AIS the way we do in the message mapping draft. Or could address similar to Y.1731.

Heron?:  Creating a MEP and a MIP is too much for what we want to achieve

Ali Sajassi: For the way that it uses AIS is consistent with Y.1731.  If the current spec doesn't cover certain areas then we need to discuss.

Nabil Bitar: The proposition is that you must have at least one MEP or MIP.

Italo Busi: This draft would be in the coupled OAM model introduced by the message mapping draft.  We need to consider the cases and the architecture in the main document to see how to progress this document.

PWE3 Bonding - draft-stein-pwe3-pwbonding-01.txt - Yaakov Stein
-----------------------------------------------------------------------------------------------

Feeling on WG draft, minimal feelings one way or another (2 or 3 people either way).  Please read the draft and provide input on whether should be accepted or not.

Composite Transport Group Framework - draft-so-yong-mpls-ctg-framework-requirement-00.txt - Ning So
------------------------------------------------------------

Need to determine which WG this draft belongs to.  Is there recharting needed to consider draft?

Yaakov Stein:  First slide Issue when using multipl parallel links.  Please explain other than better efficiency on filling pipes, what advantage is over and above hashing

Ning So: This draft is a complement to hashing.  Hashing is a non TE based.  TE based not available.  Efficiency is a big reason to consider this.  Traffic BW per flow varies greatly.

Yaakov Stein: If you don't have info on TE then you can base on measurement.  Once the traffic is mapped to a link then you can't move it so how do you do by measurement.

Ning So: you can measure via logical link and then move traffic to a particular link.

Yaakov Stein: when moving you will get a reordering of packets even if slight

Stewart: How is time traffic going to be affected by semi-random moving of traffic.  Some traffic would like to stay where it is so end-end delay doesn't need to be recalculated.

Stewart: No, moving the traffic for some data applications is fine but others it is catastrophic.

Ning So: can measure and consider this and consider the type of traffic when

George:

Mark Townsley: When in a working group try to tailor presentation to each particular working group to help folks decide on what WG to put it into.

Andy Malis: Presentation was for information only will need further discussion to determine placement.

Transport Area Review Pseudowire Congestion Control Framework - draft-ietf-pwe3-congestion-frmwk-01.txt - David Black
----------------------------------------------------------------------------------------------------------------------------------------------------------------

David Black presented

Review Summary

Yaakov Stein:  Like this approach of separating the issues.  Don't like use of policing.  Separation of transport networks from internet networks is a good approach.

David: Design team will come up with another term for policing that isn't congestion control

Dave McDysan: Current draft is difficult to follow.  Will need to work through through the terminology. Are you saying if we have PWs for customers of anticipated performance, and there is a problem in the network that causes problems for the TCP users on the Internet, should the PWE address this?

David Black:  What we do when an awful failure happens and we can't carry PWs and other Internet traffic what is carried and not is a carrier decision.

Stewart Bryant: Transport networks is not a good name.  Need a name to describe the transport like networks for the PWE3 networks out there that aren't traditional transport networks covered by MPLS-TP.  We are trying to define mechanisms to detect catastrophic failure and handle.

Yaakov Stein: In a transport network there are protection paths to handle the traffic.  Not a reduction of traffic.

Stewart: we are talking about the network returning to a healthy state as soon as possible with keeping the important traffic.

Dave McDysan:  How many government agency PWs would be premptable? Difficult if someone is paying a premium for strict availability on SLAs to preempt them.  Is this what you had in mind?

David Black: Yes, but not what the policy is, rather the tools.  Need to figure how to carry 20lbs of traffic on a 10lb facility

Bruce Davie: PW congestion is needed and applicable to address the 20lb vs. 10 lb issue.

Stewart: on design team are Ben, Bruce, Luca, Stewart and Yaakov (and David as advisor). Draft by the next IETF.

Mark: ADs are happy with approach.  May be concerned with multilevel security and applicability to IP and TCP stack for the governments.

Stewart:If you have interest talk to the list or members of the design team.