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

Aijun, Hi!

Thanks for giving the draft a read!
Please see inline for responses (prefixed VPB).

Regards,
-Pavan

On Thu, Jul 11, 2019 at 5:24 PM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> 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?
>

[VPB] Yes, the traffic steered into the IP tunnel will have the EAB address
as the destination in the outer IP header.

> How you convince the person that worries about the state preservation
> capabilities associated with the RSVP protocol then?
>

[VPB] I believe you are alluding to scalability concerns that folks tend to
have about RSVP-TE  (let me know if that isn’t what you are asking about).
There are two aspects to RSVP-TE state scalability - control-plane state
and data-plane state. As far as control-plane state scalability is
concerned, we now have techniques such as RI-RSVP and Per-Peer Flow Control
(RFC8370) that allow implementations to support large scale deployments.
There are also “Fast Reroute” specific techniques like RI-RSVP-FRR and
Summary-FRR available now that significantly cut down processing cycles on
the PLR/MP when there is a local failure. All of these techniques are
applicable to the IP RSVP-TE tunnels discussed in this draft. As far as
data-plane state scalability is concerned, please refer to the section on
“Shared Forwarding” (Section 3.7) in this draft.The intent of the proposed
solution is to provides tools that will help seamlessly replicate key MPLS
RSVP-TE features/ functions in native IPv4/v6 networks.

>
>
> 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 <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
> <https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00#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
> <https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00#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
> <https://www.ietf.org/mailman/listinfo/teas>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>