Hello Lou, > > > > We think you are correct about the Path message. > > But Resv messages are different. The Resv messages are sent hop- > > by-hop. The destination is not the remote PE but the unicast > > address of a previous RSVP hop when a PE send out a Resv message. > > > > Therefor, there will be no VPN label and the remote PE will > > have no method to identify the VPN context/VRF. > > > > I'd expect it to be represented in the HOP object. Sorry for misleading. Scenario 1: (Our main scenario) RSVP-TE control messages are used to create LSP between CE and CE including PE-to-PE(multi hops) part. We do not see PE-to-PE part as one hop. Our Path and Resv messages, both of them do not have VPN labels because we want to reserve network resources hop-by-hop between PEs. Scenario 2: View PE-to-PE as one hop and adds VPN labels to both Path and Resv messages. In this case, as in your email hierarchy-based solutions is also effective. But our main target is Scenario 1. We think it is necessary to also reserve network resources between PEs. Best Regards, Peng JIANG KDDI > Peng, > Thanks for the quick response! Please see in line below. > > On 10/22/2012 9:39 PM, Peng JIANG wrote: > > Hello Lou, > > > >>> As to the technical details, the next hop as identified by the Path > >>> message in the VPN context, will have a route and associated label > >>> within the VPN context. This VPN label can be added to the Path > >>> message, just as it would be for any VPN IP packet, and additional > >>> labels may be added for PE-PE transport. In implementations that > >>> rewrite the IP header, the IP destination can be set to the next > >>> hop. The remote PE/next hop will receive the Path message with the > >>> VPN label which will identify the VPN context/VRF. This PE will then > >>> need to identify the packet as RSVP using either the router alert > >>> mechanism or based on the IP header destination address. So I see no > >>> reason for the modifications when the VAN-specific MPLS labels are > >>> used. > >>> > >>> Shout if you think I missed something. > > > > We think you are correct about the Path message. > > But Resv messages are different. The Resv messages are sent hop- > > by-hop. The destination is not the remote PE but the unicast > > address of a previous RSVP hop when a PE send out a Resv message. > > > > Therefor, there will be no VPN label and the remote PE will > > have no method to identify the VPN context/VRF. > > > > I'd expect it to be represented in the HOP object. > > Lou > > > In RFC 2205: > > 3.1.3 Path Messages > > A Path message travels from a sender to receiver(s) along the > > same path(s) used by the data packets. The IP source address of > > a Path message must be an address of the sender it describes, > > while the destination address must be the DestAddress for the > > session. > > 3.1.4 Resv Messages > > Resv messages carry reservation requests hop-by-hop from > > receivers to senders, along the reverse paths of data flows for > > the session. The IP destination address of a Resv message is the > > unicast address of a previous-hop node, obtained from the path > > state. > > > >>> My high-order take away is that it seems to me that this draft runs > >>> counter to hierarchy-based solutions that can solve this problem just > >>> fine without any additional RSVP modifications. I therefore think > >>> this draft should be run through a WG that is willing to reconcile > >>> the approaches (and fully document their uses case supported by > >>> hierarchy). Failing that, I think the draft should have an IESG > >>> applicability note added saying that this is experimental only and > >>> that standard hierarchy should be used to solve the problem in any > >>> operational implementation/network. > > As I have explained, For Resv messages, hierarchy-based > > solutions are not able to identify the VPN context/VRF at a > > remote PE. > > > > Hope the above explaination will make sense to you. > > Please let us konw if you have any further comments. > > > > Thanks. > > > > > > Best Regards, > > Peng JIANG > > KDDI > > > > > >> > >> Hello, > >> I made this comment privately during the LC period. I don't mind > >> sharing it more widely: > >> > >>> My high-order take away is that it seems to me that this draft runs > >>> counter to hierarchy-based solutions that can solve this problem just > >>> fine without any additional RSVP modifications. I therefore think > >>> this draft should be run through a WG that is willing to reconcile > >>> the approaches (and fully document their uses case supported by > >>> hierarchy). Failing that, I think the draft should have an IESG > >>> applicability note added saying that this is experimental only and > >>> that standard hierarchy should be used to solve the problem in any > >>> operational implementation/network. > >>> > >>> As to the technical details, the next hop as identified by the Path > >>> message in the VPN context, will have a route and associated label > >>> within the VPN context. This VPN label can be added to the Path > >>> message, just as it would be for any VPN IP packet, and additional > >>> labels may be added for PE-PE transport. In implementations that > >>> rewrite the IP header, the IP destination can be set to the next > >>> hop. The remote PE/next hop will receive the Path message with the > >>> VPN label which will identify the VPN context/VRF. This PE will then > >>> need to identify the packet as RSVP using either the router alert > >>> mechanism or based on the IP header destination address. So I see no > >>> reason for the modifications when the VAN-specific MPLS labels are > >>> used. > >>> > >>> Shout if you think I missed something. > >> > >> Lou > >> On 9/5/2012 6:43 PM, The IESG wrote: > >>> > >>> The IESG has received a request from an individual submitter to consider > >>> the following document: > >>> - 'Support for RSVP-TE in L3VPNs' > >>> <draft-kumaki-murai-l3vpn-rsvp-te-06.txt> as Experimental RFC > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits > >>> final comments on this action. Please send substantive comments to the > >>> ietf@xxxxxxxx mailing lists by 2012-10-03. Exceptionally, comments may be > >>> sent to iesg@xxxxxxxx instead. In either case, please retain the > >>> beginning of the Subject line to allow automated sorting. > >>> > >>> Abstract > >>> > >>> > >>> IP Virtual Private Networks (VPNs) provide connectivity between sites > >>> across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS > >>> and a single provider edge (PE) node may provide access to multiple > >>> customer sites belonging to different VPNs. > >>> > >>> The VPNs may support a number of customer services including RSVP and > >>> RSVP-TE traffic. This document describes how to support RSVP-TE > >>> between customer sites when a single PE supports multiple VPNs. > >>> > >>> > >>> > >>> > >>> > >>> The file can be obtained via > >>> http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ > >>> > >>> IESG discussion can be tracked via > >>> http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ballot/ > >>> > >>> > >>> No IPR declarations have been submitted directly on this I-D. > >>> > >>> Due to an error by the sponsoring Area Director, the Last Call on > >>> this document (which completed on 3rd September) incorrectly > >>> stated that this draft was intended that it be published as Informational. > >>> The correct intention (as stated in the draft itself) is that it be > >>> published as Experimental. > >>> > >>> This Last Call is to verify community consensus for publication of > >>> this draft as Experimental. > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > > > > >