IETF 77: Layer 3 Virtual Private Network (l3vpn) Minutes
Monday, March 22, 2010. 0900-1130 Morning Session I


2. WG Status and Update

Ross Callon: [Regarding ďdraft-ietf-l3vpn-ospfv3-pece-05Ē] We last called this document in OSPF. A major comment meant that significant changes to the document were necessary. We expect that the document will be reviewed again by the L3VPN and OSPF WGs before being submitted to the IESG.
Ben Niven-Jenkins: We will request a joint last call then.

3. Using mLDP through a Backbone where there is no Route to the Root

Rahul Aggarwal: [Slide 6 - Another Use of VPN Recursive FEC] why not take out this use case?
Eric Rosen: It is a mechanism that provides use. If itís not useful people wonít use it.
Rahul Aggarwal: There are two choices take it out from the draft, and put this in another draft and call it experimental. This problem is solved using existing L3VPN documents; they provide a solution for carrier's carrier. I see this as an optimisation of existing procedures. During the charter discussion we need to decide to do with this.
Eric Rosen: Do you have a similar objection to the previous application?
Rahul Aggarwal: No.
Eric Rosen: We had a discussion on the wrong mailing list at the last IETF (re: carriers carrier) this is probably more useful for a carrier thatís broken up into several ASís. I see this as a simple use of the mechanism.
Eric Gray: You are not talking about adding a lot of protocol complexity. Whatís the point in taking it out? Once the mechanism is in, it can be used, aside from the philosophical differences. The other view is the use case is evil.
Rahul Aggarwal: I do want to point out that the WG opinion depends on the outcome of the charter discussion.
Marshall Eubanks: Why? This proposal is for the MPLS WG.
Rahul Aggarwal: There is functionality that extends the l3vpn charter. When this draft was presented the draft had two components lvpn and mpls. We can split the work into two separate documents for the two working groups. The l3vpn charter still needs to cover it.
Eric Gray: Two documents may not be worth the energy.
Rahul Aggarwal: That's finally Eric let's see what the charter discussion outcome is?
Marshall Eubanks: So in your opinion [Rahul] we should wait until we have the charter discussion, before we gauge the feeling in the room for this document?
Rahul Aggarwal: That is up to the chairs.
Ben Niven-Jenkins: Whether the specific functionality is useful or not needs further discussion. We can take a sense of the room. Does anyone object to the document being led in mpls?
We will take this to list.
Marshall Eubanks: How many are in support?
(10 hands)
Marshall Eubanks: Opposed?
(Not a single hand)

4.Multicast VPN fast upstream failover

Thomas Morin: Would like to request WG adoption.
Eric Rosen: Something we see in MPLS is what happens if tunnel is down, or up. So much restoration and underlying IP stuff built into MPLS. It's not obvious to me if it it's a good idea to change upstream multicast. Why not wait for tunnels to be repaired. Is there really something going wrong with the mpls mechanisms?
Thomas Morin: So what we did not do yet, is make a distinction between the tunnel being down and cases where you know the tunnel is down for all PEs or criteria to know that only for him or neighbors the tunnel is down. In each case you can apply a criterion for determining this. The draft needs to be more precise in this area. Making a decision on the local status of the tunnel in one case where its valid is hot leaf protection. Although it depends on the type of tunnel, fast recovery is based on the decision to downstream PE, based on the local protection of the last hop. It is true that it is not applicable for all cases.
Eric Rosen: Useful to have more discussion on what kinds of failures which are protected (failure scenarios). How much more coverage do you get if you do this or do not do this, etc.
Thomas Morin: We have been focusing on the procedure and the combination of scenarios to improve recovery. The failure coverage and speed is dependent on the scenario. It's interesting to Look at the various cases.
Marshall Eubanks: If the WG charter includes this item. Would you like to include this for adoption? What terms do you want to see in charter to support this? Working on fast failure, improving fast failure, etc.
Thomas Morin: I do not have a draft recharter for you. It would be sensible to have a precise charter, not something that states work on MVPNs.
Rahul Aggarwal:As a co-author of this document. We need to spell out functionality and requirements. We then need to say if the WG can work on existing procedure optimizations.
Marshall Eubanks: Under the assumption we are not going to shut down the WG. Let's have a show of hands to support document?
(2-3 hands)
Marshall Eubanks: Opposed?
(One hand)
Marshall Eubanks: We will take to list.

