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

From: "Aijun Wang" <[email-masked]>
Date: Thu, 11 Jul 2019 10:52:07 +0800

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? 

  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?

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/

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

---

From: Tarek Saad <[email-masked]>
Date: Thu, 11 Jul 2019 16:14:55 +0000

Hi Aijun,

Thanks for reading and providing your comments on the draft. Please see inline.

From: Teas <[email-masked]> on behalf of Aijun Wang <[email-masked]>
Date: Wednesday, July 10, 2019 at 10:52 PM
To: Tarek Saad <[email-masked]>, 'Vishnu Pavan Beeram' <[email-masked]>
Cc: 'TEAS WG' <[email-masked]>
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

---

From: Aijun Wang <[email-masked]>
Date: Fri, 12 Jul 2019 06:23:34 +0800

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 <[email-masked]> wrote:
> 
> Hi Aijun,
>  
> 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.
> 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?
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 13 Jul 2019 10:23:49 -0500

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 <[email-masked]>
wrote:

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

> *From: *Teas <[email-masked]> on behalf of Aijun Wang <
> [email-masked]>
> *Date: *Wednesday, July 10, 2019 at 10:52 PM
> *To: *Tarek Saad <tsaad@juniper..net <[email-masked]>>, 'Vishnu Pavan
> Beeram' <[email-masked]>
> *Cc: *'TEAS WG' <[email-masked]>
> *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#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.
>
> [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.
>
>
>
> <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.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/, both can
> be the candidate solutions for the scenarios described in
>
> [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
>
> https://www.ietf..org/mailman/listinfo/teas
> <https://www.ietf.org/mailman/listinfo/teas>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 29 Jul 2019 11:19:41 +0800

Hi, Vishnu and Tarek:

I think you should add these explanation in some section such as  “deployment consideration” to convince the persons about the extensibility of RSVP-TE.

One other question, also raised by other person during the IETF 105 presentation, how you consider to accomplish the loose path function in Native IP environment? 

We are seeking some solutions for TE in native IP network.

Currently, we consider using PCE to assist us to accomplish this task (as that described in https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-03).  The merit of this solution is that it can control the underlay network flexibly(strict path or loose path) and also exploit the advantage of traditional IGP/BGP protocol.  One need not worry about the extensibility of these protocols.

Best Regards.

Aijun Wang

发件人: [email-masked] [mailto:[email-masked]] 代表 Vishnu Pavan Beeram
发送时间: 2019年7月13日 23:24
收件人: Aijun Wang
抄送: [email-masked]; Tarek Saad; TEAS WG; Vishnu Pavan Beeram
主题: Re: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

Aijun, Hi!

Regards,

-Pavan

On Thu, Jul 11, 2019 at 5:24 PM Aijun Wang <[email-masked]> wrote:

Hi, Tarek:

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

[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

Hi Aijun,

 

To: Tarek Saad <tsaad@juniper..net <mailto:[email-masked]> >, 'Vishnu Pavan Beeram' <[email-masked]>

Hi, Tarek and Vishnu:

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. 

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

Regards,

Tarek

Best Regards.

Aijun Wang

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf..org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>