IETF 77: Layer 3 Virtual Private Network
(l3vpn) Minutes
Monday, March 22, 2010. 0900-1130 Morning Session I
1. Administrivia
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?
(No)
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).
(No)
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.