Subject: [pim] WG Last Call - draft-ietf-pim-join-attributes-00

From: Mike McBride <[email-masked]>
Date: Tue, 3 Jan 2006 11:20:04 -0800 (PST)

Today begins a 2 week working group last call for the pim-join-attributes 
draft. January 17th, 2006 will be the final day of the last call. Please 
review this document and send any comments to the list.

http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt

thanks,
mike

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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Jan 2006 14:23:38 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt

Hello;

I read this document and found it to be in general well written and 
suitable for
publishing.  I have one nit, one small question, and one major question.

Major Question : This document seems to be written entirely from the
standpoint of
allowing for attributes for (S,G) joins only.

Since my understanding is that these capabilities are being added for
things like L3VPN, which supports ASM and  BiDir, why shouldn't (*,G)
attributes be supported ?

If, in the opinion of the author's,  (*,G) attributes ARE supported
already, then I don't think that this is clear.

I would urge that (*,G) attributes be supported, and that text be
added to make this point clear.

Minor Question / point

In Section 2.2

    It may be desired to have routers that understand the generic
    attribute format, forward the attributes regardless if they
    understand the TLV's encoded in the attribute not.  For this the
    first bit in the Type field is reserved.  If this bit is set then the
    TLV is forwarded upstream in case the router does not understand that
    type.

Is this forwarding with the  bit set a MUST ? Then specify it so, and
add the following boiler plate :

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 and indicate
requirement levels for compliant PIM-SM implementations.

AND, what if the bit is not set ? Is that a "MUST NOT" forward, or is
that left to the implementor ? I would suggest that this be made
explicit.

Nit : Section 2.3

(Even a router which
    is not the upstream neighbor must be able parse the packet in order
    to do Join suppression or overriding.)

s/able parse/able to parse/

Regards
Marshall Eubanks

---

From: Stig Venaas <[email-masked]>
Date: Wed, 11 Jan 2006 21:25:31 +0100

>attributes be supported ?
I think it is. In that case the source address is the RP address. But it 
might be good to clarify this. I definitely want it to be there for 
(*,G), so bad if some implementors read it differently.

>that left to the implementor ? I would suggest that this be made

Agree

Stig

---

From: Mike McBride <[email-masked]>
Date: Tue, 17 Jan 2006 13:55:21 -0800 (PST)

Thanks for the comments from Bharat, Stig and Marshall. The authors of 
this draft will be directed to clarify the sections in question and add a 
security section to an -01 version. Please send any remaining comments, on 
this draft, as the LC ends today.

thanks,
mike

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jan 2006 08:37:50 +0200 (EET)

Actually, as a more generic point, I'm not sure whether IANA 
registry(ies) should be created (here or in pim-sm-v2-new), as 
apparently PIM specs are going to be extended by other specs.  IANA 
already controls the Hello Options, but it seems we should create a 
registry for some other numbers in the PIM spec as well?

On Tue, 17 Jan 2006, Mike McBride wrote:
> Thanks for the comments from Bharat, Stig and Marshall. The authors of this 
> draft will be directed to clarify the sections in question and add a security 
> section to an -01 version. Please send any remaining comments, on this draft, 
> as the LC ends today.

While you're at it, check the other nits as well:

http://tools.ietf.org/wg/pim/draft-ietf-pim-join-attributes/draft-ietf-pim-join-attributes-00.nits.txt

By a quick glance, I found the document a bit lacking in 
descriptiveness (e.g., what does Hello option's "OptionType = XX" 
mean).  I'd also have swapped the order of sections 2 and 3 but it's 
OK as is.

Especially, add IANA considerations section as well for the new TLV 
values.

In what units is the Length field in section 3.1?  Does this include 
only the length of the 'Value' or flags, type and length fields as 
well?

I think you should write the PIM Join packet format instead as 
something like:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |PIM Ver| Type  |   Reserved    |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Source Address (Encoded-Source format)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
     |F|S|  Type     | Length        | Value
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
     |F|S|  Type     | Length        | Value
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....

This is closer to what pim-v2-sm-new describes, doesn't overlap the 
format of the encoded-source format, makes it clearer that Source 
Address field can be longer than 4 bytes, etc.

It's a bit odd that there's no clear "length" anywhere here, but I 
guess you have to use what you have..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 18 Jan 2006 02:54:37 -0500

Hello;

> apparently PIM specs are going to be extended by other specs.  IANA

Do you mean this spec, or by L3VPN add ons or ... ?

In any case, I would support creation of a IANA PIM Resgistry. Who
knows what the future will need ?

Regards
Marshall

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jan 2006 10:59:08 +0200 (EET)

> Do you mean this spec, or by L3VPN add ons or ... ?

I was referring the need shown by this spec.  There are probably 
other, new ones coming.  There currently is an IANA registry for Hello 
options and address families, but that's it.

Btw, later on I realized I was a bit confused in my comment below, 
because the format diagram was meant to show just the new 
Encoded-Source format, not the whole message.  In any case, the 
the comment about source address not necessarily being 4 bytes