5. OSPFv3 as a PE-CE routing protocol

Marshall Eubanks: How will we know you're ready? What is you're done marker?
Emre Ertekin: The draft is ready for review now.
Ray Qiu: We want to give people are chance to review before last call.
Marshall Eubanks: So an initial soak?
Ray Qiu: We
Ross Callon
: Would like to thank you [authors] for your help. We missed that this should have been sent for last call to both working groups [l3vpn and ospf].
Emre Ertekin: No problem, the [ospf] review helped.

6. Support for RSVP-TE in L3VPNs 

Eric Gray: Was there already similar work in the transport WG or MPLS WG?
Daniel King: The document was presented in the ccamp WG. The work requires RSVP C-types; it's probable that the work needs to be done in the mpls WG.
John Drake: There was a previous draft with Francois Le Faucheur Bruce Davies regarding similar work.
George Swallow: Check the transport WG. It seems to be very similar.
Loa Andersson: I am not sure we know where this draft goes.[Slide 1- Problem statement]. If there is a requirement on a bi-dir LSP. Then this needs to be coordinated with ccamp. The WG chairs [mpls and ccamp] need to decide what to do. We do not care which WG it goes to.
Marshall Eubanks: How many have read.
(7 hands)
Marshall Eubanks: Who would you support us taking this on in l3VPN?
(No one)
Marshall Eubanks: Who thinks it should be in another WG?
(3 hands)
Marshall Eubanks: Ok, we should not take this document on.

7a Recharter Slides (Need Bens slides)
7b New WG Items Proposed by Eric, et al.

Ben Niven-Jenkins: Does the group feel that the list of items on the current charter is sufficient? Should we update with additional work items?
Ross Callon: At some point the WG needs to figure out what work it needs to be doing. If you can figure out which drafts, update charter and have explicit objectives.
Yiqun Cai: Last time [IETF 76] we had 60 minutes discussions. Is this a conclusion or are we restarting the discussion?
Ben Niven-Jenkins: It's an extension of our last discussion. We need to decide new milestones or close the WG. Today we would like to get group feedback so the chairs can draft something for review on the list.
Yiqun Cai: It would be good to have milestone target dates and try to conclude on recharter discussions. One of the previous issues at the last IETF [76] is a moving target to finalize recharter discussions. What was the conclusion, quiet for 4 months? I am not blaming anyone just would like to put some targets in. Charter is good we need specific milestones and work items.
Ben Niven-Jenkins: Valid comment. Last IETF we did try to do something, we were not as proactive. Agree text before next IETF. Maybe charter fine as it is but need some specific milestones and items.
Nurit Sprecher: Regarding history of VPNs in the, the work was previously split into l2vpn and l3vpn, from and an industry perspective maybe we can deliver both VPN types on same network. Do we need to come back to l2vpn and l3vpn internetworking and collaboration? Just some thoughts I had, perhaps not specific for this working group but I wanted to raise this.
Marshall Eubanks: My personal opinion, this requires a draft,
Nurit Sprecher: Sure, I wonder if the scope of the charter. Maybe this is something we need to address, perhaps not in this context [l3vpn]?
Eric Rosen: I am glad to hear Ben then Ben [Niven-Jenkins] talking about doing real work. We are not a runaway group, we tend to propose useful work and not useless items.
Ben Niven-Jenkins: The charter does not stop work. The need is to focus the group.
Eric Rosen: When people start saying they need specific items in the charter they are worried that people will work on things that are not relevant. I'd rather see a general charter, we should bring items that are interesting and useful, and we should take on more work rather than less.
Rahul Aggarwal:I agree with the spirit of Richard and Eric. I have one point though, I do not think the WG did not take on work because it was not in charter. I think the chairs and AD decide that three WG docs we had should be progressed. What I would like to see is the work that is useful. We should take a few things that we focus on and we want to get done. Extranets could be picked up. Something thatís open ended, have a milestone, only reason we did not take on work.
Ben Niven-Jenkins: Back to slides. Question 1: Does anyone object to removing VR and CE related (top bullet).
Andy Malis: I was an early author of VR drafts. I have no problem with taking it out of charter.
Yiqun Cai:
Ben Niven-Jenkins: Show of hands to signify that the charter is ok as it is?
(6 hands)
Ben Niven-Jenkins: Who think charter needs refreshing?
(most hands).
Marshall Eubanks: One thing I would add. The charter mentions text thatís specific, I think we should expand the text to include triage. This will include work thatís included in the charter as well as continuation of existing work.
Ben Niven-Jenkins: Ok.
John Messenger: Why is OAM excluded from current charter?
Danny McPherson: A lot of work was happening elsewhere. Primarily MPLS.
George Swallow: As I remember a draft did make it RFC. That was soundly defeated by the IESG mainly as they considered it a layer violation.
John Messenger:Is it still true?
George Swallow: That restriction could be taken out.
Rahul Aggarwal: I tend to agree, we can remove that statement (charter text?)
Danny McPherson: Just a general comment. The charter tends to be a strategy specific items can be defined by milestones.
Stuart Bryant: Take feedback from this meeting and create straw man charter and reflect back on WG.
Ben Niven-Jenkins: Eric also has a list of topics, let's see those.

7b. New WG Items Proposed by Eric

Rahul Aggarwal: How to do this? Shall I go from the top?
Ben Niven-Jenkins: This is Eric's view of items to work towards. Some are drafts that may or not be adopted, some should be milestones.Rahul Aggarwal:My comments on if the technologies makes sense or not.
Marshall Eubanks: A this point we should not debate the specifics. We should we consider that these may become items at some future point.
Rahul Aggarwal: First Slide [S-PMSI Join Extensions]. I have an objection. It's fine to produce options and let the market decide.
Thomas Morin: I subscribe to the idea it's not good idea. I think there is consensus in the working group not to do this.
Yiqun Cai: I also tend to agree with Rahul and Thomas. There has been lots of debate and we have decided.
Ben Niven-Jenkins: So to summarise, some IPv6 extensions are needed. The method or mechanism to extend is a discussion for the future.
Eric Rosen: It makes sense to discuss to extend or not extend.:
Rahul Aggarwal: Next Slide [Wild Card S-PMSI Bindings] Yes agree to
Rahul Aggarwal: Next slide Extranets Happy to talk about this
Rahul Aggarwal: Next slide [bi-dir p-tunnels] This has to be clean separation.
Rahul Aggarwal: Do we need this? We need to take this back to SPs. We need feedback from SPs for sure.
Thomas Morin: [bi-dir p-tunnels] What I would expect from such a statement, draft to explain what's missing. If there is usefulness I would like see one p-tunnel per VPN, for this to be possible to have multiple p-tunnels.
Eric Rosen: I think that case is covered.
(Continued discussion between Thomas and Eric)
Ben Niven-Jenkins: Let's not get into the details.
Rahul Aggarwal: I want to correct one thing. Considerations mandates two technologies, what you are proposing is a third way. You cannot argue that itís a must in considerations..
Eric Rosen: There is PIM and BGP, etc.
Rahul Aggarwal: Do not use the considerations as an argument.
Yiqun Cai: Are we using considerations draft for charter discussions? I thought just requirements draft.
Ben Niven-Jenkins: I do not see the considerations draft as flag bearer. The chairs have an action to create a straw man.
We are not saying that we can only work on things in or out of the considerations draft. It's not a gating factor.
Thomas Morin: I see this as adding noise for SPs making a decision. I do not support this as a WG document.
Ben Niven-Jenkins: We understand that Rahul Aggarwal and you do not think these items should be included:
Ben Niven-Jenkins: We have made a bunch of notes. Co-chairs have some work to do. We come back to list with straw man.
Ross Callon: Worth a show of hands now?
Ben Niven-Jenkins: Let's see if we have consensus when the straw man document is ready.

