Subject: Re: [Teas] RSVP TE Scalability - Recommendations

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 1 Apr 2015 07:58:08 -0400

Pavan,

Thanks for the recommendations. They could certainly be addressed by
bringing back RFC 3212 (but note today's date, I deliberately waited six
days to send this email :-).

Cheers,
Andy

On Thu, Mar 26, 2015 at 3:09 PM, Vishnu Pavan Beeram <[email-masked]>
wrote:

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

---

From: Paweł Brzozowski <[email-masked]>
Date: Wed, 1 Apr 2015 12:48:25 +0000

Pavan,

you wrote:

“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).”
I guess this is where our disconnect comes from. You certainly know RFCs better than me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time out. Is it not the case?

Thanks,
Pawel

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Paweł Brzozowski
Cc: [email-masked]
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

Pawel, Hi!
Thanks for the response. Please see inline.
Regards,
-Pavan

On Tue, Mar 31, 2015 at 5:30 PM, Paweł Brzozowski <[email-masked]<mailto:[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]<mailto:[email-masked]>] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: [email-masked]<mailto:[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,

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

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

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 09:50:30 -0400

Andy,

No, We are not bringing back the RFC3209 vs RFC3212 debate :)

Regards,
-Pavan

On Wed, Apr 1, 2015 at 7:58 AM, Andrew G. Malis <[email-masked]> wrote:

> On Thu, Mar 26, 2015 at 3:09 PM, Vishnu Pavan Beeram <
> [email-masked]> wrote:
>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 1 Apr 2015 15:58:38 +0200

Hi all,

two comments regarding the usage of RSVP in GMPLS enabled
transport networks:

In my view, RSVP requires LSP state cleanup in case of RSVP
refresh timeouts (soft state protocol) - you may, however,
suspend

the refresh mechanism in case your signalling communication is
broken while your data plane is working properly.

RSVP-TE scalability may not be an issue in GMPLS enabled
transport networks due to the fact that we have a limited number
of

LSPs per link (corresponding to the number of circuits per link)

Thanks,

Dieter

On 01.04.2015 14:48, Paweł Brzozowski
wrote:

Pavan,

you wrote:

“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).”

I guess this is where our disconnect comes
from. You certainly know RFCs better than me. I assumed that
IETF recommendation for GMPLS running in transport networks
would be NOT to cleanup lsp state when refreshes time out.
Is it not the case?

Thanks,

Pawel

From: Vishnu Pavan Beeram
[mailto:[email-masked]]

To: Paweł Brzozowski

Cc: [email-masked]

Subject: Re: [Teas] RSVP TE Scalability -
Recommendations

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.

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!

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]>
wrote:

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:

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

Teas mailing list

[email-masked]

--

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: Wed, 1 Apr 2015 10:10:07 -0400

Pawel, Hi!

There is no (AFAIK) GMPLS document that recommends NOT cleaning up LSP
state when refresh times out. So, the point that you are making about these
recommendations not being applicable for GMPLS LSPs isn't quite true.

I do understand that there are proprietary implementations out there that
use some additional procedures (after the refresh times out) to make sure
that it is absolutely safe to cleanup the data-plane before cleaning up the
corresponding LSP state. With the new recommendations proposed in
<draft-beeram..>, these implementations should still be able to run similar
procedures after the node-hello times out and then cleanup the state. But
since these are all proprietary mechanisms, this draft will not spell all
this out for you.

Regards,
-Pavan

On Wed, Apr 1, 2015 at 8:48 AM, Paweł Brzozowski <
[email-masked]> wrote:

>  Pavan,
>
>
>
> you wrote:
>
>
>
> *“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).”*
>
> I guess this is where our disconnect comes from. You certainly know RFCs
> better than me. I assumed that IETF recommendation for GMPLS running in
> transport networks would be NOT to cleanup lsp state when refreshes time
> out. Is it not the case?
>
>
>
> Thanks,
>
> Pawel
>
>
>
> *From:* Vishnu Pavan Beeram [mailto:[email-masked]]
> *Sent:* Wednesday, April 01, 2015 12:13 AM
> *To:* Paweł Brzozowski
>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations
>
>
>
> Pawel, Hi!
>
> 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
> 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!
>
> 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]> wrote:
>
> Pavan,
>
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>
>
>
>

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 1 Apr 2015 14:30:58 +0000

Dieter,

Hi all,

two comments regarding the usage of RSVP in GMPLS enabled transport networks:

  1.  In my view, RSVP requires LSP state cleanup in case of RSVP refresh timeouts (soft state protocol) - you may, however, suspend
the refresh mechanism in case your signalling communication is broken while your data plane is working properly.
You can also just push the refresh-interval and miss-count high enough that your timeout is sufficient for network operators to notice and fix the problem. So your soft-state protocol becomes… soft, like rocks are soft :)

  1.  RSVP-TE scalability may not be an issue in GMPLS enabled transport networks due to the fact that we have a limited number of
