Skip to main content

A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04

Discuss


Yes

(Bill Fenner)
(Ross Callon)

No Objection

(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ron Bonica)
(Russ Housley)
(Ted Hardie)

Note: This ballot was opened for revision 04 and is now closed.

Lars Eggert (was Discuss) No Objection

Comment (2007-02-05)
  - Obsolete Reference: RFC 3667
  - Obsolete Reference: RFC 3668

Has a _ton_ of other idnits, please check with latest version of the tool.

(David Kessens; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2007-02-08)
In section '2. Sub-TLV Additions ':

 The methods for which their use is employed is beyond the scope of 
 this document and left to the implementer and/or operator. 

We are not required to have a complete operational description, but
I do believe that there should be a few example use cases that the
authors envision what this option can be/should be used for.

 An implementation MAY consider only one of the encoded tags, in which 
 case the first encoded tag MUST be considered. 

What is the motivation for this ? I don't see why the first tag is more 

important than the next one. I also wonder why the 'MAY' is useful in the
first place.

Note that section '3. Ordering of Tags' says:
          
 The semantics of the tag order are implementation-dependent.  That 
 is, there is no implied meaning to the ordering of the tags that 
 indicates a certain operation or set of operations need be performed 
 based on the order of the tags.

Why is the following not a 'MUST':

 However, an implementation MAY 
 wish to preserve tag ordering such that an ordered set of tags has 
 meaning to the local policy. 

This seems a recipe for problems for operators with multi-vendor networks 

and I don't see a reason why the spec allows for this flexibility without 

a real benefit.

I don't why a 'SHOULD' is used instead of a 'MUST':

 If an 
 implementation needs to change tag values, for example, at an area 
 boundary, then the TLV(s) SHOULD be copied to the newly generated 
 Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s) 
 MAY change as dictated by the policy action.  In the event that no 
 change is required, the SubTLV(s) SHOULD be copied in order into the 
 new LSP, such that ordering is preserved. 

In section '5. Operations':

 There is no discussion on how compliant and non-compliant routers are  

supposed to interact.

Otherwise, this draft is well written and easy to understand.

(Bill Fenner; former steering group member) Yes

Yes ()

                            

(Ross Callon; former steering group member) (was No Objection) Yes

Yes ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2007-02-02)
I very nearly made this a DISCUSS...

1. The example in Fig 1 is not from the range of example addresses.

2.
 7. IANA Considerations 
         
 
    The authors have chosen "1" as the type code of the 32-bits 
    Administrative Tag Sub-TLV and "2" as the type code of the 64-bits 
    Administrative Tag Sub-TLV. These values must be allocated by IANA.

We normally talk about suggested values, not "must", and does this need
a new registry?

(Chris Newman; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection (2007-02-02)
The security consideration sections seems incredible thin. Aren't there risks with someone tapping this information from within the network. What effect would that have? I think that should be described.

(Mark Townsley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection (2007-02-07)
I think the semantics specified by this draft are incredibly thin
about how tags can be set from BGP extended communities, how tags can
be used, etc.  I think that there are not really sufficient semantics
for a reasonable assurance that two implementation make sufficiently
similar uses of tags that you can use them on the same network.  I
consider that a problem, but there's just enough there that I'm filing
a no-obj.

(Ted Hardie; former steering group member) No Objection

No Objection ()