Subject: Minutes

From: Ron Bonica <[email-masked]>
Date: Mon, 06 Aug 2007 14:23:05 -0400

Folks,

The following are minutes from our last meeting. If there are no
corrections, I will post them on Friday.

                                             Ron

==================================================

WG status/charter - Ron/Rick
----------------------------------------------------------------------------

Ron - Only one or two docs left outstanding (mostly to do with multicast).
So would be good to recharter.  Virtual Routers etc. could come in - was
taken off charter before.  Anyone who wants VRs on charter can they please
come to the mic?

Hamid - unintelligible.

Eric - I thought it was good to drop it.  Seen same pattern over the years,
nothing gets done until we threaten to do it when we get a flurry of work.
Don't want to put on the charter unless there are lots of people interested.

Ron - if you're interested in seeing VR completed raise hand.  3 hands.  If
opposed then raise hand.  5 hands.  Do we take to mail list?

Mark Townsley - unintelligible.

Ron - will take to list and see if can get consensus one way or the other.

Ron - next issue we talked about bringing was MPLS LSPs over L3VPN.  Kenji
will talk about this (signalling LSP from CE to CE through L3VPN).  Is that
work we'd like to see the WG doing?  No comments...  Sense of room... 3
hands.  Does anyone not understand the question?

Kireeti - do you have to be an SP to answer this?

Ron - no, just in the room...  any strong feelings?

Luca - how does that relate to L1VPN?

Ron - only diference is that it is for people who are already doing L3VPN.

Mark - other difference is how deeply signalling from CE goes into SP's
network.  L1VPN is setting up Lambdas.  This work is going over existing
L3VPNs.

Ron - sense of room.  Anyone interested in bringing the work to the WG?
2 hands...

Ron - next issue is authentication.  Mechanisms that prevent misconfig (e.g.
CE attached to L3VPN without authorisation) or mechanism to detect such
attachment.  had two past drafts, both went away for lack of interest.
Sense of room as to whether people are interested.  A few hands.

Eric - are we just going to bring back old drafts and let them die again?

Ron - will fire myself as editor and see who can advance it.

Eric - that won't be sufficient.  Seems like we ought to do this, but never
been possible to get enough traction for any given method.  Is it different
this time?

Rick - unintelligible.

Shane - speaking as an SP I realise this has languished for a while but see
it as fairly critical and with an operational use in our own network.  Am
surprised not been completed to date and strongly advocate we pick it back
up.  we face these problems on a daily basis and rely on legacy OSS to watch
the network for us - would be much better built into the protocols
themselves.  4 or 5 people interested.  Will Shane be editor?

Shane - don't have the time.  But willing to contribute.

Mark - when we have BoFs to start WGs we ask if people are willing to write
text etc.  And sometimes even "do we have employers who will support it".
Of those people who said they'd like to see it done would anyone take over
editorship of any of the docs?

Shane - better to ask list.  Many more people there than here.

Mark - I wanted to at least get someone here.  But let's go to the list...

Ron - I don't see enough support for any of the 3 areas.  will ask again on
list...

Multicast VPN - Eric/Rahul
----------------------------------------------------------------------------

Eric - tried to put finishing touches on this set of docs.  Some finishing
touches are bigger than others!

1) gone through and tried to clarify the notion of upstream multicast hop
determination. In previous docs that was spread out so all in one place.

2) new notion of upstream-assigned PE labels (will discuss)

3) added more material on MP2MP LSPs as P-tunnels

4) added support for BIDIR-PIM by customers (never got around to up to now).

(1) New Three Letter Acronym (UHM).  Trying to carefully distinguish finding
upstream PEs from the PIM notion of "RPF determination".  Had complaints
that
the document didn't support load balancing, so added simple procedure.  Uses
a simple default hashing algorithm.  can do more complex stuff if you want.
There's work out there on multicast specific topology (OSPF MTR, BGP SAFI 2,
etc.). Sets of routes only used for multicast.  So incorporated that into
the language for choosing the UHM.  Introduced BGP SAFI 129 (VPN equivalent
of SAFI 2).

Another area where clarity was lacking was Single Forwarder Selection (SFS).
Want all PEs to pick the same ingress PE for a stream.  A multicast tree in
a customer's network could have multiple points of entry, and you could end
up with 2 copies of the packet through the backbone and to customer end
systems.  By inspection of BGP routes you can force all PEs to pick a single
ingress PE.  Or if a PE gets a packet from the "wrong" ingress PE then it
won't forward towards the customer.  There's a convergence time issue with
using inspection of BGP routes.  Why both procedures (ensure only send once,
and discard if duplicates)?  Both needed.  Also PIM-BIDIR won't work with
SFS.  A third option is to use S-PMSIs.  Don't have to do SFS as all PEs are
bound to the S-PMSI.  So can get multiple copies in backbone, but don't
forward to multiple customer receivers.  Doesn't work in all cases...

(2) Upstream-assigned PE labels.  A PE label identifies a PE.  These are
upstream-assigned in that the root PE for a multicast tunnel through the
backbone assigns labels that identify itself to other PEs that are tunnel
members.  Have not identified a precise mechanism to distribute them, but
planning to use BGP.  upstream-assigned labels Will be unique per P-tunnel.
We need this so that if P-tunnel is an MP2MP LSP then the egress PEs can
identify the senders in order to do the discard procedure.

When a P tunnel carries PIM-BIDIR then use PE label to identify designated
forwarder.

can use the same mechanism to identify the ASBR for an MP2MP intra-AS
segment of an inter-AS tunnel.

(4) C-Bidir support.  In bidir PIM each root address is associated with an
RP address (RPA).  The RPA is just an address (doesn't need to be a box).
Packets don't just go downstream from root but can go upstream towards root.
At each branch point packets can start going downstream. This is a neat
feature but has costs - e.g. loops that would not exist on unidir trees.
Easy to see that doesn't happen on unidirectional tree.  In Bidir copies
are only bounded by TTL.  Loops can occur on any multiaccess medium (LAN or
MVPN PMSI).  BIDIR PIM handles this with an elaborate DF election procedure
(40 pages of the spec).  In an MVPN context we want one PE to be DF towards
the backbone.

worked example of this.  Issue is that multiaccess link creates a cycle in
the tree. So if the backbone is modelled as multiaccess then can get cycles.
DF election is one way to break the cycle.  Will present other methods. DF
election is regarded by many people as complicated.  Last time I presented
I showed a simple procedure for SFS forcing all PEs to choose same DF (for
same C-RPA).  Issue with that model is that convergence might not be fast
enough to prevent packets looping.  Other alternatives:

i. simple scheme where RPA outsourced to SP.  So each PE sees the RPA as
reachable via the backbone.  So the root is always the backbone and backbone
can't create cycles.  But of course this isn't transparent to existing
customer multicast routing (and they may not wish to outsource the RPA).

ii. don't remove cycles, but prevent packets from traversing cycles.  So the
ingress PE must choose a PE to be the DF and identify it in the P-tunnel
encapsulation.  So when an egress PE receives a packet from a P-tunnel it
only forwards it if it would have picked the same DF as its ingress PE.  So
different DF choices won't cause looping.  Can identify the DF either by
using a PE label as the second label or by sending the packet on the MP2MP
LSP whose root was the selected DF.  When you partition the set of PEs then
the only way to get to the other set of PEs is via the RPA.  That's normal
BIDIR procedure.

Rahul - short update on v3 of the BGP MVPN draft.   Various enhancements
from previous version that are worth mentioning.

1) spec has clarified non-congruent unicast/multicast connectivity (SAFI 129
case).
2) clarified RR processing of next-hop.  RR should set next-hop to self when
re-advertising C-multicast routes (to reduce route churn).  RR must not
modify the next-hop when re-advertising inter-AS autodiscovery routes.
3) clarified that PMSI tunnel attribute is carried in intra/inter-AS AD
routes if, and only if, an I-PMSI is used for the MVPN.

next steps?  Document is stable.  Got assignments for codepoints (thanks to
chairs).  Have at least one implementation.  For next revision we want
extensions to support areas of new work being addressed by architecture doc.

Ron - unintelligible.

Rahul - will give you ETA by next IETF.  We have some areas of new work...

MVPN revisited - Maria Napierala
----------------------------------------------------------------------------

Another draft on MVPN!  Discussing differences between this and other
drafts.  Usually get comments from the same people, so not sure how many
people have read it.

coming from SP area and see it as important not to have to choose a single
forwarder.  This draft addresses the issues with current proposal from Eric
and Rahul, in that I believe we need to support multiple forwarders for the
same (S,G).  There are various drawbacks of single forwarders - e.g. removes
the advantage of IPVPN where different VPNs can have different policies.
Customers can't take advantage of that with single forwarder procedure
(however that is done).

want to point out that for any C-multicast procedure which is used to
exchange customer multicast routes between PEs then aggregation of routes
can't prevent there being multiple inter-PE paths for multicast traffic.
We know from production networks that whatever we do must be transparent to
the customer.  Can't change states created on customer side.  Larger
customers usually have large networks behind the PEs - not just one single
LAN...

draft is about these procedures, but doesn't dictate what protocol is used
to exchange the C-Multicast routes, or to transport the P-tunnels.  All
about discovering groups, when to announce etc.

current experience is that VPN Customers are unhappy with MVPN.  Today have
to explain to customers that single forwarder behaviour will change in
future.  Only way to keep customers interested.  As an SP we are interested
in the service being a success.  We must allow for multiple forwarders so
customers can get benefit of IPVPN and so different egress PEs can join for
the same source and same group.  Today customers are asking SPs to change
the PE loopback address to achieve the desired traffic patterns!  Only way
to achieve what we want is to adopt this draft!

various changes in -01. Also -02 on way (too late for this IETF).

Incorporated comments received privately.  Also edited text to make it
clearer and remove unnecessary text etc.

main change to logic is distinction between co-located and non co-located
source and RP.  We can't change anything in customer sites in terms of the
flow, what states are created, and where the states are created.  So need
the distinction to make that work.  When the source and RP are not
co-located can make simplifications (automatic switch to trigger use of
SPT).  From customer perspective it is transparent whether we switch to SPT
or not. But if source and RP are co-located then customer will imediately
see if we switch.  Very small change to draft - but allows for some
optimisations.  If we make the distinction we can conform to customer SPT
thresholds (e.g. if non-zero - for which customer may have a good reason).
These procedures are described in version 01.  If co-located then can simply
send traffic from all co-located sources on same trees.  New tunnel
announcement route type, based on updated version of BGP draft.  May not
need a separate route, but just that the existing tunnel announcement for
the PMSI has a wild-card for the source address.  Doesn't matter how it is
done, but just a tunnel that aggregates all sources at same site as the RP.

added support for switchback to shared tree.  Need to set signalling up.
Also needed in non co-located case with dual homed receivers (SPT and
shared tree may diverge - and can't assume that join of SPT and RPT go over
the same link).

given all the above we get automatic support of shared trees (didn't have in
the -00 version).  All completely transparent.

Also get support of anycast C-RPs.  Different receivers can join different
RPs based on customer policy etc.

Also added support for C-bidir trees.  Agree that may have to be done in the
more sophisticated case to avoid loops (am assuming single forwarder today).
This can be changed so that it doesn't have any restrictions and has strong
DF election procedure.

procedure for scalability.  C-BIDIR trees ideally could be autodiscovered.
So even if customer uses PIM-SM then if we discover that most receivers are
sources we could use MP2MP tree etc.  need more details to finish this off.

-02 adds S-PMSI auto-discovery route for active muilticast c-groups.  used
in c-bidir as only announce one tunnel per group.  Have a note there as to
how this can be done, but SP wouldn't want to go that way as not scalable.
Also used in co-located C-S and C-RP so don't need to knmow specific
sources.

might be that you have sources sending traffic with no receivers.  if you
only build the tunnel when receivers come you'll have a delay.  So have
unconditional source so you can build the tunnel before receivers come along
(optional if delay is not acceptable for some applications).

support for fast reconvergence with single fowarder if DF-PE fails.  So
pre-build the tunnel from the secondary.

procedure to support C-bidir trees using MP2MP tunnels.

2 slides explaining anycast C-RPs.  Because of procedures in the draft there
could be multiple forwarders.  Allows multiple anycast C-RPs to send traffic
in parallel to different receivers.

By default if there is a tie then the highest IP address wins.  But a VPN
can use different multicast policy for different RPs.  At AT&T we allow
customers to have different routing policies for different VRFs.  One option
is to use SP's IGP cost.  so customer may be willing to use that as it is
generally based on distance.  But should be an optional knob.  Not all SPs
have the same IGP design!  Or some SPs may not want to expose IGP cost to
customers...

support for C-BIDIR.  have simple DF-PE election right now (highest IP
address).  As Eric mentioned is not ideal, but could be made more complete,
so then the procedure for announcing the tunnel is that is done when get a
(C-*, C-G) join.

tunnel announcement via S-PMSI auto-discovery route (when using BGP to
announce tunnels).

