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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 16 Jul 2015 22:51:13 -0400

Folks, Hi!

A rejigged version of <draft-beeram-mpls-rsvp-te-scaling-01> is now
available (with a new name).
http://datatracker.ietf.org/doc/draft-beeram-teas-rsvp-te-scaling-rec/

We received some very good feedback both on and off the list and we have
tried to incorporate all of that in this new version. Please do go through
it when you find some time and let us know your comments.

Regards,
-Pavan (as a co-author)

On Thu, Apr 2, 2015 at 4:24 AM, Dieter Beller <
[email-masked]> wrote:

>  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:
>>
>>    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
>>    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
>>
>>
>> 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]
>> <[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]> 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!
>>
>> 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:
>>
>>  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
>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> <%2B46%20739%2081%2021%2064>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Teas mailing [email-masked]://www.ietf.org/mailman/listinfo/teas
>>
>>
>
>
> _______________________________________________
> Teas mailing [email-masked]://www.ietf.org/mailman/listinfo/teas
>
>