Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument?

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 29 Aug 2005 08:52:56 +0200

Hi Adrian

Please see inline 

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : vendredi 19 août 2005 12:58
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]; Zafar Ali; Bill 
> Fenner; [email-masked]
> Objet : Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt 
> forworkingdocument?
> 
> Hi J-L,
> 
> Thanks for you support for this draft.
> 
> I would like to pursue the scaling issue with you in more 
> detail since it is something that has worried us as authors.
> 
> The problem is essentially the stress that is placed on the 
> root (and the network near the root) if one pings the entire 
> tree and receives responses from all of the leaves.
> 
> The first point to note is, of course, that this only becomes 
> a problem when the tree is over a certain size. But, yes, we 
> need to be able to handle trees of all sizes.

It depends on what you mean by "a certain size", to my mind without Jitter mechanism we may face issues even with just a few tens of leaves, particularly is leaves are at the same distance from the root (i.e. simultaneous replies)...

> 
> The jitter mechanism is designed to increase the size of tree 
> that can be handled. And is it fair to say that if the root 
> knows its own limitations and knows the size of the tree, it 
> can set the jitter suitably large according to the size of 
> the tree to mean that it is not swamped.

Yes, and we must be aware that this will have an impact on the delay to diagnose that there is a failure. Note that the jitter may rapidly become quite important:
Let's take 
 R = the number of echo reply messages that can be handle on the root per second
 L = the number of leaves
 J = the jitter
We should have J >= L/R

Let's take L = 1000 and R = 100, we have J >= 10s

> 
> The other mechanism that we supply allows the root to ping an 
> individual leaf. Clearly this mechanism has a scaling problem 
> in the other dimension.
> That is, the root will never be swamped, but it may take 
> forever to ping all of the leaves one at a time.
> 
> Well, to be frank, tough!
> If the root does not have enough horsepower to handle pinging 
> all of the leaves, or to handle receiving responses from all 
> of the leaves, there is not much that can be done.
> 
> Recall that there are three purposes to the tool.
> 1. To discover the topology (or just the leaves) of the tree.
>    This does not need to be a quick process, and setting a 
> large jitter (10s of seconds) is fine.
> 2. To diagnose a fault in delivery to a particular leaf.
>    This has no scaling issues because only a single leaf is pinged.
> 3. To detect faults through periodic polling.
>    I am personally pretty suspicious of this use of ping even 
> in unicast!
>    Nevertheless, if "periodic" is acceptable, then it should 
> be possible either to
>    ping each leaf in turn, or to ping the entire tree with a 
> large jitter.

I agree with you that this would not be the best way to perform fast failure detection.
By the way note that the polling period would have to be higher than the Jitter which may lead to a poor detection delay (e.g. more than 10s)...

> 
> There are two other suggestions that have been made.
> a. Allow the specification of a "group" of leaves that are 
> being pinged.
>    This was in our original I-D, but we dropped it because it 
> put considerable
>    processing overhead on the transit nodes in the traceroute 
> case (it also
>    puts some overhead on the leaves in the ping case, but 
> this is less significant).
>    We have repeatedly asked the WG if we should reintroduce 
> this function,
>    but no-one is interested.
> b. Develop some mechanism whereby ping responses are "aggregated" at
>    branch points and sent back to the root as single report 
> of all of the
>    downstream tree.
>    This is similar to the SRRO mechanism in P2MP RSVP-TE.
>    This is certainly achievable, but the reasons for not even 
> beginning to think
>    about this is that it is a completely new protocol that 
> would not be based
>    on LSP Ping. Recall that the return path in LSP Ping is in 
> the control plane
>    and therefore might not (will not!) flow upstream through 
> the branch nodes.