Again have option to announce tunnel if receive unconditional source traffic
even though there are no active members.  (PE announces the group C-G to
DF-PE when it gets unconditional source traffic).

next step is to adopt as WG doc and to get comments on the list.  As an SP
we're anxious to be able to explain to customers that what we have today
will change.  Also need to add tunnel aggregation procedures (need extra
machinery to avoid duplicates), and support of C-BSR and C-Auto-RP.

Yakov - same comment I made in private.  Useful to have another iteration
that reflects most recent changes to architecture and BGP procedures doc.
Then can see what's missing if anything and decide whether to adopt this as
a WG doc.

Maria - only prob I have with that is current drafts are just signalling
procedures (using BGP).  Arch draft still does not address the single
forwarder problem.

Yakov - yes it does.  It explains clearly that you don't have to have single
forwarder.

Maria - I have to check.

Yakov - that's why I suggest you look at latest doc, see what's missing (if
anything), and see if we need a new doc or to change existing procedure.

Rahul - yakov said what I want to say.  But please tell us what is missing
in the latest docs and we'll fix it.

Maria - I'm not sure of exact procedures for multiple forwarders.

Rahul - it's in the document.

Maria - is this in response to what I presented before?  Not sure of
process.

Eric - there are lots of things in this doc.  Deployment scenarios are
worth putting in a separate doc.  Other things are criticisms of the WG
docs.  Need to be clear precisely what those areas of disagreements are.  If
you have issues with WG doc you can't solve that by writing a new doc.  Need
to persuade people to change the existing doc.  Don't see why we'd make this
a WG doc.  More of a basis for discussion.

Ron (chair hat off).  Can I recommend you get together with WG doc authors
and see what is there, what isn't, what needs to be augmented, and what
might
need to be kept in a separate doc. Actually am saying that as WG chair.

Maria - I know for a fact that because my 00 draft came before current docs,
that I don't know if they're responding to my criticism or is something
independent.  would help me to see if are going in same direction.
Originally the architecture doc had one forwarder.

Rahul - lots of mis-communication here.  I've spoken to you before, as have
others who know MVPN well.  You think there's functionality missing.  That's
not correct. once we have bridged the mis-communication then we can see what
is missing.

Maria - I want to see how doc supports multiple C-RPs.

Rick - we've stated intention to last-call Eric/Rahul's docs around next
IETF.  So  at that time can see what from Maria's doc needs to be
addressed...
Does that schedule work?

Rahul - I'm happy to talk to Maria after this and see what's missing.

Mark - there are three people here who just need to get in the same room and
hash all this out.  Then come back and say what was agreed upon.  If that
doesn't happen at this IETF am sure that as you don't live that far apart
from each other you can do it before the next IETF.

MPLS over L3VPN Kenji (with Raymond, Nabil)
----------------------------------------------------------------------------

motivation is to provide robust MPLS services to customers.  Today we can do
end-to-end paths from CE to CE using LDP, but not using RSVP-TE.  We want
RSVP-TE so can guarantee bandwidth and provide fast protection etc.  aim is
for all benefits of L3VPN (VRF per customer for security - can't forward
through SP's instance and can't join SP's routing/signalling domain - and
unique address space per VPN).

The important thing here is that most SPs deploy L3VPN, not L1VPN.  So don't
see L1VPN as a solution...

So aim here is to clarify issues for TE over IPVPN and models, scenarios,
requirements.

Reference model - C-TE LSPs established from C router to C router.  P-TE
LSPs from PE to PE.

3 scenarios (needed for NGN services).

since last version we added Nabil as co-author, clarified the problem
statement etc.

now want to become WG doc.

Rick - questions?  Not seeing any.  So will continue to look at adding this
to charter. can't be WG doc unless added to charter.

Support of RSVP in L3VPN (Bruce)
----------------------------------------------------------------------------

this draft may or may not be in this WG as also relates to TSV.

so issue is customer of L3VPN wants to do admission control including on the
CE to PE links.  Won't work out of box, and will explain why.

2 main issues:

1) need to associate RSVP messages at PE with correct VRF context (not as
easy as it appears)
2) path messages in RSVP are sent with router alert option - and need to get
that to work.

focus here is admission control, not TE.  And primary focus is CE-PE links.
Also may wish to do in backbone, but is separable problem.  Main challenge
is to aggregate in backbone as don't want per-customer state in backbone.

