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

From: Mike McBride <[email-masked]>
Date: Thu, 30 Nov 2006 14:00:40 -0800 (PST)

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

thanks,
mike

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

---

From: Stig Venaas <[email-masked]>
Date: Thu, 30 Nov 2006 23:16:58 +0000

> 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.

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