IETF-76 L3VPN Meeting Minutes
Monday November 9th, 2009, 1300-1500 Afternoon Session
I
Agenda
1. Administrivia
2. WG Status, Update
3. Using mLDP through
a Backbone where there is no Route to the Root
4. Mandatory
Features in a Layer 3 Multicast BGP/MPLS VPN Solution
5. Multicast VPN fast upstream failover
6. Working Group Recharter
1. Administrivia
- No agenda change request.
2.
WG Status, Update
- Welcome Ben Niven-Jenkins as a new working group co-chair
- AD update on draft-ietf-l3vpn-2547bis-mcast
Ross
Callon: The multicast BGP draft should not have the
sub-state of AD follow-up. I will change the sub-state shortly. We had this on
an IESG telechat and we only had 9 votes. We need 10th vote. It's
been out back on the next telechat [after IETF 76].
3. Using mLDP through
a Backbone where there is no Route to the Root
Presented by Ijs Wijnands
- Questions?
Ron
Bonica: The draft appears to be about MPLS, but the
motivation is L3VPN?
Ijs Wijnands: The motivation is also
for global tables.
Ron Bonica: My concern is it defines
new procedures for carrier's carrier, where we already have procedures for
carrier's carrier. We need a discussion on are new procedures required, and why
they are required. Then will these new procedures meet existing requirements?
Ijs Wijnands: Which procedure for
carrier's carrier are you referring too?
Ron Bonica: The ones from 2547 BIS
[draft-ietf-l3vpn-2547bis-mcast-bgp].
Ijs Wijnands: I am not aware it
describes carrier's carrier.
Thomas Morin: Just to give some more
detail, it’s true draft MCAST
[draft-ietf-l3vpn-2547bis-mcast-bgp] explains the procedures. I agree that the
motivations for why another solution is needed would be useful. There is a
significant difference between the solution you presented and what's already
available. Currently we can aggregate multiple external trees into one LDP tree
on the carrier's carrier model. That seems to be missing from what you
presented.
Ross Callon: [As AD] this draft is
interesting for MPLS and L3VPN, by becoming a working group draft gives it some
credibility. For the correct process, the question [poll] whether or not it
should become a working group draft should go to both working groups. The work
would still only sit in one working group.
Loa Andersson: We are comfortable to
do this [poll] within the MPLS working group.
Marshall Eubanks: Which working
group would you prefer?
Ijs Wijnands: The procedures are
mainly MPLS, so the MPLS working group.
Loa Andersson: Just one comment, the
chairs of each [MPLS and L3VPN] working group would need to communicate for how
to perform the poll and last call.
4. Mandatory Features
in a Layer 3 Multicast BGP/MPLS VPN Solution
Presented by Thomas Morin
- Next Steps
Danny McPherson: I have been
communicating between Thomas [Morin] and Eric [Rosen] on this. The outstanding
item is to wrap up some text and submit back to the working group. LC will
happen only on the parts that had editorial changes since the previous LC
Marshall Eubanks: Is the goal to do
this before the next IETF[77]?
Thomas Morin: Yes.
- Appendix A [Scalability of C-multicast routing processing load]
Ijs
Wijnands: I have some concerns regarding appendix
A. It makes a comparison between PIM and BGP, but it's dangerous to make this
comparison because it could become outdated, as the protocols might be
improved, before the document becomes an RFC. So I do not think the [protocol]
comparison should be included.
Thomas Morin: I think it was agreed
that this draft would focus on what is described on the specifications draft.
Further improvements are completely out of scope. If you believe there are
personal opinions rather than facts please highlight them.
Yiqun Cai:
Regardless of personal or working group opinion, there was a debate on if PIM
overhead should be considered or not for the comparison. If we want to evaluate
the control overhead placed on the router, then we need to consider all the
[multicast] parts not a single part.
Thomas Morin: This has been
discussed extensively on the list, multiple times. There are scenarios for PC
in PIM.
Yiqun Cai:
We are picking pieces of the control plane and performing a comparison.
Thomas Morin: The objective of thus draft is to comparison multicast options. In this
contest we are differentiating options. The information is in the draft you are
free to comment.
5. Multicast VPN fast upstream failover
- No comments
6. Working Group Recharter
- Next steps
Marshall
Eubanks: Ross [Callon], do you have an AD perspective on you see us proceeding?
Ross Callon: The first thing I would is to progress the two existing
drafts. I am suspecting yes there is more L3VPN work. I am assuming we have
additional multicast work.
Marshall Eubanks: The previous piece
[draft-morin-l3vpn-mvpn-fast-failover-03] Thomas [Morin] presented could be a
working group item.
Ross Callon: We discuss what we want
to do and then write it into the charter. The existing charter has some
vagueness regarding what we want to do for multicast. I’d prefer some
clarification if we can do so. If we identify items now, we can always update
the charter again if we find we have more work.
Marshall Eubanks: I am thinking that
this cannot come from the chairs. We should open this up to the group.
Yiqun Cai:
As a co-author of draft-rosen-l3vpn-mvpn-mspmsi-05, we feel this is a good
basis for some L3VPN working items. So I would like to request that the working
group accept this draft. We could accept the entire draft, or split the draft
into several drafts. We would also seek additional co-authors.
Marshall Eubanks: Do the authors
think this should be one draft or several drafts?
Yiqun Cai:
We are open.
Ben Niven-Jenkins: Can you remind us
of the topics?
Yiqun Cai: 1) S-PMSI Join extensions
2) Wild card support in S-PMSI A-D routes and S-PMSI Joins 3) Finish the
specification for the use of bidirectional P-tunnels 4) Using PIM as PE-PE
control plane, but without using MI-PMSI 5) Extranet support using PIM control plane
6) Offering MVPN service with PIM control plane in concert with unicast
"Hub and Spoke" VPN service and anycast-source service.
Ben Niven-Jenkins: Are we cleaning
up or enhancements?
Yiqun Cai:
Enhancements.
Ron Bonica: [Speaking as an
individual contributor] I would
recommend that you place a high priority on the existing work items if you
recharter. [Speaking as an AD of Operations and Management Area] As you
consider new work items you might want to poll the operator community and see
what they are likely to use.
Marshall Eubanks: Besides the
operators in this room?
Ron Bonica: The operators in this
room are a good place to start.
Andy Malis: Speaking as an operator,
other than multicast, we are happy with the state of things. We have happy
customers.
Thomas Morin: Speaking as an
operator and contributor there are obviously areas that need to be addressed by
the working group, including extranet. There are two drafts than propose a
solution. This is a feature required by the multicast requirements RFC. The
other item is multicast fast-failover. At the same time it's important to have
a clear view on how the current documents of the working group will progress
[through the IESG].
Ben Niven-Jenkins: As an operator
extranet is on my list. Multicast and IPv6 are important.
Ron Bonica: A question for the three
operators in the room. We have lots of operation experience with unicast. Do we
need a few years of operational experience to understand what we need next for
multicast?
Yiqun Cai:
We actually have MVPN experience, starting from two years ago.
Ron Bonica: I am concerned that we
pursue too many things before we have real operational experience. Watch it
scale, fall over, all the ugly experiences when deploying new services.
Yiqun Cai:
Do we need a working group document to solicit MVPN experience?
Ben Niven-Jenkins: Does the group
feel there is enough experience with multicast which would warrant further
work.
Yiqun Cai:
We have had PIM solutions for a sufficiently long time. The BGP based solution
is newer. We need to start somewhere.
Marshall Eubanks: What is the
deployment of PIM versus BGP based solutions [question to the room]. Would
anyone be willing to talk about their experience or plans for the BGP based
solutions?
Ron Bonica: The problem is we only
have three operators in the room and some may or may not be able to discuss it.
It's difficult to pool that question.
Ben Niven-Jenkins: Two options. We
can shut the group down and wait while operators get more experience. The
alternative option is that we agree there is more work we can do now. The view
seems to be that we do have items people are interested in.
Ron Bonica: I think there is a third
option. Don’t shut the working group down. Finish the existing work over 3-6
months. Then look to recharter when the plate is empty.
Yiqun Cai:
I support Ron. I do not want to see the working group shut down. Given the
experience of MVPN deployment we have interoperability issues where we can
involve the working group, operators and developers to find solutions. Having
said that maybe we have to wait a year as the existing work items are in last
call. I suggest we move forward with the new items.
Ijs Wijnands: We have customers that
are asking for solutions from draft-rosen-l3vpn-mvpn-mspmsi-05. I do not see
any issue with progressing those solutions now.
Thomas
Morin: I agree that closing the working group is
not a good idea. We have a few items that are relevant. We need to work on
them.
Ben Niven-Jenkins: I think that the
previous reason for not accepting new work was to clear the existing plate.
Ron Bonica: It might be good to
clear the plate then look at a recharter, but not before then. If it’s a
working group draft then it's on the plate.
Ross Callon: We may find ourselves
at the next IETF [77] with the current work ready for publication. If that’s
the case I do not see an issue with showing up in Anaheim [IETF 77] with drafts
that people want considered.
Marshall Eubanks: Our charter states
IP Multicast so it s fairly wide ranging.
Ross Callon: Yes.
Marshall Eubanks: Would it be
appropriate to start consider new drafts in January and not wait for Anaheim
[IETF 77]?
- BGP Multicast
Marshall
Eubanks: Anyone have suggestions on how we can find
out about BGP Multicast?
Daniel King: We could create an anonymous
survey to gauge how many and how big people have deployed or are considering
deploying BGP multicast.
Marshall Eubanks: Would you be
willing to do this?
Daniel King: Yes, I am not a vendor
or operator.
Ross Callon: If we have a suspicion
that BGP multicast is deployed but no one is willing to admit it there are two
ways forward. The first is to approach people and see if they are willing to
state this publically. The other option is do something to what Daniel [King]
proposed. This could be done via email or private survey and publish the
results.
Marshall Eubanks: We did that
previously. It's more like soundings than a survey.
Ron Bonica: I like the idea of an
anonymous survey. You could also poll organisations like NANOG, RIP or Apricot
where you will find a larger number of operators.
Yiqun Cai:
From a vendor view. We tend to write things about implementation experience to
help each other. I'd be happy to discuss my experience. Other vendors can do
the same.
Thomas Morin: I am a little
skeptical on the survey idea. It was done for the MVPN requirements draft. The
focus was to gain information on deployment numbers. We had a drive for asking
the information. I am not sure we clearly indentified the driver for performing
a survey. I do not see this [the survey] as a prerequisite for accepting new
work. In other working groups people define problem statements and propose
solutions.
Ben Niven-Jenkins: I don’t think we
are saying this [a survey] would stop us accepting new items. The question
would be is it valuable to know what people are deploying. These are two
different topics.
Marshall Eubanks: A survey might not
be the right way to go. Yes, it would be nice to know if people are deploying,
but the real question is what problems are people seeing, or is something
missing. I am not sure if we get this from a survey.
Thomas Morin: I think that feedback
happens anyway as operators contribute to a draft.
Yiqun Cai:
I agree.
Thomas Morin: You have forums to hear
about implementation and feedback. It's not necessary to reflect this
information within IETF work.
- Meeting Ended