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