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. 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. > > > > > > > > > > > > >