Subject: [Roll] Route-tags - Soliciting WG comments

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 10:09:24 +0200

Dear all,

This is one of the comments that I send last week (ticket 70). We had  
a discussion with the RPL authors yesterday (as pretty much every  
week) to continue our work on the remaining open tickets (making great  
progress). Let me simply explain why "route-tags" may be important to  
have in the core spec. First of all, I'd like to clarify that we are  
not discussing about using tags/labels for forwarding (we will at some  
point !) so I'll start using the terms prefix-color to avoid  
ambiguity. We had the concept of route-color (called route-tags) up to  
revision -7, at which point we revisited the whole DAO format and it  
went away.

Why is it used for ?

Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS),  
that is used to mark a route. For example, this could be used to flag  
important versus less-critical prefix. This has proven to be useful in  
a number of other routing protocols but to give two examples: this can  
be used to prioritize prefix installation during DODAG rebuilt to  
increase the "convergence" time and restore connectivity faster for  
critical prefixes, it could also be used in case of memory overflow to  
preferably keep the important prefix, ...

Complexity ?

Nothing more than an option carried in a DAO message that could look  
like this:

  0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |   Type = 8    |       2       |               
Flags            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

We just need to add one sentence in the Manageability Section.

We could either defer it to another ID or add it now. Personally I am  
leaning toward adding it back, considering how simple it is and the  
benefits this can bring.

Could you let us know whether you think that we should add it to the  
core spec:

1) Yes
2) No.

Thanks.

JP.

---

From: "Navneet Agarwal (navagar)" <[email-masked]>
Date: Fri, 23 Jul 2010 13:42:49 +0530

Hi JP:
Yes for me
 
Would be useful in future.
 
Regards,
Navneet

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
	Sent: Friday, July 23, 2010 1:39 PM
	To: roll WG
	Subject: [Roll] Route-tags - Soliciting WG comments

	Dear all, 

	This is one of the comments that I send last week (ticket 70).
We had a discussion with the RPL authors yesterday (as pretty much every
week) to continue our work on the remaining open tickets (making great
progress). Let me simply explain why "route-tags" may be important to
have in the core spec. First of all, I'd like to clarify that we are not
discussing about using tags/labels for forwarding (we will at some point
!) so I'll start using the terms prefix-color to avoid ambiguity. We had
the concept of route-color (called route-tags) up to revision -7, at
which point we revisited the whole DAO format and it went away.

	Why is it used for ?

	Route-colors is just an x bit flag field (e.g. RPC 5130 for
ISIS), that is used to mark a route. For example, this could be used to
flag important versus less-critical prefix. This has proven to be useful
in a number of other routing protocols but to give two examples: this
can be used to prioritize prefix installation during DODAG rebuilt to
increase the "convergence" time and restore connectivity faster for
critical prefixes, it could also be used in case of memory overflow to
preferably keep the important prefix, ... 

	Complexity ?

	Nothing more than an option carried in a DAO message that could
look like this:

	 0                   1                   2                   3
	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	       |   Type = 8    |       2       |              Flags
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	We could either defer it to another ID or add it now. Personally
I am leaning toward adding it back, considering how simple it is and the
benefits this can bring.

	Could you let us know whether you think that we should add it to
the core spec:

	1) Yes
	2) No.

	Thanks.

	JP.

---

From: Nicolas DEJEAN <[email-masked]>
Date: Fri, 23 Jul 2010 11:25:35 +0200

Hello JP,

you can count one more Yes.

Cheers,

Nicolas.

2010/7/23 JP Vasseur <[email-masked]>:
> Dear all,
> This is one of the comments that I send last week (ticket 70). We had a
> discussion with the RPL authors yesterday (as pretty much every week) to
> continue our work on the remaining open tickets (making great progress). Let
> me simply explain why "route-tags" may be important to have in the core
> spec. First of all, I'd like to clarify that we are not discussing about
> using tags/labels for forwarding (we will at some point !) so I'll start
> using the terms prefix-color to avoid ambiguity. We had the concept of
> route-color (called route-tags) up to revision -7, at which point we
> revisited the whole DAO format and it went away.
> Why is it used for ?
> Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is
> used to mark a route. For example, this could be used to flag important
> versus less-critical prefix. This has proven to be useful in a number of
> other routing protocols but to give two examples: this can be used to
> prioritize prefix installation during DODAG rebuilt to increase the
> "convergence" time and restore connectivity faster for critical prefixes, it
> could also be used in case of memory overflow to preferably keep the
> important prefix, ...
> Complexity ?
> Nothing more than an option carried in a DAO message that could look like
> this:
>
>  0                   1                   2                   3
>        |   Type = 8    |       2       |              Flags            |
> leaning toward adding it back, considering how simple it is and the benefits
> this can bring.
> Could you let us know whether you think that we should add it to the core
> spec:
> 1) Yes
> 2) No.
> Thanks.
> JP.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Jul 2010 11:28:09 +0200

