[PWE3] Vancouver minutes

["BOCCI Matthew" <[e-mail]>]

All,

Please find attached the draft minutes from Vancouver. Please let me
know if you have any comments or corrections by 3rd Jan.

Many thanks to Yaakov for the extra notes.

Regards,

Matthew



MONDAY, December 3rd, 2007 - 15:20 - 17:20
-----------------------------------
CHAIRS: Danny McPherson & Stewart Bryant
SCRIBES: Matthew Bocci and Yaakov Stein
JABBER: Yaakov Stein


15 mins WG Status and Update - Chairs

17 RFCs published. AII aggregate is new : RFC 5003
3 in RFC eds queue
MS-PW requirements: new draft has been uploaded
Summarises work in progress

OAM message map: needs updating.

Monique Morrow: waiting for VCCV. Next in queue
TDM control extensions is ready for proto

MIBs: a couple have aexpired. Will progess these and have had some
feedback. Looking good.

PW protection and restoration needs to be adopted.

Possible New items: 
MPLS PW
Multipoint PWs
T-MPLS ad hoc committee outputs
Others? E.g. OSPF extensions. Need to decide if this should be done in
OSPF or PWE3, if we decide to adopt it.



VCCV-BFD - Tom Nadeau ([e-mail])
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00
-----------------------------------------------------------------

Giles Heron standing in for Tom.

VCCV draft was split to simplify the base spec.

As few areas where we need refinement:
-	4 different BFD CV types defined
-	how does a PE select among BFD modes?
-	text says should use LDP status if using the control plane.
-	How to decide if you want UDP/IP headers or not.

Where to go from here: already a WG draft because it was split off out
of a WG draft. Currently held up by base BFD drafts.
Need WG input ASAP.

Danny: Tom wants to wrap up within a couple of months.


PW Redundancy - Marc Lasserre ([e-mail])
http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redundancy-bit-02.t
xt
http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundancy-02.txt
------------------------------------------------------------------------
---


Matthew Bocci standing in for Marc Lasserre standing in for Mustapha. 

Shows a slide explaining "request switchover".
T-PE1 communicating with T-PE2 with 3 S-PEs in between
Draft muley up to version 02
Authors requesting to move to WG status

Dave McDyson: Proposes requirements be settled first. Also requests
cross-referencing other drafts, and explaining terminology.
Stewart: asks what alignment is required
Dave McDyson: IEEE protection, and possibly ITU
Matthew: That is part of requirements draft
Dave McDyson: The solution seems to rely on correct configuration.
Automatic identification of master and slave would be nice. 
Danny: Are you volunteering to help ?
Dave McDyson: yes
Dave says he is happy that Luca is now working on this draft as well
Luca Martini (via Jabber): Hey ! , this is a very different document
since the time I made that statement !

Danny: will ask on the list.


Pseudowire Emulation MPLS PSN Congestion Status Bit - Matthew Bocci
([e-mail])
http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn-congestion-bi
t-00.txt
------------------------------------------------------------------------
------- 

Matthew: PWE3 needs to provide congestion handling mechanism
Talks about congestion of underlying PSN, PW needs to be TCP friendly
This new draft talks about how egress PE signals ingress PE on
congestion detection.
Control plane mechanism : reliable, scalable, avoids using scarce bits
in PW header. Egress PE2 detects congestion 
by packet loss/VCCV/ECN
It sends congestion status back to PE1, which applies control
Second case - MS-PW
T-PE2 sends message to S-PE which forwards to T-PE1. 
S-PE can also apply congestion control locally, or originate the status
message.
When congestion ceases - egress PE sends PW status with status bit
cleared
Need to avoid flapping (when resume it causes congestion again). Need to
work details out.
Matthew asks for feedback to the list, and to move to WG draft
Stewart: need feedback from TSV area since they are the ones that want
it.
Mark Townsley: Have you asked them?
Stewart - not yet, will now
Mark Townsley: In MS-PW case, can we get a broadcast storm?
Matthew: Limited to one per T-PE.
Stewart: Only at the start
Mark Townsley: Let the transport people work on this
Himanshu Shah: better to have transport parameter
Matthew: It might be that only the ingress PE knows if the traffic is
elastic
Luca Martini (via Jabber): The mitigation function is PW technology
specific
Rob ?: do you indicate to source to increase policing?
Matthew: yes
Luca Martini (via Jabber) it varies from shutting down a pw ( TDM ) to
applying a policer

Danny: need feedback, make sure aligned with TSV (Allison)


Load Balancing Fat MPLS Pseudowires - Joerg Kuechemann
([e-mail])
http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00
------------------------------------------------------------------------
----

Ulrich presents.:

Transport label is chosen by a hash algorithm, but the PW always takes
the same route. This leads to imbalance
Options:
- DPI would need lots of computing power in P and PEs
Next try was PW label range ("label block"), whereby several PW labels
mapped to AC
Shows diagram with 2 PWs (could be more, e.g. 16)
Hash on PW label
Shows format - header has ethernet + IP header + PW label, hashing to
get transport label
Final solution - new label after PW label, finer granularity
Primary hashing based on load balancing label
Need to pop 2 labels at PE
In either case need new TLVs for signalling
Conclusion - need at least one solution to this problem
Label range is easy to implement, lad balancing label solution is better
since more generic 
Since not interoperable, should we choose one, or put both in one draft?
Stewart: since draft came out other operators have expressed interest
Need to compare possible solutions

Ali Sajassi: have you considered OAM issues?
Stewart: Discussed with Luca, majority interest is for IP
Operators expressed interest - DT and others on list in last 2 days)
Giles Heron: customer's IGP is easy, SP IGP harder
Stewart: SP should self repair
Kireeti Kompella: answering a few questions. Important problem, but may
not need a draft. Either solution can live with LSP ping as OAM
Stewart: authors want input from list.
Giles Heron: only a subset is being handled here.
Stewart: IP case is the most urgent
George Swallow: need to get OAM considerations out on the table before
choosing an approach.
Giles Heron: need to document which scenarios we are addressing.
Stewart: need to send requirements to the list. The IP case is certainly
the most urgent.
Giles Heron: but perhaps IP with tunnels hiding header is the most
urgent


OSPF Extensions for Dynamic Multi-segment Pseudo Wires - Andrew Dolganow
([e-mail])
http://tools.ietf.org/wg/pwe3/draft-dolganow-pwe3-ospf-ms-pw-ext-01.txt
------------------------------------------------------------------------
--

Presented to OSPF in Prague. New coauthors added.
Comments incorporated into new version.

Changes in version 1.0: 
Priority given to consensus parts of original draft.
-	advertise AII
-	router does not need T-LDP or Tunnel
-	Opaque LSA mechanism used
-	PW switching LSAs carry AIIs attached at T-PEs: configuration,
advertisement, interaction with EGPs e.g.BGP
Full alignment with dynamic placement of MS-PWs draft

Shows an example of how it works.

Next steps: work closely with OSPF and adopt as a PWE3 WG draft
Create an IS-IS version

Danny: need to determine if we want to do this first and then decide
where to do it.

Stewart: is there any plan to include TE metrics?
Andrew: could use IGP first, then could add more later
Stewart: need to make sure that do not overload routing protocols. Other
work needs to be done first to check this.
Andrew: This was already discussed in OSPF 
Stewart: routing groups must make the call as to whether this is safe
for routing.
Rahul: You are violating architecture as you are advertising customer
state
Luca Martini (via Jabber): only intended for aggregation, and operators
today put customer state in the IGP
Ali Sajassi: Need this in the IGP because the low cost T-PEs in the
aggregation do not run BGP
Alex Zinin: Separation of resources: remember that different LSP
fragments can be advertised separately in IS-IS.  
Regarding BGP and OSPF, obviously requirements for non-BGP solutions.
Danny: how many people see interest in this: a small number of hands
Ali Sajassi: Need some additional discussion with respect to how with
convey this information. Need to still carry some info in P-nodes. 
Do we need to modify PW architecture for this? P-nodes are no longer
completely transparent.
Stewart: it is the ABRs ? Need to discuss this off-line.
Luca Martini (via Jabber): OSPF is just a transport protocol for the
external routes. P nodes install no state !

Danny: take this to the mailing list as to whether we should do this or
not.


Dynamic Update of PW parameters (v00) - Frederic Jounay
([e-mail]) -
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-update-00
.txt 
------------------------------------------------------------------------
--- 

Need this for mobile backhaul for voice services - TDM PWs.
Need to do this update without impacting customers.
Scenarios:
-	setup a new PW. New FEC-> new PW label. Static switching from
the old to the new PW.
-	Scenario 2: PW update - retain the existing FEC. New label
mapping message with dynamic PW update

Draft defines a generic solution.

Presents the CESoPSN parameters that are relevant.
Configured: number of time slots: N
Signalled: P


N and P must be included in the label-mapping message

Proposes PW update TLV.
Use it increase or decrease PW capacity.
Illustrates how this works for a CESoPSN PW.

Next steps: add a section that describes the PW label removal from the
LFIB
Describe the MS-PW approach
Solicit comments.

Stewart: do we need a requirements document? This is a change in the way
PWs work as they were previously static for life.

Hamid Ould-Brahim: reminds me of work we did a while ago with Himanshu.
Why is this coming back?
Frederic: this is a change in interface parameters, so this couldn't be
done before.
Hamid Ould-Brahim: you are reprogramming the data plane. You are doing a
new PW in some sense.
Stewart: can we start by gathering requirements?
Nitin Bahadur: Still not convinced that need anything new.

Danny: Need to work on a requirements document.




P2MP PW Requirements v01 - Frederic Jounay
([e-mail])
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw-requirements
-01 
------------------------------------------------------------------------
----

