[Teas] Preferred Path Routing (PPR) Re: Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

[Toerless Eckert <[e-mail]>]

I think this option might not have been brought up on TEAS in before:
With "Preferred Path Routing" (PPR) we have proposed a solutoin that
signals traffic engineered paths efficiently solely via the IGP, independent
of fowarding plane, hence applicable to IPv4/IPv6/SR-MPLS/SRv6 (or
even L2 switching).

The core thought was to simplify signalling and leverage what we learned
eliminating LDP from the necessary signaling protocol suite with SR,
something customers seem to overall appreciate. But there was no
equivalent mechanism to eliminate RSVP-TE signaling, and with PPR there
is.

Btw: When i started working on RSVP/RSVP-TE i also wanted TE functions
for RSVP-IP, but after having experienced a lot of the perfomance /
complexity issues, i think its a good idea to consider a more forward
looking alternative.

Wrt to loose hop forwarding: With PPR, the cost of signaling strict cost
is minimized, so whenever the desired policy better suits strict (e.g.:
no undeisred rerouting on loose segments), PPR should make it most easy.
When the policy is really loose segments, then i think for all signaling
mechanisms (RSVP-TE-IP, PPR or anything else), the same considaration
for the forwarding plane could apply:

Typically you wouldn't want to carry customer payload packets without
encap across the TE domain. Not an issue of TE, just of not wanting
customer addresses in your own network domain.  So you can assume to have a TE-domain
end-to-end encap. You can logically simply do on loose hops an
architectural IP-decap followed by IP-encap. And implementation wise its
at worst a 2 * 128-bit rewrite (Src,Dst-IP-addr). If you are creative
and consider the source-address to be an anycast-address owned by every
loose-hop, and you don't need to steer on the source-address, it's only a
single 128 bit rewrite. So not that difficult. In IPv4 the rewrite would be
shorter, but you also need to incrementally update the checksum, which
may be an issue for simpler forwarding HW (shouldn't be for P4-class
forwardign engine, but might cost more performance).

For PPR, See e.g.: draft-chunduri-lsr-isis-preferred-path-routing,
draft-qct-lsr-ppr-yang, draft-bryant-rtgwg-plfa,
draft-chunduri-idr-bgp-ls-ppr-ext, draft-ce-lsr-ppr-graph,
draft-cls-ppr-te-attributes, ...

Cheers
    Toerless

On Thu, Jul 11, 2019 at 04:14:55PM +0000, Tarek Saad wrote:
> Hi Aijun,
> 
> Thanks for reading and providing your comments on the draft. Please see inline.
> 
> 
> From: Teas <[e-mail]> on behalf of Aijun Wang <[e-mail]>
> Date: Wednesday, July 10, 2019 at 10:52 PM
> To: Tarek Saad <[e-mail]>, 'Vishnu Pavan Beeram' <[e-mail]>
> Cc: 'TEAS WG' <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas


-- 
---
[e-mail]