Subject: [Roll] [roll] #72: Prefix-color

From: "roll issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 08:19:34 -0000

#72: Prefix-color
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  jpv@…        
     Type:  enhancement         |      Status:  new          
 Priority:  major               |   Milestone:               
Component:  rpl                 |     Version:               
 Severity:  Active WG Document  |    Keywords:               
--------------------------------+-------------------------------------------
 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.
 _____________

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 24 Jul 2010 15:14:10 -0000

#72: Prefix-color
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  jpv@…        
     Type:  enhancement         |       Status:  closed       
 Priority:  major               |    Milestone:               
Component:  rpl                 |      Version:               
 Severity:  Active WG Document  |   Resolution:  fixed        
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Several expressed positive support, one neutral. Here is the proposing
 text:

 Please find the proposed solution for issue 71 to add an opaque tag with
 the RPL route advertisements:

 Changed 6.4.3.  DAO Options to add the Descriptor

    The DAO message MAY carry valid options.

    This specification allows for the DAO message to carry the following
    options:
       0x00 Pad1
       0x01 PadN
       0x05 RPL Target
       0x06 Transit Information
       0x09 RPL Target Descriptor

 Changed  6.7.7.  RPL Target

    A RPL Target Option May optionally be paired with a RPL Target
    Descriptor Option (Section 6.8) that qualifies the target.

    A set of one or more Transit Information options (Section 6.7.8) MAY
    directly follow a set of one or more Target option in a DAO message,
    where each Target Option MAY be paired with a RPL Target Descritor
    Option.  The structure of the DAO message, detailing how Target
    options are used in conjunction with Transit Information options, is
    further described in Section 9.6.

 Added
 RPL Target descriptor

    The RPL Target option MAY be immediately followed by one opaque
    descriptor that qualifies that specific target.

         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 = 9    | Option Length |   Descriptor                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Descriptor (cont.)          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 29: Format of the RPL Target Descriptor Option

    The RPL Target Descriptor Option is used to qualify a target,
    something that is sometimes called tagging.

    There can be at most one descriptor per target.  The descriptor is
    set by the node that injects the target in the RPL network.  It MUST
    be copied but not modified by routers that propagate the target up
    the DODAG in DAO messages.

    Option Type:  0x09 (to be confirmed by IANA)

    Option Length:  6

    Descriptor:  32-bit unsigned integer.  Opaque.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/72#comment:1>
roll <http://tools.ietf.org/wg/roll/>