[PWE3] Philadelphia minutes

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

Folks,

Please find attached the draft minutes from Philadelphia. Please let me
know if you have any comments.

Best regards,

Matthew


> Monday, March 10th, 2008 - 15:20 - 17:20
> ----------------------------------------
> CHAIRS: Danny McPherson & Stewart Bryant
> SCRIBE: Matthew Bocci
> 
> ------------------------------
> WG Status and Update - Chairs
> ------------------------------
> 
> Agenda agreed.
> 20 RFCs to date
> 3 held up
> MIBs pushed through to IESG.
> MS-PW requirements - many security requirements on this. Trying to
> resolve these. There is a backlog behind these.
> ATM MIB a little late - updated now
> Work in progress - many held up due to MS-PW reqs.
> Redundancy - now a WG item. No negatives on the list. A few comments
> on list about couple mechanisms together.
> Need some work on other MIBs.
> New charter being worked on
> OSPF routing draft - needs to coordinate with the OSPF. Chairs will
> check with ADs that this is OK to take on.
> 
> ----------------------------------------------------------------------
> PW Redundancy Update - Praveen Muley
> ([e-mail])
> http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-redundancy-bit/
> draft-ietf-pwe3-redundancy-00.txt (posted to list)
> ----------------------------------------------------------------------
> 
> Gives an update on the drafts. Both adopted as WG docs.
> Major addition is revertive behaviour.
> Framework and Requirements:
> -	added new co-authors
> -	added new definitions and terminology
> -	aligned text to be more to FR like
> -	added generic PW requirements
> 
> Shows new terminology.
> Generic PW redundancy requirements - 1:1 is mandatory, N:1 optional
> 1+1 is left for further study.
> Non-revertive mandatory, revertive optional.
> Added operational requirements.
> 
> Preferential forwarding status bit draft:
> -	updated scope of protection capabilities achieved
> -	- revertive/non-revertive behaviour
> -	Added appendix
> 
> 
> Next steps 
> -	manual lockout case
> -	more feedback from WG requested
> 
> Danny: has evolved and progressed and fine to go forward
> ??: ITU-T have defined some linear protection. Better to align with
> ITU-T.
> Dave McDyson - I agree. Important clients are TDM etc that have their
> own native protection schemes. Framework would be a good place to map
> native service terminology and make appropriate references.
> 
> -------------------------------------------------------------------
> MPLS & Ethernet OAM Interworking - Dinesh Mohan ([e-mail])
> http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> -------------------------------------------------------------------
> Presented by Nabil Bitar.
> 
> Current PWE3 OAM message mapping does not address interworking with
> Ethernet OAM.
> Since then, good progress in Ethernet OAM space. 
> This draft tries to complement the mapping draft with interworking
> with PWs.
> Shows reference model.
> Consistent fwd/reverse defects with message mapping draft
> Explains PW and AC defect detection options, and the mapping of
> reverse and forward defects between the Ethernet AC and the PW
> 
> Next steps: 
> Could merge with oam-msg-map or pursue as a separate draft.
> 
> Yaakov Stein - this is important work. Have you also looked into .3ah?
> We need this covered too.
> Nabil: I thought we did, because we cover link level defects. We need
> to go back and make sure this is covered.
> Ali Sajassi: This is a very good comment. Counts for ELMI too in MEF.
> Luca Martini: I have asked for this years ago, and chairs did not want
> to put into. I am in favour of putting this into message mapping.
> Stewart - don't remember, but msg-map is quite mature
> Luca Martini - this will generate more interest again and we can
> progress this.
> Stewart - Monique is the editor and she just refreshed it. It would be
> good to review msg-map, and progress Ethernet separately as some more
> material to add.
> Yaakov Stein - agrees should be separate, and not hold up message map.
> Danny: is there consistent terminology with OAM and redundancy drafts?
> Nabil: The mapping draft is most advanced, and common authors with
> redundancy, so hope they are consistent, but need to check.
> 
> Stewart: if existing OAM message mapping draft is nearly done, then
> keep separate so as not to hold up.
> 
> Luca Martini: what will the IESG say without the lack of Ethernet?
> Stewart: put in informative reference to Ethernet doc. Co-authers need
> to add informative reference, and then we will last call it.
> George Swallow: The way the industry is going, the Ethernet is the
> most important part.
> 
> ----------------------------------------------------------------------
> -------
> LDP AII Reachability - Frederick Jounay
> ([e-mail])
> http://tools.ietf.org/id/draft-delord-jounay-pwe3-ldp-aii-reachability
> -00.txt
> ----------------------------------------------------------------------
> -------
> 
> First version of the draft.
> 
> Explains rationale.
> Procedure to populate AII routing tables in first hop S-PE via LDP
> Intended to complement IGP/BGP mechanisms
> Problem statement:
> Typical to access networks. No IGP or BGP - p2p physical connectivity
> But run LDP for PW setup
> IP and PW addressing separate
> 
> Does NOT replace routing protocols
> Advertise only locally attached AII
> 
> Explains proposed mechanism
> 
> Next steps:
> -	feedback from WG
> -	add some extra scenarios (dual homing)
> -	extend to AGI as well?
> 
> 
> Luca Martini: What do you mean by extend to AII?
> Fred: Just mean also use for VPN provisioning using LDP
> Luca Martini: Just haven't found a good application for the AGI in
> this context, but would like to know if you have one.
> Fred: Network autodiscovery populates on S-PE/T-PE, but VPN
> autodiscovery must only be at the end point
> Hamid Ould-Brahim: on your 1st slide, what do you mean by interwork
> with other auto-discovery mechanisms?
> Fred: the S-PE can relay this info based on BGP or IGP
> Luca Martini: confusing term is auto-discovery. It should be over
> routing protocols.
> 
> Stewart: Who is interested? Lots
> Stewart: Who thinks this is a good starting point? Quite a few
> 
> 
> ----------------------------------------------------------------------
> -----
> Conversation Hashing for Pseudowires - Vach Kompella
> ([e-mail])
> http://tools.ietf.org/id/draft-vkompella-pwe3-hash-label-00.txt
> ----------------------------------------------------------------------
> -----
> 
> Discussed a long time ago, but no demand at that time. Then Stewart
> brought fat PW draft, so I wanted to add this to the pile.
> 
> A PW can carry many flows, and do not want PW to follow one path if
> the PW has many flows that can follow different path e.g if PSN has
> ECMP or LAG etc
> Explains PW hashing fields
> Could use hack such as looking at 1stt nibble, but complex and only
> works if it is a 4/6 for IP.
> Can we do something intelligent with the label stack?
> 
> Shows an example.
> 
> Solution proposes that 2 ends of PW exchange a range of has labels
> that can be used by ingress side to hash traffic and pick a next hop
> for trhe PSN.
> Packet: tunnel, hash, PW label, payload
> 
> At LSR, LSP swaps on tunnel label. 
> 
> At egress, tunnel popped, hash is popped, and then you proceed based
> on PW label.
> 
> Benefits include the fact that ingress holds one set of labels per
> peer. Egress distributes one set of labels. Extensible to PSNs and to
> BGP VPNs. 
> Hasahable info is stable per flow, uses MPLS methods, requires no
> changes to the CE, minimises the labels allocated and programmed per
> node.
> Acknowledges that some P routers don't hash this way (order of
> labels), would like to understand if we should...
> 
> Shows some considerations on extending to PSNs. 
> Ingress PSN- hash label at the top of the stack.
> Questions - where should we put hash label? I think it should be
> before the PW label to leave PW context processing to the end. 
> How does this work with existing implementations?
> Is this a new FEC? Or just a capabilities exchange?
> Diversity for BGP label exchanges.
> Should this be done in MPLS WG?
> Could this be used to explore PW paths like LSP-ping multi-path?
> 
> Danny: please address these questions first, then we will go to
> regular questions
> 
> Yaakov Stein: yes, place to put it is between PW label and tunnel. How
> does this work for LSPs.
> Vach: For PW, 1stst guy gets a packet with n different hash labels, to
> choose n different next hops. 
> Discussion taken off line
> Rahul : not sure if this applies to IP VPNs because IP header
> involved. PSNs could be an issue due to application level entropy...
> Kireeti Kompella: good stuff here. There are a lot of things you have
> not done quite perfectly yet. Happy to help. In picture, how do you
> get a good hash if you have 20 bits of option and only using 3 bits? I
> think you put labels in wring place - talk about off line - but do
> agree we need to extend to IP VPNs and PSNs.
> Stewart - include me in this.
> Kireeti Kompella - I agree bottom is the right place. Would like to
> take out of PWE3 for now, and talk among all the interested people.
> Then we can figure out how to proceed.
> Danny: agree
> Don O'Connor: is this only for best effort?
> Vach: this is not developed well enough for multiple levels of service
> Don O'Connor: should this be in the charter? 
> Vach: Could use diffserv TE and use different hash label
> Stewart: Not clear that you need to know this
> Don O'Connor- if you want to groom traffic by traffic class in an S-PE
> this should be allowed
> Ali Sajassi: have you considered impact on native and PW OAM?
> Vach: No, not yet
> Ali Sajassi: It has impacts and needs to be considered. If you exclude
> OAM for the time being, why not assign multiple PW labels?
> Vach: Service Providers have large numbers of PWs. That would not
> scale. Amount of churn on every failure would be too high. 
> Ali Sajassi: need to address OAM
> George Swallow: only time I looked into what labels are hashed on,
> everyone hashed on bottom label. Could do this survey again. If this a
> general mechanism, should not be in MPLS. I would like to be on this
> mailing list.
> Stewart: issue that if we do this in MPLS, not clear that the
> signalling for PS will work properly.
> Kireeti Kompella: need to do something for underlying tunnels, and
> make some generalisation about load balancing. We can then farm out
> the signalling to individual groups. Framework in MPLS.
> Stewart: Agrees to that.
> Vach: requirements come from providers, and they have lots of
> differences, but there is also differences on the implementation side
> so would like to not just give to a set of providers.
> Stewart: My draft was with DT because it is a real SP problem.
> Mark Townsley: No problem in defining this in MPLS, but pressing
> problem is here. Does not seem all that pressing for the IP case.
> Dave Allan: Would echo Mark's comments - for something that can hash
> IP now, too much complexity. Also need to ensure OAM flows fate share
> with combination of PW and hash label.
> Luca Martini: Comment on both drafts. Does not solve a generic
> problem. Only works if you can identify a flow to has on the input.
> What causes such a large flow? And IPSec flow from a bank? This only
> works if you can identify the flows on ingress.
> Shane Amante: agree this belongs in MPLS. Mark and Rahul had some
> discussions about IPVPN. This is needed for that because customers USE
> THESE FORLARGE FLOWS.
> 
> Danny - Need framework and requirements and coordination with fat PW
> stuff. 
> 
> ---------------------------------------------------
> T-MPLS Update - Stewart bryant ([e-mail])
> ---------------------------------------------------
> 
> Describes SG13 plenary in Seoul. T-MPLS protocol and requirements.
> Q5/13 in Seoul. Meeting attended by 3 IETF Ads, plus 1 from IAB. Goal
> to represent comments from IAB DT.
> Considerable work on requirements - amended to become implementation
> neutral requirements, which were published as an informational
> supplement. Available through ITU-T web site.
> Non-normative, but lots of useful info on improving OAM for MPLS and
> PWE3.
> 
> G.8114: no technical work. Question recommended that Recommendation
> withdrawn from AAP and publication stopped.
> 
> SG5 plenary: 
> Considerable work done before meeting on structure of JWT. This was
> approved. Because of the pending decision on JWT, all related tech
> work on T-MPLS halted until decision taken.
> 
> JWT task to recommend option 1 or option 2 to ITU management.
> Small team of experts picked.
> Jointly chaired by David Ward and Malcolm Betts.
> Based on technical studies of 2 large study groups - IETF interop
> design team, and ITU-T ad0hoc group.
> 
> IETF Interop design team will perform technical analysis to determine
> what ITU or IETF docs/technology mods/extensions needed. Advise JWT on
> the deliberations.
> IETF MPLS interop DT chaired by Loa. Must report by April deadline.
> Technical work is only to understand what needs to be done. Design
> will be done in normal standards process.
> 
> Shows work areas.
> 
> ITU Ad Hoc group investigates technical info needed to decide between
> option 1 and option 2
> 
> JWT will compile results of 2 support groups and make a decision.
> 
> Regardless of option 1/2 decision, we have learned a lot about OAM
> requirements. Will be a draft on this.
> There is also mis-understanding about the use of the EXP bits. There
> will be a draft to clarify this as well.
> 
> Don O'Connor: what about protection, data plane, etc
> Stewart: the only thing we can really do is reverse engineer the other
> documents, as there are no requirements for these.
> Don O'Connor: what is ITU design team going to be doing?
> Malcolm Betts: we had a n=meeting in Geneva for 2 days. We developed
> some requirements, and posted on ad-hoc teams FTP site. We should have
> some improved clarification on requirements in the next few days.
> Don O'Connor: so if option 1 is chosen, future methodology is 1 DT
> with requirements?
> Stewart: some things will be done here, but some things will happen
> over in ITU e.g. G.805 modelling. But MPLS technology extensions have
> to happen here.
> Malcolm Betts: agrees. Note these design teams have no authority to
> change IETF or ITU-T documents. These have to be done via regular
> standards process in the appropriate bodies. We also need to improve
> liaison process.
> Stewart: There is a common agreement that we will work together
> Danny: Appreciates the incredible amount of work done. Thanks to
> everyone.
> 
> 
> -------------------------------------------------
> PW Multiplexing - Yaakov Stein ([e-mail])
> -------------------------------------------------
> No draft on this.
> 
> Heard a bit about protection and load balancing today. These were held
> over from last time. This is some architecture work. In PWE3 arch, we
> have an element that can help us. This is a PW Mux which is based on
> the forwarder in the arch draft. A forwarder gives you a many-many
> connection.
> Can be used for protection, AC protection, and PW load balancing and
> inverse mux.
> 
> Doesn't think label space exhaustion is a problem because 2^20 labels
> Explains 1+1 protection. PW mux maps AC to appropriate PWs. 
> 1:1 can use PW redundancy signalling, but then PW mux makes the
> decision on forwarding.
> 
> 1+1 AC protection: AC mux, and associate multiple ACs with single PW
> label
> 1:1 AC protection : again map single PW label to multiple ACs.
> Load balancing and inverse mux: use all PWs at same time, but not for
> all the packets.
> 
> Proposal is for pure architecture work. 
> Need a single method for PW protection, AC protection and load
> balancing and PW mux.
> Means a single label for associating PW labels to AC IDs.
> Designating PW status
> Signaling between forwarders
> 
> Sasha V: agree with Yaakov, and 3985 says must be per-tunnel, but 4447
> says must be per-platform because of MPLS arch requirements. Can you
> map CE dual homing to this? This is not covered.
> Yaakov: why is this not 1+1 AC protection?
> Sasha: Because not one PW
> Yaakov: This is a very important use case. If it cannot be included,
> we should see if we really want to proceed.
> Andy Malis: on ACs, why not just use LAG or multi-link
> Yaakov: could do, but this is a single AC from arch point of view.
> Sure you could do that. But that is not using the function of the
> forwarder.
> Andy Malis: so why is this needed?
> Yaakov: might not be Ethernet, might be ATM IMA etc.
> Dave McDyson: why can't these just be native service protection?
> Yaakov: If you have native service protection, go ahead and use it if
> you want. 
> Dave McDyson: is this really a requirement then
> Ali Sajassi: so you are proposing multiple PWs per AC for load
> balancing?
> Yaakov: yes
> Ali Sajassi: we have an internal PW ID and a hash ID, whether you map
> into a single or two labels, that is only an encoding issue.
> Yaakov: might be computationally more expensive with two labels that
> you have to pop.
> Ali: 2 issues: number of labels and processing in the PE. Processing
> in the PE is not an issue.
> Stewart: putting an extra label in is not computationally complex.
> 
> Danny: proposal is that you publish a draft on anything else you want
> to discuss.
> Yaakov: wanted to have presentation because wanted to gauge interest
> Stewart: touches on a number of areas 
> Danny: could submit as a draft this is the appropriate way to convey
> this.
> 
> ------------------------
> Meeting Closes (early!).
> 
> 
> 
> 
> 

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