diagram of how this is supposed to work.  So path messages from sender to
receiver and resv from receiver to sender.  Resv must follow reverse path.
Path messages are there to leave "breadcrumbs" for the resvs to follow.
Assuming here that the paths and resvs won't be seen by core routers in SP
network.

proposed a solution in the draft.  Been discussing other possible mechanisms
with Yakov today.  Two new objects designed to identify which VRF you should
be processing the paths and resvs in.  these will only appear inside the
provider's backbone (so transparent to customer).

one idea in the proposal is that the path messages rather than using router
alert can be sent directly to the egress PE with that PE's destination
address.  Simplifies the data plane operation since don't have to worry
about looking for router alert inside a packet which is wrapped in MPLS
headers.

For admission control in the backbone is very similar to RFC4804. So doing
admission control over a tunnel as if it was a link.

looking at details.  Path message intercepted by ingress PE (because of
router alert).  RSVP code looks at it.  Figures out what MPLS labels would
be used if being sent as data and puts that in the RSVP message. Also
figures out the VRF and puts a handle to that in the message and sends to
the egress PE.  No need for router alert as sending to egress.  egress PE
looks at the packet and gets VPN label and "real" IP address (can look up
label and IP address - if needed - to identify the egress VRF and store that
with path state)..  Forwards to the CE with router alert.  When resv
received find the VRF and find the path state to send towards the ingress
PE.  At ingress PE you know the VRF (from the handle in the msg) and can use
that to get path state, do admission control for the backbone (if needed)
and send to the ingress CE.

showing new objects for VPN label and VRF.

addressing potential Qs (Yakov thought of more)

1) not using MPLS router alert because concerned about data plane support in
existing PEs and wanted the control plane to be consistent with RFC4084.

2) put VRF ID and label in all "forward" messages and VRF ID in all
"reverse" messages (so not just path and resv).

3) option A and C interprovider are easy.  Looking at option B.

4) why do we need the VRF_ID when have existing HOP object in GMPLS.  Issue
is that HOP doesn't appear in all message types so using new object for all
messages.

in summary main goal is admission control on PE-CE links.  In TSV WG have
been doing lots of work on RSVP for admission control.  So people are seeing
more and more scenarios which they want to work.  Hoping this is smallest
possible set of scenarios to make this work whilst solving router alert
issue. Also gives optional admission control over backbone...

Yakov - there is an existing RFC (4208) that solves a superset of this
problem.  It discusses how GMPLS solves this.  So look at 4208 section 7 and
see if anything is missing.  I think it is a superset, so just describe how
to subset.  Also GMPLS UNI is used in L1VPN which is, again, a superset of
this problem.  What you need is not new objects but a description of the
subset you require.

Bruce - doesn't look to me like is fully specified in that RFC.

Yakov - if not then fix in that RFC

Bruce - or elsewhere?

Raymond - so in terms of PE to CE link don't care if is physical or
logical?

Bruce - yes, don't care.

Raymond - is address of egress PE in global space or VRF space?

Bruce - it's known in the SP's network.

Ron (chair hat off) - you said you hadn't thought option B through.
Wouldn't it be impossible to make it work in any scenario where the packet
travels labelled to ASBR?

Bruce - would need to process RSVP at ASBR.  So RSVP wouldn't go from
ingress PE to egress PE but ingress PE to ASBR to ASBR to egress PE, etc.
Is the point you're getting at that if you put a label in the RSVP message
then don't you know what the right label is if it is being swapped at the
ASBR?

Ron - right.

Bruce - want to know if people think this should be done here or in TSV.

Rick - again issue with charter.  current charter says we don't address QoS.
Already called into question by the last draft.  Seems to be that what Bruce
has proposed is pretty specific to L3VPN.  So seems to be appropriate to do
here. so think we need to add QoS to charter...  show of hands in support of
doing this in this WG?  Many hands.  Nobody objecting.  Will allow input on
list.

---

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Mon, 6 Aug 2007 15:46:17 -0400

Ron/ Fellow L3vpn'ers,

I'd be interested in working on the PE-CE auth mechanisms. There are some interest items wrt catching misconfigs and notifications (as Shane mentioned). 

> Sense of room as to whether people are interested.  A few hands.

Regards,

-- 
Aamer Akhter / [email-masked]
Ent & Commercial Systems, cisco Systems

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Monday, August 06, 2007 2:23 PM
> To: [email-masked]
> Subject: Minutes
> 
> Folks,
>