[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Minutes
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).
> 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.
Regards,
--
Aamer Akhter / aa at cisco.com
Ent & Commercial Systems, cisco Systems
> -----Original Message-----
> From: Ron Bonica [mailto:rbonica at juniper.net]
> Sent: Monday, August 06, 2007 2:23 PM
> To: l3vpn at ietf.org
> Subject: Minutes
>
> 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.