Illustrates changes since last version.
Clarified the definition wording.
P2MP PW provides a unidirectional service.
Introduces Virtual Private P2MP service (VPMS).

Shows P2MP SS-PW reference model. 
Removed some text: parts referring to VPLS, source/leaf initiated setup,
pats referring to technical spec.
Replaced controversial text.

Next steps: solicit comments and adopt as WG draft

Stewart: who is interested in adding this to the charter?

Some support

Matthew: need to clarify what the difference is between this and
multicast services in L2VPN

Stewart: Question for the ADs





10 mins - PMP PW Signaling and Auto-Discovery in L2VPNs - Rahul
Aggarwal([e-mail])
http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-pw-00.txt
------------------------------------------------------------------
Describes what a P2MP PW is.

P2MP PWs enable a L2VPN to provide a virtual private P2MP service.

A L2VPN offering VPMS referred to as a L2 Multicast VPN
Explains the relationship between sender sites and receiver sites.

Describes BGP auto-discovery using BGP, and BPLS MCAST 

Uses procedures from these drafts

Signaling procedures use upstream assigned labels using
draft-ietf-l2VPN-VPLS-mcast

Inter-AS options are supported by P2MP PWs.

A multi-segment P2MP PW is equivalent to an inter-AS tree

Stewart: need to have a definition of the work area. Need to have clear
blue water between us an L2VPN.
Ali: this is my comment exactly. 2 things: auto-discovery and
signalling. Both of these are already done in L2VPN.
Stewart: need to see if this should be done here or not.
Ali: inter-AS requirement needs to be better cooked.



T-MPLS Update - Stewart bryant ([e-mail])
---------------------------------------------------

At last IETF, concerns were raised about redifinition of PWE3 and MPLS
design by T-MPLS.
Many discussions and a liaison sent to ITU-T about this. Concern covered
MPLS ethertypes, and other architecturally unsound issues.
Liaison addressed issues of separation. 
Options presented:
-	work together. IETF preferred solution
-	state that IETF MPLKS and T-MPLS are different, and ITU-T should
have complete codepoint separation. Not preferred solution.

ITU management referred liaison to four ITU-T groups

Stuttgart proposal: 
-	codepoint separation recommended to be rejected
-	Compatible and consistent design
-	Sole MPLS design expertise in IETF
-	Transport network expertise in the ITU-T
-	Lists domains

Proposed joint working team.

Ben Niven-Jenkins: doesn't seem very realistic to bring this work into
the IETF. What is actually going to happen when inconsistencies are
found?

Stewart, the agreement is that where there is a conflict, ITU
recommendations will be modified to align with IETF architecture

Normative IETF references should be used in the case on any discrepancy.

SG11 and 15 have endorsed the recommendation.
SG13 will meet in January to discuss.
However, G8113 and G.8114 may be consented at this meeting, unless one
country or two sector members object.
Concerns:
-	MPLS label 14
-	Semantics of MPLS EXP and TTL bits, and new P-router behaviour
-	Changes to label 14 need action through the IETF
-	ITU SG15 also accepted a proposal to use label 14 as an IP and
management messaging channel.

Interim IETF work: small IAB ad-hoc group formed to identify
inconsistencies and the IETF decisions to be revisited.

Gile Heron: what happens when joint team meets and one side says use
BFD, and the other sides uses G.8114? I can see the whole thing falling
apart
Stewart: that depends on the two management teams
Hamid Ould-Brahim: you mentioned changes to MPLS, but you did not
mention PWE3 work?
Stewart: Yes, we have a  WG draft that addresses requirements and needs
some more BFD work done. Then it will come back to this group 
Italo Busi: a couple of comments. 
-	OAM work discussed, and straddles both groups. We need to decide
how to proceed. Have not agreed 8114 is going to be used for both
domains. 
Agree that need to make sure that 8114 does not break the internet
domain.
-	Need to clarify what are the problems and some proposals to fix
the problems.
-	Management channel was just a contribution, and there is plenty
of time to change this. Prepared to work with them. Need to come with a
better solution.
Stewart: chair said they were doing nothing that is not allowed by
G.8114
Mark Townsley: Tired of T-MPLS and MPLS operating in separate domains.
Then reason why the IESG/IAB sent a liaison was because of potential
harm. Either get on a different 
Ethertype, or bring it into the IETF standards process.
Kiretti Kompella: echoes Ben's statement. Had this sort of agreement in
CCAMP before.
Monique Morrow: have had a plethora of liaisons sent. G.8113/G.8114,
they are still at AAP, and that means the comments have not been
resolved. The IETF should send a stronger 
liaison statement to the ITU-T
Chris Liljenstolpe: No matter what we say here, we all know that these
will end up on the other end of the same link. 
Italo Busi: Understands concern about G.8114 mechanisms, but does not
understand concerns about requirements
Monique Morrow: refer to Cisco comments on this.

Danny - take it to the mailing list

Eve Varma: we just rehash over and over when we talk about generalities.


MEETING CLOSES

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