Yes I also had this kind of procedure is mind. 
In my view the main problem is note to flow upstream through the branch node. You may easily enforce a return path along the reverse tree:
The echo reply could be piggyback in a Resv message :-(
Or you could check RSVP state info when propagating the reply message upstream...
IHMO the main issue would be related to the states to be maintained on branch nodes. Branch nodes would have to wait for all dowstream replies before to forward upstream, and we would fall into the classical timer expiration issue (timer value would have to depend on the distance from the leaves :-(

> 
> Now, as mLDP comes along, some of these assumptions may need 
> to change a bit. That is, the SRRO will not be available and 
> the root must rely on the traceroute option to know the 
> topology of the tree. Further, the root cannot know the 
> addresses of the leaves or even know how many leaves there 
> are before it starts to ping. This makes for a *very* 
> different situation and ping-all and traceroute-all become 
> much more significant. It is our hope that jitter will be 
> enough to resolve the scaling issues even in this case.

Yes, for instance the Jitter may be computed based on the total number of PEs, that is an upper bound of the number of leaves...

Regards

JL

> 
> Note also that in the mLDP case there is some problem with 
> doing traceroute to an individual egress because the state in 
> the network does not know which branch to follow to that 
> egress (unlike in P2MP RSVP-TE).
> Thus, a single-node traceroute in mLDP will generate the same 
> responses as a traceroute-all with the exception of the 
> responses from the leaves themselves.
> 
> We have not started to work on extending the draft for mLDP 
> (we decided to wait until mLDP is a bit more stable!).
> 
> We would welcome any ideas that you have to improve the mechanism.
> 
> Cheers,
> Adrian
> 
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN"
> <[email-masked]>
> To: "Loa Andersson" <[email-masked]>; <[email-masked]>
> Cc: "Bill Fenner" <[email-masked]>
> Sent: Friday, August 19, 2005 9:24 AM
> Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt
> forworkingdocument?
> 
> 
> Hi Loa, all
> 
> Frankly speaking I initially had strong concerns w.r.t the 
> scalability of
> this apporach.
> The reply jitter mechanism addresses some scalability issues, and I
> stongly encourage authors to pursue their effort in improving the
> scalability.
> 
> I support this draft as WG doc.
> 
> Regards,
> 
> JL
> 
> > -----Message d'origine-----
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de Loa Andersson
> > Envoyé : mardi 16 août 2005 14:18
> > À : [email-masked]
> > Cc : Bill Fenner
> > Objet : [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for
> > workingdocument?
> >
> > Working group,
> >
> > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt"
> > there were good support for making a working group document
> > and we seek the input from the working group om the mailing
> > list to decide the consensus. Please send your opinion to the
> > mailing list.
> >
> > Context: It is understood tht more work needs to be done on
> > the LDP aspects of p2mp ping, if this goes into this document
> > or a separate document is an open issue.
> > In Paris it was also pointed out that we need to collect the
> > requirments for p2mp ping, the authors would like to draw
> > attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that
> > intends to fill this need.
> >
> > Loa and George
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mpls
> >
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Aug 2005 14:37:09 +0100

Hi JL,

> It depends on what you mean by "a certain size", to my mind
> without Jitter mechanism we may face issues even with just 
> a few tens of leaves, particularly is leaves are at the same
> distance from the root (i.e. simultaneous replies)...

Yes.
"A certain size" means the size that we can handle without jitter :-)
But anyway, we now have jitter in place.

> Yes, and we must be aware that this will have an impact on
> the delay to diagnose that there is a failure. Note that 
> the jitter may rapidly become quite important:
> Let's take 

Agreed.

I might be surprised to hear that R=100. But perhaps routers don't all have very good CPUs, and (of course) we must share processing with other control plane tasks.

L=1000 seems a realistic long-term number for P2MP MPLS-TE. To quote from the requirements doc...
     It is important to classify the issues of scaling within the
     context of Traffic Engineering. It is anticipated that the initial
     deployments of P2MP TE LSPs will be limited to a maximum of around
     a hundred recipients, but that medium term deployments may increase
     this to several hundred, and that future deployments may require
     significantly larger numbers.
For multicast LDP we will need to do some similar thinking.

Anyway, J >= 10 seconds is a good number to work with.

[SNIP]

As you say...

> By the way note that the polling period would have to 
> be higher than the Jitter which may lead to a poor 
> detection delay (e.g. more than 10s)...

Yes. I think that using LSP Ping as a fast failure detection method has been ruled out by this analysis. but, in any case, I don't think that LSP Ping is recommended as a fast failure detection mechanism even for P2P LSPs.

[SNIP]

>> b. Develop some mechanism whereby ping responses are 
>>    "aggregated" at branch points and sent back to the
>>    root as single report of all of the downstream tree.
>>    This is certainly achievable, but the reasons for not
>>    even beginning to think about this is that it is a 
>>    completely new protocol that would not be based
>>    on LSP Ping. Recall that the return path in LSP Ping
>>    is in the control plane and therefore might not (will
>>    not!) flow upstream through the branch nodes.
>
> In my view the main problem is note to flow upstream through
> the branch node. You may easily enforce a return path along 
> the reverse tree:

Ha, ha! :-)

> reply message upstream...

Hmmm. I don't think the control plane and data plane states should be linked in this way if we can help it. It would certainly open up some interesting issues for the misconnection scenarios, but perhaps it would help to find more problems.

We should do some maths. Consider a mesh where multiple ingresses are pinging P2MP trees. This idea will reduce the load on the ingresses, but how will it increase the load on the core nodes?

> IHMO the main issue would be related to the states to be
> maintained on branch nodes. Branch nodes would have to wait
> for all dowstream replies before to forward upstream, and 
> we would fall into the classical timer expiration issue 
> (timer value would have to depend on the distance from the
> leaves :-(

Right.
And, we still want to send a reply up stream when the timer expires (to say that some of the leaves are present).

> Yes, for instance the Jitter may be computed based on the
> total number of PEs, that is an upper bound of the number
> of leaves...

As I understand the way mLDP is going at the moment, the ingress will not know the number of leaves or the number of PEs involved in the P2MP flow. I guess that the ingress will know an upper bound for both, but this will depend on the network and so will be the same for all mLDP LSPs.

So determining how to set the jitter period may be much harder. One could run traceroute and increase the jitter as the tree is built. From then on, ping can use the jitter that has been determined for the deepest traceroute. And as leaves come and go, the jitter can be updated for future pings.

Thanks,
Adrian