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

["Adrian Farrel" <[e-mail]>]

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.

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.

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.

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.

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.

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