Subject: mboned: Re: [pim] Simple join failure notification for PIM-SM multicast routing

From: Jerome Durand <[email-masked]>
Date: Thu, 15 Jun 2006 16:30:17 +0200

Hi!

I read your doc, nice contribution indeed. IMHO, we should move forward
this proposal quickly. We agreed in Dallas to have monitoring/management
included in MBoned charter and your doc comes at the perfect time.

Thanks

Jerome

[email-masked] a écrit :
> Hello,
> 
> A new internet-draft is available in the ietf repository :
> 
> http://www.ietf.org/internet-drafts/draft-hoerdt-pim-group-unreachable-00.txt
> 
> Title :
> "Simple join failure notification for PIM-SM multicast routing"
>  
> Abstract:
> 
> "Currently, PIM-SM is the most widely deployed multicast routing
> protocol in the Internet. However in IPv6 this multicast protocol
> lacks a simple connectivity debugging tool, making it difficult to
> identify multicast routing problems.  When a host wants to receive a
> multicast group or channel, if the corresponding  PIM-Join message
> cannot be propagated in the network, nothing exists to inform the
> receiver or the network about this failure. We propose a simple error
> notification message based on ICMP/ICMP6 which is able to indicate
> where and why the error happened in the network without using a
> multicast traceroute mechanism."
> 
> We would like to present this work in the PIM working group at the
> 66th IETF/Montreal PIM. Before that, we would like to get comments and
> engage discussion with the PIM and MBONED working groups in the
> mailing lists.
> 
> thanks,
> 
> Hoerdt Mickael
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

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

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Jun 2006 08:28:10 -0700

Jerome,

Thanks for taking the effort of putting this together. I think that
better in-band management capabilities for multicast are definitely
very important. I personally would have hoped that mtrace would see
more activity because that's my personal favourite, but any activity
is better than none, and your draft certainly points into an important
direction to examine.

Let me summarize some quick thoughts on your proposal:

- As an SSM biggot i obviously have to hate the term "Group Unreachable",
  because "group" is an ASM term. So "State Unreachable" or "Tree unreachable"
  would be more politically correct with me, and i hope we don't have
  politicans or tree-huggers to oppose that on the list. 
  Else "Flow unreachable" or "Join failed". Obviously if we simply
  would ignore PIM-SM alltogether and just care about PIM-SSM (S,G),
  then it would be "channel unreachable" ;-)).
  
- Just saying that this uses ICMP protocol type does not make it independent
  of PIM. Just saying it only interacts with the TIB neither. There is
  no PIM-independent notion of a TIB within the context of the IETF. This
  really needs to be considered as an extension or add-on to PIM and
  for that reason go into the PIM-WG. Likewise the interaction with the
  PIM-state (as well as the PIM-SM specific fields like the R and S bits)
  point to that end. You will also get i think much better review there than
  on mboned. Mboned should rather work on a requirements document for
  troubleshooting tools, and i would like nothing more than a good
  base for requirements to do something like this.

- Which brings me directly to the value proposition. There really needs
  to be first some idea of who and how these messages are used before the
  proposal can sell. It doesn't matter all too much to the protocol
  (rather the requirements side) how such a receiving client would communicate
  with the outside world (MIB OIDs or traps, CLI, XML, foo), but just when 
  and how it could communicate what to the outside world.
  
  For example: I can't figure out whether these unreachable
  messages are periodically repeated as long as the error condition 
  persists (soft state), and/or whether there would be any implied
  timing out of the signalled condition or withdraw messages. Without 
  either of these elements, i can't see how a client could do more than yell
  "Fire" and randomn points in time (aka: whenever receiving such a message),
  but it could never tell you at any point in time whether there still is a
  fire or not, nor would it be able to yell fire when it was asleep at some
  point (aka: if a new router comes up, and the unreachable message was sent
  in before).
  
  Without adding the necessary elements for a client to be able to reliably
  state at any point in time whether a particular multicast flow is
  connected/reachable or not, the value proposition just seems to be to spread
  panic ;-).
  
  Of the clients i listed above, the only one to whom i think the currently
  proposed signaling would make sense (unless i missed something reading
  the document) would be MIB traps, but those could as well be generated 
  on the point of origin directly and would not need to be propagated 
  throughout the network. So: what is the value proposition ?