Yes. We can describe that as an opaque metadata. No way we can describe
its application though.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur
Sent: Friday, July 23, 2010 10:09 AM
To: roll WG
Subject: [Roll] Route-tags - Soliciting WG comments

Dear all,

This is one of the comments that I send last week (ticket 70). We had a
discussion with the RPL authors yesterday (as pretty much every week) to
continue our work on the remaining open tickets (making great progress).
Let me simply explain why "route-tags" may be important to have in the
core spec. First of all, I'd like to clarify that we are not discussing
about using tags/labels for forwarding (we will at some point !) so I'll
start using the terms prefix-color to avoid ambiguity. We had the
concept of route-color (called route-tags) up to revision -7, at which
point we revisited the whole DAO format and it went away.

Why is it used for ?

Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that
is used to mark a route. For example, this could be used to flag
important versus less-critical prefix. This has proven to be useful in a
number of other routing protocols but to give two examples: this can be
used to prioritize prefix installation during DODAG rebuilt to increase
the "convergence" time and restore connectivity faster for critical
prefixes, it could also be used in case of memory overflow to preferably
keep the important prefix, ... 

Complexity ?

 0                   1                   2                   3

1) Yes

2) No.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 12:26:46 +0200

On Jul 23, 2010, at 11:28 AM, Pascal Thubert (pthubert) wrote:

>
> Yes. We can describe that as an opaque metadata. No way we can  
> describe its application though.

Absolutely, so do we for link affinities, ...

Thanks for the feed-back.

JP.

>
> Pascal
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of JP Vasseur
> This is one of the comments that I send last week (ticket 70). We  
> had a discussion with the RPL authors yesterday (as pretty much  
> every week) to continue our work on the remaining open tickets  
> (making great progress). Let me simply explain why "route-tags" may  
> be important to have in the core spec. First of all, I'd like to  
> clarify that we are not discussing about using tags/labels for  
> forwarding (we will at some point !) so I'll start using the terms  
> prefix-color to avoid ambiguity. We had the concept of route-color  
> (called route-tags) up to revision -7, at which point we revisited  
> the whole DAO format and it went away.
>
> Why is it used for ?
>
> that is used to mark a route. For example, this could be used to  
> flag important versus less-critical prefix. This has proven to be  
> useful in a number of other routing protocols but to give two  
> examples: this can be used to prioritize prefix installation during  
> DODAG rebuilt to increase the "convergence" time and restore  
> connectivity faster for critical prefixes, it could also be used in  
> case of memory overflow to preferably keep the important prefix, ...
>
> Complexity ?
>
> We could either defer it to another ID or add it now. Personally I  
> am leaning toward adding it back, considering how simple it is and  
> the benefits this can bring.
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2010 15:04:45 -0400

>>>>> "JP" == JP Vasseur <[email-masked]> writes:
    JP> This is one of the comments that I send last week (ticket
    JP> 70). We had a discussion with the RPL authors yesterday (as
    JP> pretty much every week) to continue our work on the remaining

I believe that this feature may be very useful to some, but not to all.
As such, I think it is a very good example of what should be the first
extension draft.  It can be 3-4 pages long (80% boilerplate), and serve
an example of how to do an extension.

