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

["LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>]

Hi Adrian

Please see inline 

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[e-mail]] 
> Envoyé : vendredi 19 août 2005 12:58
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]; Zafar Ali; Bill 
> Fenner; [e-mail]
> 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"
> <[e-mail]>
> To: "Loa Andersson" <[e-mail]>; <[e-mail]>
> Cc: "Bill Fenner" <[e-mail]>
> 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 : [e-mail]
> > [mailto:[e-mail]] De la part de Loa Andersson
> > Envoyé : mardi 16 août 2005 14:18
> > À : [e-mail]
> > 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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mpls
> >
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> 

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