Subject: [Teas] RSVP TE Scalability - Recommendations

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 26 Mar 2015 15:09:18 -0400

https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in the TEAS
WG session. There wasn't sufficient time to take in questions at the end of
the presentation (apologize for that). So, I'm opening up this thread to
make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let us
know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Mar 2015 14:31:45 -0500

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa

On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:
> <draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in the
> TEAS WG session. There wasn't sufficient time to take in questions at
> the end of the presentation (apologize for that). So, I'm opening up
> this thread to make sure that all those questions get answered.
>
> A few points to note:
>
> Please do give these recommendations some serious consideration and let
> us know your questions/comments.
>
> Regards,
> -Pavan
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 26 Mar 2015 15:55:37 -0400

Loa, Hi!

Thanks for pointing it out.

Yes, not referencing/mentioning RFC 5439 was a mistake and that would be
rectified in the next version. (But I did mention RFC5439 in this morning's
presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval as a
means of reducing the rate of messages that the control-plane has to
process, but also warn about the loss of functionality associated with
doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of
refresh independent RSVP, but also includes recommendations that would make
sure that there is no loss of functionality when a large refresh interval
is used.

Regards,
-Pavan

---

From: Paweł Brzozowski <[email-masked]>
Date: Tue, 31 Mar 2015 21:30:54 +0000

Pavan,

I think this is great work and applies well to the packet networks. Imho the draft should be augmented to reflect to what is the degree of applicability to transport networks.

You said:

“There are 3 underlying principles driving these recommendations:
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.”

In order to achieve these principles you recommend “Implementing coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.” (copied from the draft). Since in the transport network you really shouldn’t do that, I’m interested how you can fulfill above mentioned principles without it. To give an example:

Principle 2: “Completely eliminate the reliance on refresh timeouts for stale state”

In the draft you assume that stale state will be removed thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios involving a reboot of a RSVP speaker while the service is torn down e.g. by PathTear?

Thanks,
Pawel

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

Loa, Hi!
Thanks for pointing it out.
Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)).
Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used.
Regards,
-Pavan

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Pavan,

/Loa

Folks, Hi!

A few points to note:

Regards,
-Pavan

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

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 1 Apr 2015 00:13:19 -0400

Pawel, Hi!

Thanks for the response. Please see inline.

Regards,
-Pavan

On Tue, Mar 31, 2015 at 5:30 PM, Paweł Brzozowski <
[email-masked]> wrote:

>  Pavan,
>
>
>
> I think this is great work and applies well to the packet networks. Imho
> the draft should be augmented to reflect to what is the degree of
> applicability to transport networks.
>

VPB <=> As mentioned earlier, the recommendations in the draft were put
together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the
applicability of these recommendations to non-psc GMPLS LSPs at all in the
initial revision -- we simply didn't care :). But since it was pointed out
to us that most of these recommendations have generic applicability, I
agree that it would be useful to clarify the degree of applicability to
such networks in the next revision of the draft. At a high-level,
everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert
for Paths) and Section 2.6 (there are different ways of checking data-plane
readiness for non psc LSPs) should have generic applicability.

>
> You said:
>
>
>
> *“There are 3 underlying principles driving these recommendations:*
>
>
>
>
> *- Completely eliminate the reliance on refreshes for state sync. -
> Completely eliminate the reliance on refresh timeouts for stale state
> cleanup. - Implement per-peer flow control.”*
>
>
>
> In order to achieve these principles you recommend “*Implementing
> coupling the state of individual LSPs with the state of the corresponding
> RSVP-TE signaling adjacency.*” (copied from the draft). Since in the
> transport network you really shouldn’t do that, I’m interested how you can
> fulfill above mentioned principles without it.
>

VPB<=> If the elements in this transport network of yours are running
standard GMPLS Control-Plane (not some GMPLS based proprietary version),
please elaborate why you can't couple the state of individual LSPs with the
state of the corresponding RSVP-TE signaling adjacency. If an
implementation can cleanup the LSP-state when the refresh times out, then
it should also be able to cleanup the LSP-state when the hello-adjacency
goes down. I understand that there are proprietary implementations that do
not cleanup the LSP-state when the refresh times out -- those proprietary
implementations might need some additional procedures (this draft will not
furnish those).

To give an example:
>
>
> * Principle 2: “Completely eliminate the reliance on refresh timeouts for
> stale state”*
>
>
>
> In the draft you assume that stale state will be removed thanks to: a)
> reliable Tear/Err messages delivery and b) removing of lsp state after
> adjacency loss. Since b) does not work in transport, how can you cover
> scenarios involving a reboot of a RSVP speaker while the service is torn
> down e.g. by PathTear?
>
>
>

VPB <=> Again, please elaborate why you cannot remove LSP after adjacency
loss if you are using standard GMPLS RSVP-TE.

>  Thanks,
>
> Pawel
>
>
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan
> Beeram
> *Sent:* Thursday, March 26, 2015 3:56 PM
> *To:* Loa Andersson
> *Cc:* [email-masked]
> *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations
>
>
>
> Loa, Hi!
>
> Both RFC2961 and RFC5439 do talk about having a large refresh interval as
> a means of reducing the rate of messages that the control-plane has to