Subject: Re: [pim] wglc draft-ietf-pim-rpf-vector-03

From: Mike McBride <[email-masked]>
Date: Fri, 1 Dec 2006 14:41:03 -0800 (PST)

Stig,

>>  Today begins a two week wglc for draft-ietf-pim-rpf-vector-03. Please
>>  review:
>>  http://www.ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-03.txt
>
> What is the status of the attributes draft? It might have been good to
> review them together... Below I'm also suggesting some changes to the
> attributes draft.

The attributes draft had a wglc earlier this year which resulted in a few 
comments. Those comments were recently addressed in the -03. Since its 
been fairly long since the last wglc, and given your additional comments, 
the authors need to address your points then we'll issue another wglc.

thanks,
mike

> I support this draft, but there are some issues that need to be taken
> care of. There are also some typos.
>
> I think an IANA registry is needed for the attribute types. It
> seems the attribute draft does not specify that.
>
> This draft should in IANA considerations specify that it should be
> given a value from this registry. And also perhaps say TBD instead
> of suggesting 0.
>
> Semi-editorial/serious editorial issues:
>
> The introduction presents the motivation (MPLS...), but perhaps good
> to make it clear that this attribute can be used in general? At least
> my understanding is that it can be more general.
>
> In 2.2:
>
>    The RPF vector does not apply to BSR bootstrap messages.  To allow
>    BSR messages to be forwarded across a core where the RP IP address is
> s/RP/BSR/
>   not routable in the core a solution has the developed in BSR.
> s/the developed in/need to be developed for/
>
> In section 3:
>
> Most of the text is duplicated. Maybe some of the syntax stuff could
> be skipped and point to the attributes draft?
>
>   | F|S| Type      | Length        |   Encoded-Unicast address
>
> Maybe say "Value" instead of Encoded-Unicast address? At least below
> here the text talks about type, length and value. Those should match
> what is in the diagram.
>
> It doesn't really say whether length is just the length of the value
> or the entire TLV. It might be good to point to attribute draft, but
> that doesn't really say clearly what the length is either. I think
> this really must be made clear in attributes draft.
>
>
> Typos:
>
> Missing space
>    done efficiently in the core.This means that the core routers must be
>
>
> Also, some places there is one space after the period, while there are
> two in other places.
>
>   The intermediate core router do their RPF check on the Attribute (IP
> s/router/routers/
>
> In 2.3.1
>   core routers, will forwarding the Join along the Vector (i.e, towards
> s/forwarding/forward/
>
>   Whether an ttribute is actually needed depends on whether the Core
> attribute    ^^^^^^^^^^
>
> In 2.3.3
>
>   advertises reachability to the Vector in it's IGP.  If the assert
>
> s/it's/its/
>
>   interface and will result in a O-list being NULL.  The Vector
> an                             ^^^
> or "the"?
>
> In 3
>
>    Forward Unknown TLV. If this bit is set the TLV is forwarded
>    regardless if the router understands the Type.
> s/if/of whether/ ?
>
> Stig
>
>>
>>  thanks,
>>  mike
>>
>>  _______________________________________________
>>  pim mailing list
>>  [email-masked]
>>  https://www1.ietf.org/mailman/listinfo/pim
>

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim