Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc

From: Anish Peter <[email-masked]>
Date: Wed, 4 Sep 2019 19:49:34 +0530

Hi all,
 Read through the draft. Have a few comments.
1. Section 2: The P bit can be taken as the LSB on the reserved ones. This
would help this get inline with recommendations from
PIM draft-ietf-pim-reserved-bits.
2. Instead of taking two new pim message types, the same pim register and
register stop messages may be used. if this procedure can be followed.
a. RP discovers FHR capable of register bulking from the P bit.
b. When RP responds to this register, it can set set a P bit in R-S
message.
c. Once FHR knows peer has bulking capability it can register packets with
bulking
d. For bulked register messages, RP can respond with bulked R-S messages.
e. Packet format. I suggest overloading existing register and R-S packet
can be done with out using two new packet formats.
Register

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|N|P|                     Reserved2             |  S-g-count  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                     Multicast data packet                     .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Register-stop

    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  |  s-g-count  |P|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Group Address (Encoded-Group format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Anycast RP

In my opinion, anycast RP procedures must be defined. Protocols
typically should not

ask for any kind of specific configurations or features on its peers.

4. Restart / feature disable

An RP/FHR may restart or may have bullking turned on/off. In these
scenarios the behavior must be defined.

Thanks,

Anish

On Thu, Aug 29, 2019 at 6:58 AM Mike McBride <[email-masked]> wrote:

> PIMers,
>
> Today begins a two week wglc for draft-ietf-pim-null-register-packing
> which was presented at 105 and hasn't changed since April. Please give
> it a read (it's a quick read) and provide feedback to this wg with
> support/no support of it's progressing to iesg.
>
> thanks,
> mike
>
> https://tools.ietf.org/html/draft-ietf-pim-null-register-packing-03
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>