There are some clear advantages to doing this now: for instance it may
motivate clarification of text on what one does with an option that one
does not understand. (I haven't read that part of rpl-10 yet)

Options might be:
  ignore the option     
  copy the unknown option downstream
  drop the entire packet

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 21:49:07 +0200

Hi Michael,

On Jul 23, 2010, at 9:04 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

The point is also that having a number of short RFCs makes the overall
picture hard to get. Again we are talking about a field flag, that's  
all.

> does not understand. (I haven't read that part of rpl-10 yet)

This is actually clearly stated (since you're right saying that such  
text is required):

    When processing a RPL message containing an option for which the
    Option Type value is not recognized by the receiver, the receiver
    MUST silently ignore the unrecognized option and continue to process
    the following option, correctly handling any remaining options in  
the
    message.

Thanks for your feed-back.

JP.

>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE 
> >
> 	               then sign the petition.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBTEnnyYCLcPvd0N1lAQLj6wf+LkEjgWdXeO00oZmixbbsloLsALUh1KbI
> 3MPa4yc/Llm26dSZiti3Pt9fmaYAkYYd/NlarfQzAC1o9fe6CiCdIycv/PIMjG9l
> RPm1gYb5VT6WCoEyktXZMzegTNNW+usrnFUxbODAOqssf2RIPaTMaz8Ry6lfwzOd
> hIrzIakmvVBcL8ifXv0nGYuWf1Wr7DGzLmFVZqi78h+ExL3mxeTqQO6TS/aS7g83
> AfiGn+qSANHxuINnv68MhLi/sb9Xv1JsP87rs1XuUcFMpNc9HyYc4L8DfysBP/+5
> 0/e3R+9QxS9T/gyq1nuH6Rq9u9Wec2Ducn8qwVkS77M1ezyX/i7MBw==
> =WqnL
> -----END PGP SIGNATURE-----

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 09:46:21 +0200

I support 1).
This doesn't add complexity now and I trust it will prove useful later.

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de JP Vasseur
Envoyé : vendredi 23 juillet 2010 10:09
À : roll WG
Objet : [Roll] Route-tags - Soliciting WG comments

Dear all, 

This is one of the comments that I send last week (ticket 70). We had a discussion with the RPL authors yesterday (as pretty much every week) to continue our work on the remaining open tickets (making great progress). Let me simply explain why "route-tags" may be important to have in the core spec. First of all, I'd like to clarify that we are not discussing about using tags/labels for forwarding (we will at some point !) so I'll start using the terms prefix-color to avoid ambiguity. We had the concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away.

Why is it used for ?

Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. For example, this could be used to flag important versus less-critical prefix. This has proven to be useful in a number of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, it could also be used in case of memory overflow to preferably keep the important prefix, ... 

Complexity ?

Nothing more than an option carried in a DAO message that could look like this:

 0                   1                   2                   3

We could either defer it to another ID or add it now. Personally I am leaning toward adding it back, considering how simple it is and the benefits this can bring.

Could you let us know whether you think that we should add it to the core spec:

1) Yes
2) No.

Thanks.

JP.

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 26 Jul 2010 11:30:25 +0300

My only concern with this approach is that other “prf” fields were no more
than 2/3 bits long, and defined a preference value (with upper and lower
limits for comparison), the below approach is based on flags and much more
than 2/3 bits.

>From my understanding of the below explanation, it seems to me as if the
purpose of the below text and the “prf” fields are the same
(prioritization). Flags is more flexible than value, but also require more
processing.

My questions/concerns:

1.       Can we use the same approach in all places (prf) – due to the fact
that this can lead to simpler (common) coding for processing of the
prioritization fields?

2.       Is the proposed length acceptable and commonly used (seems much
more than in other places)?

I’m not familiar with this concept – so I apologize in advance in case I am
missing the point completely and the purpose of this option is different
than the “Prf” fields in other places.

Regards,

Yoav

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *
[email-masked]
*Sent:* Monday, July 26, 2010 10:46 AM
*To:* [email-masked]
*Subject:* Re: [Roll] Route-tags - Soliciting WG comments

I support 1).

Dominique

 ------------------------------

*De :* [email-masked] [mailto:[email-masked]] *De la
part de*JP Vasseur
*Envoyé :* vendredi 23 juillet 2010 10:09
*À :* roll WG
*Objet :* [Roll] Route-tags - Soliciting WG comments

Dear all,

*Why is it used for ?*

*Complexity ?*

 0                   1                   2                   3

       |   Type = 8    |       2       |              Flags            |

1) Yes

2) No.

Thanks.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2010 04:54:47 -0400

>> I believe that this feature may be very useful to some, but not
    >> to all.  As such, I think it is a very good example of what
    >> should be the first extension draft.  It can be 3-4 pages long
    >> (80% boilerplate), and serve an example of how to do an
    >> extension.

    JP> The point is also that having a number of short RFCs makes the
    JP> overall picture hard to get. Again we are talking about a field
    JP> flag, that's all.

I agree, it's really simple.
If it not relevant to everyone, then it belongs in another draft.

If you go through with this in the main draft, it is going to be very
hard to turn down other things which are also "field flags".  

--

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 26 Jul 2010 13:28:29 +0300

After some clarifications from JP (thanks for that), I also agree with
option 1.

Best regards,

Yoav

*From:* Yoav Ben-Yehezkel [mailto:[email-masked]]
*Sent:* Monday, July 26, 2010 11:30 AM
*To:* [email-masked]'; [email-masked]'
*Subject:* RE: [Roll] Route-tags - Soliciting WG comments

My questions/concerns:

Regards,

Yoav

I support 1).

Dominique

Dear all,

*Why is it used for ?*

*Complexity ?*

 0                   1                   2                   3

       |   Type = 8    |       2       |              Flags            |

1) Yes

2) No.

Thanks.

JP.