Re: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

Hi, Tarek:
Thanks for your clarification.
Then the traffic will be sent in IPinIP tunnels with the outer address kept the same as the EAB Address along the path?
How you convince the person that worries about the state preservation capabilities associated with the RSVP protocol then?

Aijun Wang
China Telecom

> On Jul 12, 2019, at 00:14, Tarek Saad <tsaad.net@gmail.com> wrote:
> 
> Hi Aijun,
>  
> Thanks for reading and providing your comments on the draft. Please see inline.
>                          
>  
> From: Teas <teas-bounces@ietf.org> on behalf of Aijun Wang <wangaijun@tsinghua.org.cn>
> Date: Wednesday, July 10, 2019 at 10:52 PM
> To: Tarek Saad <tsaad@juniper.net>, 'Vishnu Pavan Beeram' <vbeeram@juniper.net>
> Cc: 'TEAS WG' <teas@ietf.org>
> Subject: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels
>  
> Hi, Tarek and Vishnu:
>  
> I just read your draft https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00, some questions are raised as the following. Would you like to clarify them:
> 1. As described in section-3.5.2, the final path is established hop by hop, with the EAB address is the final destination, and the next-hop address is determined via the EXPLICT_ROUTE object.
>   If so, then this draft proposes to establish one e2e path explicitly via RSVP in Native IP network. The tunnel itself is not related to this draft?
> [TS]: The idea here is to reuse the many constructs that RFC3209 (and others) introduce to achieve the IP TE tunnel – this includes FRR, BW management, make-before-break, e2e path-protection, preemption, etc.,-- so the tunnel (as ingress construct) is surely related.
>  
>   If so, should the title be changed to “IP RSVP-TE: Extensions to RSVP for P2P IP-TE Path” more appropriated?
>  
> 2. The usage of the label proposed in section-3.4 is just for identification of the above P2P IP-TE Path(control plane only)? It will not existed within the forwarding packet(data plane) itself?
> [TS]: No, the EAB address is allocated by the egress node (triggered by RSVP signaling). It is carried in the RESV message on the way back to ingress. Any router that sees the RESV, will process it and program the EAB address in its forwarding – effectively setting up its dataplane for that IP-LSP path.
>  
> If my understanding is correct, I think this draft has the same effect as that proposed in https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/, both can be the candidate solutions for the scenarios described in
> https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/
>  
> [TS]: We have mentioned in the draft that it is possible the ERO to be computed and downloaded by a PCE (using PCEP) to an ingress PE, and for the ingress PE to use that ERO in RSVP signaling to setup the IP RSVP-TE tunnel using the mechanisms defined in the draft. The draft you mentioned (from skimming quickly have to say), seems to be using PCEP as interface to program the RIB on router hops. I’m not sure if it covers many of (exisiing TE feature BW/preemption/protection/etc) aspects I’ve mentioned above as well as being able to establish multiple IP-LSP(s) to same destination and being able to share the dataplane forwarding state among the different IP-LSP(s) as we describe in this draft.
>  
> Regards,
> Tarek
>  
>  
> Best Regards.
>  
> Aijun Wang
> Network R&D and Operation Support Department
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
>  
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas