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(_at_)ietf(_dot_)org mailing lists by 2012-10-03. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.