LSPs per link (corresponding to the number of circuits per link)
True. Pavan’s draft seems to be aimed more at the packet world where supporting hundreds of thousands of LSPs is becoming a requirement, and we’ll doubtless be getting into the millions before we know it. I’m not aware of this being an issue for GMPLS.
Cheers
Matt

Thanks,
Dieter
On 01.04.2015 14:48, Paweł Brzozowski wrote:
Pavan,

you wrote:

Thanks,
Pawel

Pawel, Hi!

You said:

Thanks,
Pawel

Loa, Hi!

/Loa

Folks, Hi!

A few points to note:

Regards,
-Pavan

--

Teas mailing list

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 1 Apr 2015 10:59:33 -0400

Dieter, Hi!

Please see inline..

Regards,
-Pavan

On Wed, Apr 1, 2015 at 9:58 AM, Dieter Beller <
[email-masked]> wrote:

>    1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh
>    timeouts (soft state protocol) - you may, however, suspend
>    the refresh mechanism in case your signalling communication is broken
>    while your data plane is working properly.
>
>
>
>    1. RSVP-TE scalability may not be an issue in GMPLS enabled transport
>    networks due to the fact that we have a limited number of
[VPB] Totally agree that the scaling requirements imposed on MPLS RSVP-TE
LSPs are very different from those imposed on non-psc RSVP-TE LSPs. The
recommendations in this draft were put together to cater to the former set
of requirements (and that would continue to be the primary focus of this
draft). But one of the initial points that was made to us when we came out
with this draft was that most of these recommendations are applicable to
non-psc GMPLS LSPs as well -- and I don't think there is an argument
against that statement (irrespective of whether "Scalability" is a current
concern or not for GMPLS-enabled LSPs).

> *From:* Vishnu Pavan Beeram [mailto:[email-masked]
> <[email-masked]>]
> Teas mailing [email-masked]://www.ietf.org/mailman/listinfo/teas
>
>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 1 Apr 2015 17:46:17 +0200

Hi Matt, all,

On 01.04.2015 16:30, Matt Hartley
(mhartley) wrote:

Dieter,

Hi
all,

In my view, RSVP requires LSP state cleanup in case of
RSVP refresh timeouts (soft state protocol) - you may,
however, suspend

the refresh mechanism in case your signalling
communication is broken while your data plane is working
properly.

You can also
just push the refresh-interval
and miss-count high enough that your
timeout is sufficient for network operators to notice and
fix the problem. So your soft-state protocol becomes…
soft, like rocks are soft :)

this is what we GMPLS folks normally do! Without refresh timeouts
you may end up having orphaned resources which is also bad!

Thanks,

Dieter

RSVP-TE scalability may not be an issue in GMPLS enabled
transport networks due to the fact that we have a limited
number of

LSPs per link (corresponding to the number of circuits per
link)

True. Pavan’s
draft seems to be aimed more at the packet world where
supporting hundreds of thousands of LSPs is becoming a
requirement, and we’ll doubtless be getting into the
millions before we know it. I’m not aware of this being an
issue for GMPLS.

Cheers

Matt

Thanks,

Dieter

Pavan,

you
wrote:

“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).”

I
guess this is where our disconnect comes from. You
certainly know RFCs better than me. I assumed that IETF
recommendation for GMPLS running in transport networks
would be NOT to cleanup lsp state when refreshes time
out. Is it not the case?

Thanks,

Pawel

From:
Vishnu Pavan Beeram [mailto:[email-masked]]

To: Paweł Brzozowski

Cc: [email-masked]

Pawel,
Hi!

Thanks

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.

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]

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]>
wrote:

Pavan,

The MPLS wg did "An Analysis
of Scaling Issues in MPLS-TE
Core Networks"

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:

Folks, Hi!

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)

Teas mailing list

[email-masked]

--

Loa Andersson
email:
[email-masked]

Senior MPLS Expert

[email-masked]

Huawei Technologies
(consultant)     phone:
+46 739 81 21 64

Teas mailing list

