Re: [pim] wglc draft-ietf-pim-rpf-vector-03
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Mike McBride wrote:
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.

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
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim


_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.