- If we rather want to have downstream in the trees a reliable indication
  of connection status of trees (which i think would be great), then i
  think we would immediately go back to the problem soft vs. hard-state
  protocol, which is another reason for this to go to PIM-WG were
  i guess we hopefully will have that discussion anyhow.

- Last but not least: If such tree-connectivity/brekage information
  is only signalled for curiosity/offline-alerting reasons, then it
  should obviously take second place to ongoing inline-mitigation, aka:
  reconvergence. That also is of course easier if this is integrated
  into the tree-building (PIM) and can thus appropriately take second
  place. Like ensuring these messages are sent after the more important
  reconvergance join/prunes are sent. 

Cheers
    Toerless

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Fri, 16 Jun 2006 09:07:37 +0200

>   then it would be "channel unreachable" ;-)).
I wont get in this channel/group battle :-))
Tree unreachability would be fine for me
>   base for requirements to do something like this.
Right.
>   point (aka: if a new router comes up, and the unreachable message was sent
I agree this is the hard part. Currently we assume that these messages 
are periodic.
This means that the failed TIB entry  has a timer (could be similar to 
the PIM-join timer).
Instead of sending a join upstream (it cant) it sens a GI downstream.
Note that if the tree is repaired from below the failing point (for 
example the new route from receivers
to source does not go through this node) then the TIB entry will 
desappear since there wont be
joins from downstream.
If the tree is repaired at the failing node, the error condition disappear.
Finally if all receivers quit the tree (for example because the error 
indicate a permanent error)
then the TIB entry disappears also .

Obviously it would be better if the user (or ist network admin) once 
alerted could also
use mtrace

>   connected/reachable or not, the value proposition just seems to be to spread
well if a unicast route breaks and you have an open TCP connexion,
you get  ICMP dest unreach messages ?
>   throughout the network. So: what is the value proposition ?
If you assume that the network admin at the point of failure will jump
to solve the problem you are right. But is it always the case ?
The idea is to get a failure indication closer to the reciever (or its 
network admin)
>   i guess we hopefully will have that discussion anyhow.
I agree
>   reconvergance join/prunes are sent. 
Yes, among possible use of these messages, downstream routers might speed up
recomputing the upstream neighbor for example.

Cheers

Jean-Jacques

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Jun 2006 18:03:55 +0300 (EEST)

> you get  ICMP dest unreach messages ?

Correct, but that ICMP message includes at least the top 20+8 bytes of 
the original packet, so the receiver can demultiplex it to the right 
TCP session, and the TCP session can act on it if it wants to (many 
implementations do, and there are specs out there describing this).

In this case, the ICMP error does not include anything resembling the 
packet that a host or router sent, hence demultiplexing would require 
special ICMP-GU -specific code.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Fri, 16 Jun 2006 17:49:58 +0200

> special ICMP-GU -specific code.
Right, for TCP you can demultiplex on source address, destination 
address and ports (ie socket)
and signal the corresponding socket
In  the multicast  case (assume for exemple SSM) you can demultiplex on 
(S,G) (which is in
the error message) and signal the corresponding UDP socket(s). 
Obviously, this requires some GU specific code
(there is already specific code for TCP, for ICMP reply, ...).
As a first step (before every OS and application can process this :-) we 
can imagine the following
- a receiver (user)  has a problem with a multicast application (ie no 
video stream coming)
- the user (or its network admin) uses a  tool a la ping (let say 
asmping/ssmping)
  using an icmp socket  that can get and decode the GU
then either calls its network admin or close its application or both.

Jean-Jacques