[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Apr 2015 20:12:50 +0100

I'm doing this from memory - someone might want to read an RFC.
 
3473 includes processing to enable restart after a control pane communication failure. Fundamental to that is LSP soft state does not time out when the session (hello state) is down. That would probably be section 9.
 
So "it all depends what you mean".
 
Adrian
 
From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 01 April 2015 15:10
To: Paweł Brzozowski
Cc: [email-masked]
Subject: Re: [Teas] RSVP TE Scalability - Recommendations
 
Pawel, Hi!
There is no (AFAIK) GMPLS document that recommends NOT cleaning up LSP state when refresh times out. So, the point that you are making about these recommendations not being applicable for GMPLS LSPs isn't quite true.

I do understand that there are proprietary implementations out there that use some additional procedures (after the refresh times out) to make sure that it is absolutely safe to cleanup the data-plane before cleaning up the corresponding LSP state. With the new recommendations proposed in <draft-beeram..>, these implementations should still be able to run similar procedures after the node-hello times out and then cleanup the state. But since these are all proprietary mechanisms, this draft will not spell all this out for you.
Regards,
-Pavan
 
On Wed, Apr 1, 2015 at 8:48 AM, Paweł Brzozowski <[email-masked]> wrote:
Pavan,
 
you wrote:

Thanks,
Pawel

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

 
You said:

 

 
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!

/Loa

Folks, Hi!

A few points to note:

Regards,
-Pavan

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [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 16:35:05 -0400

Adrian, Hi!

First, a quick clarification on how/if these recommendations impact the
"Graceful Restart" procedures:
- The "LSP state cleanup upon node-hello timeout" recommendation made in
<draft-beeram..> does NOT impact the RSVP-TE graceful restart procedures
defined in ([RFC3473], [RFC5063]).  If the node is not acting as a
"graceful-restart" helper, it would cleanup state immediately upon
node-hello timeout. But if the node is acting as a graceful-restart helper
for a neighboring node, then the "cleanup" action will be executed only
after taking into account the grace period extended for the neighbor by the
helper.

I checked Section 9 of RFC3473 again.  Section 9.3 says the following:

9.3 <https://tools.ietf.org/html/rfc3473#section-9.3>. Modification to
Hello Processing to Support State Recovery   When a node determines
that RSVP communication with a neighbor has
   been lost, and the node previously learned that the neighbor supports
   state recovery, the node SHOULD wait at least the amount of time
   indicated by the Restart Time indicated by the neighbor before
   invoking procedures related to communication loss.  A node MAY wait a
   different amount of time based on local policy or configuration
   information.

Was this the text that you were thinking of? The text in 9.3 is in line
with the clarification that I gave above.

Regards,
-Pavan

On Wed, Apr 1, 2015 at 3:12 PM, Adrian Farrel <[email-masked]> wrote:

> 3473 includes processing to enable restart after a control pane
> communication failure. Fundamental to that is LSP soft state does not time
> out when the session (hello state) is down. That would probably be section
> 9.
>
>
>
> *Sent:* 01 April 2015 15:10
>
> *To:* Paweł Brzozowski
> *Cc:* [email-masked]
> *- Completely eliminate the reliance on refreshes for state sync.-
> Completely eliminate the reliance on refresh timeouts for stale
> statecleanup.- Implement per-peer flow control.”*
>
>
>
> *Principle 2: “Completely eliminate the reliance on refresh timeouts for
> stale state”*
>
>
>

---

From: Dieter Beller <[email-masked]>
Date: Thu, 2 Apr 2015 10:24:35 +0200

Hi Pavan, all,

I agree with you that when a new draft is being developed in TEAS it
should be applicable to all technologies including non-psc GMPLS.

However, if we figure out that an issue is very much technology
specific, we may decide to develop a techno-specific I-D that will
be

done in MPLS for example when it only applies to classical MPLS
(psc).

Another aspect is compatibility of new mechanisms with
implementations based on existing RFCs. So, I would expect a
compatibility

section addressing backward compatibility and seamless introduction
of new mechanisms or extensions into existing networks.

Thanks,

Dieter

On 01.04.2015 16:59, Vishnu Pavan
Beeram wrote:

Dieter, Hi!

Please see inline..

Regards,

-Pavan

On Wed, Apr 1, 2015 at 9:58
AM, Dieter Beller <[email-masked]>
wrote:

Hi all,

two comments regarding the usage of RSVP in
GMPLS enabled transport networks:

In my view, RSVP requires LSP state
cleanup in case of RSVP refresh timeouts
(soft state protocol) - you may, however,
suspend

the refresh mechanism in case your
signalling communication is broken while
your data plane is working properly.

RSVP-TE scalability may not be an issue in
GMPLS enabled transport networks due to the
fact that we have a limited number of

LSPs per link (corresponding to the number
of circuits per link)

[VPB] Totally agree that the scaling
requirements imposed on MPLS RSVP-TE LSPs are very
different from those imposed on non-psc RSVP-TE
LSPs. The recommendations in this draft were put
together to cater to the former set of
requirements (and that would continue to be the
primary focus of this draft). But one of the
initial points that was made to us when we came
out with this draft was that most of these
recommendations are applicable to non-psc GMPLS
LSPs as well -- and I don't think there is an
argument against that statement (irrespective of
whether "Scalability" is a current concern or not
for GMPLS-enabled LSPs).

Thanks,

Dieter

Pavan,

you wrote:

“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).”

I guess this is where
our disconnect comes from. You
certainly know RFCs better than me.
I assumed that IETF recommendation
for GMPLS running in transport
networks would be NOT to cleanup lsp
state when refreshes time out. Is it
not the case?

Thanks,

Pawel

Sent: Wednesday, April 01,
2015 12:13 AM

To: Paweł Brzozowski

Cc: [email-masked]

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

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:
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!

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

wrote:

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:

Folks, Hi!

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)

Teas mailing
list

[email-masked]

--

Loa Andersson

email:

[email-masked]

Senior MPLS
Expert

[email-masked]

Huawei
Technologies
(consultant)
phone:
+46 739 81 21
64