Subject: [Gen-art] Gen-art review of draft-ietf-pim-join-attributes-03.txt

From: Elwyn Davies <[email-masked]>
Date: Sun, 16 Mar 2008 00:06:16 +0000

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pim-join-attributes-03.txt
Reviewer: Elwyn Davies
Review Date: 15 March 2008
IETF LC End Date: 26 March 2008
IESG Telechat date: (if known) -

Summary:
This document appears to be seriously unready, although, as ever, some 
of the apparent problems may be due to my misunderstandings. From the 
introductory description that totally fails to give a concise summary of 
how address encodings with additional attributes are distinguished and 
what is actually done to the format, through statements in s3.3 that 
would appear to preclude any sort of incremental deployment and an 
ambiguous packet format section, to a seriously incomplete IANA 
considerations, I believe that a good deal of work is needed to fix up 
this document.  Indeed the problems with s3.3 may actually be a show 
stopper.  I am unclear whether there is actually a technical solution to 
the requirement for 'ALL' routers to be able to support the new options 
even if this isn't the entire Internet.  See below for further discussion.

Comments:
s3.1: The terminology is inconsistent with RFC 4601 which uses 
Encode-Source Address rather than source encoded (I assume that is the 
right association). I found this section totally unenlightening about 
the general principles of the new Join attributes.  I spent a good 20 
minutes trying to understand what was going on. The indication that a 
different Encoding Type is what distinguishes this form from the 
'legacy' Encoded-Source format is not made clear - it is ultimately 
buried in the packet format.  Is the WG clear whether this is really a 
different encoding and/or happy that this is an adaptation of the 
meaning of the field?  There is not actually any difference in the way 
the address itself is encoded.

s3.2:  Should clarify whether it is expected that the address should be 
forwarded upstream without the TLV or the whole address discarded.

s3.3:
>
>    We can only send a PIM Join which includes an attribute if ALL
>    routers on the network support the new option.
>
If this really means what it says, then there seems little chance of 
effective (incremental) deployment.  Even if what is actually meant is 
that all routers on the relevant multicast tree have to support the 
extra capability, I am unclear how the originator of such a message gets 
to know how this condition is fulfilled.  This needs some explanation I 
think.  What happens if the original tree that is 'attribute capable' is 
broken due to a failure and the paths reconverge to pass through one or 
more routers that don't support Join attributes?

s3.4: The upshot of the potential need for conflict resolution is AFAICS 
that the definition of any attribute MUST include instructions for 
conflict resolution (even if they state that the attribute is either 
present or not, and if it is received from any source then it is 
propagated to all next hops - or maybe conversely, if not received from 
all sources then should not be propagated).  I think this requirement 
has to be specified.

s3.8.1: The format specifies (on the second line of the picture) 'Source 
Address (Encoded-Source format)'.  Does this mean the *whole* of the 
Encoded-Source format from section 4.9.1 of RFC 4601?  or just the 
source address?  If the former this results in duplicating the first row 
of information.  I understand that a different Encoding Type is needed 
to distinguish this format from the basic 'native encoding'. RFC4601 
fails to define an IANA registry for Encoding Type. What happens if 
there are no attributes on some address?  Should a 'null' attribute be 
defined to carry the 'bottom of stack' bit if there aren't any 
attributes?  If not then probably worth making it explicit that the 
'legacy' encoding should be used if there are no attributes. How is the 
length field encoded (number of octets, 32 bit words, twists in a piece 
of string, etc.) and represented.

s4: The definition and review type for the attribute type registry are 
not defined.  This document effectively updates RFC 4601 by requiring a 
registry for Encoding Types - although it doesn't define this registry.  
One problem with this is that doing this from an informational document 
may not be allowed (I am not sure about this, because it is an effective 
update of RFC 4601 which is standards track).

Editorial:
Abstract: Expand PIM and TLV acronyms.
s1: Expand PIM-SM acronyms. RFC 2119 needs to have a reference.
s3.x/s3.x.x: Capitalization of section titles needs attention.
s3.3, para 2: 'must be able to parse to the packet'?  s/parse to/parse/?
s3.8.1: Prefer octet to byte.
s3.8.1/2: The bit number labels are not aligned over the bit fields on 
the pictures (and in s3.8.2 the decade digits are missing).

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art