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
> [email protected] mailing lists by 2012-10-03. Exceptionally, comments may be
> sent to [email protected] 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.
>
>
>
>
>
>