8. Multicast in MPLS/BGP IP VPNs

Rahul Aggarwal: [slide 3] The WG spent a number of years developing the architecture which includes pieces of technology that are standards which is mentioned here. The WG should not approve this document.
Eric Rosen: I compare this to the Martini documents, which preceded the PWE WG and were held as drafts until after PWE completed its work.
Rahul Aggarwal: My interpretation of the market is that a wide number of customer's deployed draft-rosen version 6 of this document, a large part is detailed in the MVPN architecture document currently in the RFC queue.
Eric Rosen: The architecture specification in the RFC editor queue does not have a bunch of things that were in the revised document. Rahul Aggarwal: Here we have the technology, rosen version 6 versus the rest.
Marshall Eubanks: Is the 13 the same as version 8?
Eric Rosen: Some changes across drafts.
Yiqun Cai: As far as I know least to vendors have implemented version 8 that is interoperable. Around 5-6 customers deployed version 6, five years ago with people upgrading to version 8 and above overt time.
Danny McPherson: I would prefer to see this published thru the WG with a historic flag and not as an individual submission. I also understand Rahul Aggarwal's concern.
Eric Rosen: I think it's better as historical. No need to add new things, as long as it stays a living document.
Ben Niven-Jenkins: Is your intent to say there is multiple deployments therefore its useful to document this in a formal way.
Eric Rosen: Publish it, so I do not need to work on it again.
Thomas Morin: [First slide] So luck is not enough? My point is I am worried that a proposal diverts effort of WG. Do you expect them to not read the document?
Eric Rosen: The document has been around for so long. No secrets, pre-standards mechanism.
Thomas Morin: It may be useful to document, but I do not think the WG should work on it.
Marshall Eubanks: Historical is not tweaking the proposal.
Ross Callon: I was going to argue as an old ietf guy, this is not a new issue. The issue comes up as do you want to document what got done in the past. Itís a judgment call to decide that these are historic RFCs. Pre-standard, obsolete etc.
Marshall Eubanks: I've heard historical used as "do not do this". Would you say this would not be a large amount of work.?
Ross Callon: Reasonable to have paragraph explaining that this was done in the past and people have deployed pre-standard technologies. Historic does imply all of this anyway but we can state it anyway.
George Swallow: With respect, I think Ross Callon' text is redundant.
Andy Malis: There is a precedent in PWE WG that described implementation in field and one for the standard. We published proposed standard, then pre-standard and added text.
Rahul Aggarwal: If you go back to draft-rosen 6 that was implemented, then 7 that had extra features that was less widely deployed and same with 8. The first thing is this is work for the WG. We need to disseminate the diffs. Tomas Morin made a point that this is diversionary.
Danny McPherson: I looked at Andyís draft; they went straight from individual to the RFC editor on the individual submission track and were held until the PWE2 work was done.
Marshall Eubanks: Eric could certainly publish this in the MPLS WG.
Wim Henderickx: Big difference between 8 and 13.
Marshall Eubanks: Do you agree Eric Rosen?
Eric Rosen: No, it's not that big.
Wim Henderickx: Do a diff between 6 and 8.
Marshall Eubanks: Any reason we cannot version 8 and make some adjustments and use that to move forward, as historical? We could remove the IPv6 support if no one has implemented. Have they implemented all the mechanisms including IPv6?
Eric Rosen: I do not think there is anything in this document that no one has implemented.
Ben Niven-Jenkins: I wanted to ask some questions to the group.
Q1. In general is there value in documenting what is developed for MVPN prior to current standards?
(20 plus hands)
Does anyone think that we should not document this? I.E., not take on this work?
(1 hand)
Is version 13 an appropriate document to publish?
(2 hands)
And no?
(1 hand)
Is version 8 a good document for historic publication?>
(13 hands)
Ben Niven-Jenkins: Ok, take to list.