Subject: Re: Last Call: <draft-kumaki-murai-l3vpn-rsvp-te-06.txt> (Support for RSVP-TE in L3VPNs) to Experimental RFC

From: Lou Berger <[email-masked]>
Date: Mon, 22 Oct 2012 20:40:28 -0400

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Oct 2012 08:59:10 -0400

Peng,
	Thanks for the quick response!  Please see in line below.

On 10/22/2012 9:39 PM, Peng JIANG wrote:
> Hello Lou,
> 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. 
> 
> 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,

---

From: Peng JIANG <[email-masked]>
Date: Tue, 23 Oct 2012 10:39:18 +0900

Hello Lou,

In RFC 2205:
3.1.3 Path Messages

Thanks.

Best Regards,
Peng JIANG
KDDI

---

From: Peng JIANG <[email-masked]>
Date: Wed, 24 Oct 2012 11:57:43 +0900

Hello Lou,

> I'd expect it to be represented in the HOP object.

Sorry for misleading.

Scenario 1: (Our main scenario)
RSVP-TE control messages are used to create LSP between CE and 
CE including PE-to-PE(multi hops) part.

We do not see PE-to-PE part as one hop.

Our Path and Resv messages, both of them do not have VPN labels 
because we want to reserve network resources hop-by-hop between 
PEs.

Scenario 2:
View PE-to-PE as one hop and adds VPN labels to both Path and 
Resv messages. In this case, as in your email hierarchy-based 
solutions is also effective.

But our main target is Scenario 1.
We think it is necessary to also reserve network resources 
between PEs.

Best Regards,
Peng JIANG
KDDI