Layer 1 VPN WG (l1vpn) - Minutes ================================ THURSDAY, November 9, 2006 1300-1500 Afternoon Session I CHAIRS: Hamid Ould-Brahim Tomonori Takeda Adrian Farrel ================================================================ Agenda and admin (Hamid) ================================================================ Hamid - read out the agenda. No bashing. Online at. http://www3.ietf.org/proceedings/06nov/agenda/l1vpn.html ================================================================ WG Status and milestones (Hamid) ================================================================ Draft status draft-ietf-l1vpn-framework-04 Hamid - Expect respin after meeting to close remaining issues. draft-ietf-l1vpn-basic-mode-01 Hamid: Asked authors at the mic what had changed and what was left. mic: Don: Little has changed, Dimtri had a question about procedures for stitching and nesting - still open, but other than that basic mode signaling is stable. Hamid: Invited more comments on this draft. Chairs will review. Tomonori: Basic mode applicability statement is expected to be completed soon. Enhanced mode is at an earlier stage, and will be covered under other agenda items. Hamid: Main missed milestone is MIB modules for basic mode. ================================================================ BGP TE attribute (Don) draft-fedyk-bgp-te-attribute-02.txt ================================================================ Why draft is necessary; to augment TE database to complete its view of PE-CE links. This is needed in order to determine whether CE-CE links can be set up. Several information items are needed; TE metric, switching cap, encoding, max LSP bandwidth, and some capability-specific information. Some further items are optional; SRLG, protection type/cap, admin group (colour). mic: Dimitri: Asked if extension is specific to L1VPN Don: No Dimitri: What common set is required for other VPN environments Hamid: Not necessarily just VPN, could apply to other applications Dimitri: Within the VPN context, is it just PE-CE links or inter-AS Don: both Dimitri: Worries about impact of injecting TE into other applications such as BGP Hamid: Acknowledged concern Lou: Confirm applicability is broader than just VPN? Don: Yes Lou: Wy not integrate this with BGP docs and take forward in IDR? Hamid (as author): Yes, should be taken to IDR. Lou: Why define new ways/semantics for carrying TE information? Don: Are trying to use the ones for GMPLS. Lou: Why not reuse IGP formats? Because it's not BGP? Don: Attributes are spread across two or three documents Lou: A well-accepted way of representing TE links already exists, if a third protocol needs TE, we should use the same format, not a subset. However, it's a defensible position that is not the same information set as BGP. Don: Does this just mean the optional items should be included? Lou: Should include SRLG, should have the same set that is available in other routing protocols. Lou: If you're going to do TE, you should do TE. Think about whether we want this to be a generic thing. Hamid: Okay, there could be other applications, but we are not yet clear on specific applications other than L1VPNs Lou: Suggested get-together with ADs and other WG chairs. Adrian: At last IETF, there was a promise to take this work to IDR. It's impotrant that this work is seen here, but clearly the way it's presented is for generic TE, not just L1. So really this discussion needs to be had across the routing area, soon. This group cannot be seen to be inventing generic TE for BGP. Don: Okay. Dimitri: This should also involve CCAMP. I believe this discussion should happen in the routing area context. Dimitri: If we have BGP capabilities associated with a speaker, would we incorportate these as well? Do we want a unification of TE operations, or of routing operations? At the end of the day this will determine the format that we need to have. Don: Okay - any other comments? Hamid: Invited comments on the list as well. ================================================================ Basic mode discovery using BGP (Hamid) draft-ietf-l1vpn-bgp-auto-discovery-01.txt ================================================================ Described changes from -00 version. Added section 4 to refer to BGP TE attribute Added section 5 on scalability Completed section 5 on security Added section 7 on IANA considerations. Tomonori: Is this I-D close to completion? Hamid: Mostly done, but since we're adding the BGP TE attribute, we should wait for that. ================================================================ Basic mode discovery using OSPF (Lou) draft-ietf-l1vpn-ospf-auto-discovery-01.txt also draft-berger-ospf-rfc2370bis-00.txt ================================================================ The document is pretty stable and fully baked. Covers the TE issues, no technical changes are being considered. Only change was to reference the new OSPF work. In discussions of earlier revs of the document, authors found a hole with propagation of opaque LSAs across areas. This is going on in the OSPF working group. Status of the work in the OSPF WG (Lou asked who here was present at the OSPF WG - only a few). There is no way for OSPF routers to validate AS-scope (type 11) opaque LSAs. The last OSPF WG decided to combine this work and draft-bryskin-ospf-lsa-type11-validation into 2370bis. Lou said it is possible that this might change the nature of opaque LSAs, but he hopes not. Any implementers of opaque LSAs should review the draft and raise any concerns. Lou cited some language from Acee in a MAY, allowing implementations to choose to give priority to base OSPF LSA types over opaque LSAs. No-one is believed to be doing this yet - it's an option for the future. Lou thanked Alex Zinin for suggesting/simplifying methods for simplifying external routes. ASBRs inject the set of ASBRs into other areas, which allows the validation of external routes inter-area. The same mechanism is used for opaque LSAs - flip the bit to masquerade as an ASBR. The only change is on the receive side, whereby if a type 11 LSA is received go validate the originator. mic: Acee: For all other scope LSAs, there is a reachability requirement before information can be used as well. Lou: I'll be floored if it's not there. That would be really surprising. Acce: I'll go check. /mic This function ensures stale information is not used. It's not really likely that CEs will move from one area to another, but the fix is very important for other external information. In the GMPLS or MPLS context, this can be very significant. Lou closed with a request to review the document, and to check that implementations match what is now specified in here. The plan is for Acee to get consensus on the OSPF list to make it an OSPF WG document. mic: Igor: We identified a problem in OSPF, so it is being solved in OSPF. This is a great example of how we should proceed in the BGP TE information case. We should go solve this in IDR. Lou: Agreed Dimitri: Asked about the use of the word masquerade. Lou: Repeated the mechanism whereby non-ASBRs set the bit in order to re-use the ABR mechanism to validate the originator before propagating/using the information. Dimitri: Asked for a further clarification Lou: I believe we said the only time we need to do the masquerade as the ASBR is if we're configured to originate type 11 opaque LSAs. Acee: This draft is correcting an omission. Any router that originates AS-scope LSAs is an ASBR. This isn't right in 2370. Lou: Agree - this isn't a design change, it's just correcting a documentation error. Don: Maybe question to chairs about if we work on OSPF, we should work on IS-IS as well? Lou: In the previous meeting, we raised if there is anyone interested in IS-IS, please write a draft. Acee: Humorous aside about IS-IS and TRILL work. Tomonori: Seems cooked, would be good to have a detailed review. Lou: Authors believe this is done, but good to have a review. ================================================================ Basic mode applicability statement (Tomonori) draft-takeda-l1vpn-applicability-basic-mode-00.txt ================================================================ This is about applicability of existing GMPLS protocols to cover L1VPNs. We split this document into basic/enhanced mode just before this IETF, to allow basic mode to progress. Drafts describes how basic mode solution I-Ds can be used to support L1VPN basic service model. No new protocol extensions are defined or required. Quick summary of options for PE-PE segment control. Explanation of routing adjacency configuration. Discussion of data plane resiliency. CE-CE recovery is not supported by basic mode. Note ongoing discussion of this topic in CCAMP. A significant question is how to protect CE-PE links. This will be addressed by the next version of the draft. Authors believe this should be a WG document. Listed areas for enhancement of document, e.g. more on use cases of nesting, stitching, and shuffling, clean-up, or management considerations. Tomonori: Will be submitted as a WG document. ================================================================ Enhanced mode applicability analysis (Tomonori) draft-takeda-l1vpn-applicability-enhanced-mode-00.txt ================================================================ This is the other part of the split document. Again analyzes GMPLS for applicability to this proble, and identifies areas for protocol enhancement. Quick summary of four sub-models of the enhanced mode. Quick summary of applicability analysis of existing GMPLS protocols and missing holes. mic: Dimitri: We are discussing BGP discovery and support, what is the purpose of putting GVPN on the slide here? Where is the consistency with the work we were just discussing? Hamid: I think Tomonori meant using GVPN to extend membership summary information - we should remove the GVPN string. Dimitri: GVPN is something that was a concept some time ago. Since then we have developed 2547bis, and many other extensions. I want to make sure we're not discussing L1VPN auto-discovery process and then go choose L1VPN. Adrian: No - it's just saying there is some prior art in this area. Hamid: We did the same process for basic mode. /mic This I-D is just a portion of a previous WG document, so authors believe this should be a WG doc. There's plenty of work left to do, though. Note that 'easy to support' does not mean 'good'. It's important to look at the use cases for each sub-model, and discussion of details would be useful. See also draft-li-l1vpn-enhanced-mode-analysis, to be presented later. It's also acceptable to look for other sub-models. see draft-yasukawa-pce-vpn-req, also to be presented later. mic: Dimitri: What do you mean by sub-model? Do we not have enough material without doing more investigation? What is missing? What is the purpose of further investigation? Adrian: It's a passive search, not an active search. If someone arrives with a brilliant sub-model, we won't send them away because we already have four. Dimitri: Do we feel there is something big we're missing? Adrian: This is just an opening. Tomonori: We shouldn't close the door. Tomonori: This will be a WG document. ================================================================ Enhanced mode analysis (Dan) draft-li-l1vpn-enhanced-mode-analysis-00.txt ================================================================ Motivation for this draft is to generate discussion about enhanced mode. Analyses the proposed models with a view to choosing one or more of them. Issues to consider include recovery, dual-homing, inter- domain. Not a complete list. Listed the 'exchanged routing information' items present in each of the virtual topology models in turn. Draft proposes to measure the sub-models against four metrics; topology confidentiality, scalability, reliability, and 'other issues'. Next step is to decide our objectives. Do we just want to clarify applicability of sub-models, or to choose one? If so, what would be our criteria for choosing? More information is required from the WG. Discussion and input from the WG is solicited. We'd like more people to work on this draft. Mic: Tomonori: This is a good start. The client network can be any type, IP, MPLS or GMPLS. Is there any difference in applicability of models depending on the client network? Dan: Yes, they may have different requirements, and a different sub-model might be better depending on C network. Tomonori: That would be a good place to start. Hamid: It would be good to list applicability to these different scenarios explicitly. Hamid: How many people have read this - about 5 hands. Hamid: More people should read this draft and provide comments, for example about realistic deployment scenarios. Loa: Not a comment on the draft, more a comment on Hamid's last statement. Since we have a situation where 5% of the room has read the draft, suggest that in the month before the IETF meeting, the chairs should poll the list saying which drafts are the important ones, so that people can prepare and have a sense of where we're going. ================================================================ PCE VPN (Adrian for Seisho) draft-yasukawa-pce-vpn-req-01.txt ================================================================ VPNs sometimes provide limited visibility, so there may be applicability to providing PCE to provide additional visibility/path compuation. Also, there can be problems if the core network is partitioned, and for example a device is multi-homed and only one PE has the resources to provide it access to the core. This draft presents requirements from VPNs, and presents them as functional requirements that could be addressed by the PCE Communication Protocol. The main requirement is 'identify the VPN', the path computed may depend on the VPN. The 'VPN' part of 'L1VPN' stands for 'VPN'. So anything that is generically applicable to VPNs are of interest here. So this WG should look at the draft to see whether it is applible here, and consider whether a L1VPN-specific applibility statement is necessary, or whether a generic one would do. The generic appliblity statement will be sent round to all VPN WGs, and then worked on in PCE. The VPN WGs will be pinged, but the work will be done in PCE. mic: Tomonori: Next step is to write an applicability statement, so do the protocols stay the same? Adrian: Three protocols to consider: Signaling protocols stay the same. Discovery protocols stay the same, but we may want to pick up the changes for discovering where PCEs are, for example, the location of the core network PCE could be configured or discovered. The PCECP itself may need some extensions for VPNs. Tomonori: So by 'discovery' you mean 'PCE discovery'? Adrian: Yes. ================================================================ GMPLS Reservation Service (Lucy) draft-yong-ccamp-ason-gmpls-autobw-service-00.txt ================================================================ This draft was not presented from CCAMP due to lack of time. It is being presented here for two reasons: It may benefit L1VPN, and many folks in this room are from CCAMP. This draft tries to extend GMPLS to provide bandwidth to customers on-demand, rather than requiring communication from customer to carrier and manual provisioning through the management plane. Several applications/uses of this function are possible. (1) The customer could 'book' bandwidth prior to it being used, in such a way that bandwidth requests can be decoupled from actual bandwidth allocation. (2) Time-based bandwidth service could be offered. Listed high-level requirements from the point of view of the customer and network provider. Detailed some ways that carriers could manage pre-booked resource requirements to either provision necessary resource, or provide 'rain-check' to customers before pre-empting resources. Today, all this function could be provided by management. The aim is to simplify/automate this function by automating it in the management/control planes. Aim is to leverage GMPLS function to allow provision of advanced services. Next step - ask CCAMP people if this is interesting work for CCAMP, if so would like to make this a WG document. mic: David McW: Not an expert, but is author aware of OIF UNI 2.0 bandwidth modification work? Is this related? Adrian: We're just talking about ahead-of-time reservation of bandwidth, not modification of bandwidth in an LSP. Base RSVP-TE can do this. Can you just confirm the OIF only does bandwidth modification at a point, there's no future reservation here? David McW: I'm not an expert on OIF, but I think you're right. Lyndon: No work has been done on OIF on reservation services. The ITU might have done. Julien: How do you expect the future resources? Lucy: Allowing the carrier to book the service ahead allows the carrier to book ahead of time. This gives the carrier time to engineer the network to fulfil the bandwidth requirements. Julien: Do carriers need some sort of reservation system? Lucy: Yes, but it's not necessary to allocate these resources until service time. They can do the planning work. Don: Adrian said there were some things in RSVP-TE for bandwidth modification, but some changes are required for specifying booking ahead of time? Lucy: Yes, but specification of how far ahead is an implementation issue Don: Another aspect for standardization would be database representation. Would this be held in TE databases? Lucy: That's possible, this is for further study. Julien: Will moving the service platform to the network device be viable? People won't want to mix services onto a network box. We have to draw a line. Lucy: We're moving the function into the network, perhaps as a separate components. It could stand-alone, much like a PCE. Julien: There's no reason to distribute a booking service over multiple devices. Lucy: It might be possible to distribute it. Implementation issue. Don O'Connor: Some customers might be unhappy with the rain-check function. Some want a cast-iron SLA guarantee, and if they can't have it then this has no benefit to certain customers. Lucy: Yes this is true. Implementations may Hamid: How is this related to this WG? Lucy: It's possible we could extend this prootocol to support additional services though GMPLS-UNI, then protocol extensions might be required to describe this. Hamid: Need further discussion on the mailing list.