Subject: [Roll] [roll] #114: mcast option number changed

From: "roll issue tracker" <[email-masked]>
Date: Thu, 11 Apr 2013 15:04:32 -0000

#114: mcast option number changed

 From: "Adrian Farrel" <[email-masked]>
 Subject: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle

 It's been brought to my attention that between -02 and -03 the form of the
 IPv6 option number was changed. I've had a quick chat with the chairs, and
 I'm
 jumping in because of the implications for IANA (see below).

 The act bits remain the same (01) indicating that the IPv6 node MUST
 discard the  packet if it doesn't recognize the option type.
 But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit
 nodes can now change the content of the option.

 I have no comment on whether this is a good idea (the WG should decide
 about
 that), but I haven't been able to find a discussion of this change on the
 list.

 Let's sort out first things first.
 - Authors, please explain why the change was made.
 - WG, please wait for the authors to explain, and then
   respond with your opinions.
 - Chairs, please let me know what the consensus is.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-roll-trickle-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  trickle-     |    Version:
  mcast                  |   Keywords:
 Severity:  Submitted    |
  WG Document            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/114>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2013 11:16:48 -0400

{I would prefer that we have this discussion on the thread created by
the ticket, so that this can be tracked.}

Jonathan Hui writes:
>2) 03 Aug 2012
>
>We sent a proposed update to -01 to the ROLL ML.  As mentioned in that
>email, the intent was to provide WG members some additional visibility
>into how we were addressing the announced deficiencies and to prime
>discussion during the ROLL WG meeting.  This draft included the
>following change to the HbH Option Header: 

>   M                   1-bit flag. 0 indicates that the value in
>                       sequence is not the largest sequence number that
>                       was received from the MPL seed.
>
>Unfortunately, this proposed text did not include necessary updates to
>the chg bit. 

This is all well and good, but I don't see how this makes the hop-by-hop
option mutable enroute.

The option flows along a single link.  My understanding is that the
packet is received by mcast forwarders on that link, and a new outer
packet is emitted by each forwarder, along with what is effectively a
new HbH option and outer header.  

The chg bit is supposed to indicate when a packet is transiting a 
normal router and will continue mostly-unchanged, that that option is
mutable by the routers along the way.    
I don't see how this is the case for the HbH option in question.

>5) 14 Jan 2013
>
>In a private email exchange, Joseph Reddy pointed out to me that -02
>had an inconsistency between the 'M' flag and the chg bit.  Ralph Droms
>was included on that mail and he indicated that we could get it
>modified "although the responsible AD may be a little cranky" :)  In
>any case, for whatever reason, we failed to announce the issue on the
>ROLL ML. 

If the issue tracker could be used more, this would be much less of an
issue.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Apr 2013 17:28:46 +0100

> any case, for whatever reason, we failed to announce the issue on the
IMHO, no eidtor should make any change to WG draft until discussed in IETF,
I know it is not a best practice but discussion list is the place to work,
not privately

AB

On Thu, Apr 11, 2013 at 4:16 PM, Michael Richardson
<[email-masked]>wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 11 Apr 2013 18:25:55 +0000

> I don't see how this is the case for the HbH option in question.

MPL Data Messages are generated by MPL Seeds.  The IPv6 Destination Address of the outer header is set to the MPL Domain Address, which serves to scope the dissemination to an MPL Domain.  MPL Forwarders do not generate a new outer IPv6 Header and HbH Option when forwarding MPL Data Messages.

--
Jonathan Hui

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Apr 2013 20:20:21 +0100

On Thu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) <[email-masked]>wrote:

> MPL Data Messages are generated by MPL Seeds.  The IPv6 Destination
> Address of the outer header is set to the MPL Domain Address, which serves
> to scope the dissemination to an MPL Domain.  MPL Forwarders do not
> generate a new outer IPv6 Header and HbH Option when forwarding MPL Data
> Messages.
>

I understand that you agree that no need that forwarders change the option
content. Or you may mean if forwarder changes it, then it MUST be
forwarding-to different domains or destinations' group. Is that right,
please advise,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Apr 2013 20:27:33 +0100

I understand that each domain is forwarded to but the forwarders are same
decisions, not different. If you have change to option-content then you
have complixity I think,

Please note that that is my opinion, not tested,

AB

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2013 16:06:55 -0400

>>>>> "johui" == johui  <Jonathan> writes:

    johui> MPL Data Messages are generated by MPL Seeds.  The IPv6
    johui> Destination Address of the outer header is set to the MPL
    johui> Domain Address, which serves to scope the dissemination to an
    johui> MPL Domain.  MPL Forwarders do not generate a new outer IPv6
    johui> Header and HbH Option when forwarding MPL Data Messages. 

okay.

This seems at odds with the slides that were produced last November.

http://tools.ietf.org/agenda/85/slides/slides-85-roll-5.pdf

Slide 3.  Did I misunderstand our conclusion as to how things work?
Two mechanisms are describe in slide 3: MPL domain multicast,
and Link Local Multicast.  Do we still have two mechanisms, or one?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 11 Apr 2013 21:28:31 +0000

> and Link Local Multicast.  Do we still have two mechanisms, or one?

We only have the MPL Domain mechanism (termed subnet-local in a prior mail).

http://www.ietf.org/mail-archive/web/roll/current/msg07624.html

--
Jonathan Hui

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 11 Apr 2013 21:34:53 +0000

Trickle relies on having a node determine whether or not there is new information.  MPL uses a sequence number to make that determination.

1) A node determines that a neighbor has newer information if that neighbor announces a larger sequence number.

2) A node determines that it has newer information than its neighbor if that neighbor announces a smaller sequence number with the 'M' flag set.  Without the 'M' flag, a neighbor retransmitting an 'older' packet can falsely cause a node to determine that it needs newer information.

--
Jonathan Hui

On Apr 11, 2013, at 12:27 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

I understand that each domain is forwarded to but the forwarders are same decisions, not different. If you have change to option-content then you have complixity I think,

AB

On Thu, Apr 11, 2013 at 8:20 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

I understand that you agree that no need that forwarders change the option content. Or you may mean if forwarder changes it, then it MUST be forwarding-to different domains or destinations' group. Is that right, please advise,

AB

--
Jonathan Hui

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2013 18:49:14 -0400

>> and Link Local Multicast.  Do we still have two mechanisms, or one?

    johui> We only have the MPL Domain mechanism (termed subnet-local in
    johui> a prior mail). 

    johui> http://www.ietf.org/mail-archive/web/roll/current/msg07624.html

okay, this explains things: we decided in January that this was the
case.  I don't think that the ticket got closed properly with that
conclusion.  January was after we asked for the early adoption.