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