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

From: <[email-masked]>
Date: Tue, 4 Feb 2020 16:53:09 +0800 (CST)

Hi chairs, authors,

I read this draft, IMO it can be moved on.

I have some comments on it:

The message format is from "draft-ietf-pim-reserved-bits", right? But I don't see the reference and description of draft-ietf-pim-reserved-bits.

If the optimized message defined in RFC8364 can be used here?

Should the fragment be mentioned here? Though the method is the same with RFC7761.

Anycast RP is mentioned in the draft, but the reference to RFC4610 is missed.

Thanks,

Sandy

原始邮件

发件人：MichaelMcBride <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年01月31日 08:41
主 题 ：[pim] draft-ietf-pim-null-register-packing wglc

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

We are going to start a new wglc for https://www.ietf.org/id/draft-ietf-pim-null-register-packing-04.txt which was updated based upon comments during the first wglc (please see below). Since we received only one comment, and really no one showing wglc support, we are issuing a new wglc.

Sometime over the next two weeks please let the wg know if it’s ready to be sent to the iesg for publication.

thanks,

mike

From: pim <[email-masked]> On Behalf Of Ramakrishnan Chokkanathapuram (ramaksun)
Sent: Tuesday, October 15, 2019 11:37 AM
To: Anish Peter <[email-masked]>; Mike McBride <[email-masked]>
Cc: [email-masked]
Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc

Hello Anish,

Thanks for the comments.. I have my responses inline..

Thanks,

Ramki

From: pim <[email-masked]> on behalf of Anish Peter <[email-masked]>
Date: Wednesday, September 4, 2019 at 7:20 AM
To: Mike McBride <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc

Hi all,

 Read through the draft. Have a few comments. 

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.

       ##Ramki##  Not sure if using LSB or MSB has an advantage here. I am not sure if the pim-reserved-bits mandates such thing.

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. 

##Ramki## It will be good to have a new type. If we overload the same type it could happen that a router receives a message and think its malformed.

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 notask for any kind of specific configurations or features on its peers.##Ramki## PIM Anycast RP is based on configuration. So not sure if this is a problem. 4. Restart / feature disableAn RP/FHR may restart or may have bullking turned on/off. In these scenarios the behavior must be defined.##Ramki## Yes. In such scenarios if an RP is downgraded from a version that was supporting packing to one that doesn’t support it, then RP will not respond to the packed registers. In such cases one could send an unpacked  register to RP to check if the RP supports it or fallback to data register and then discover the RP capability. 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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 5 Feb 2020 22:20:27 -0800

Mike,

I support progress of this draft, I believe it is ready for wglc.

Cheers,
Jeff

> On Jan 30, 2020, at 16:40, Michael McBride <[email-masked]> wrote:
> 
> 
>     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. 
> ##Ramki## PIM Anycast RP is based on configuration. So not sure if this is a problem.
>  
> 4. Restart / feature disable 
> An RP/FHR may restart or may have bullking turned on/off. In these scenarios the behavior must be defined. 
> ##Ramki## Yes. In such scenarios if an RP is downgraded from a version that was supporting packing to one that doesn’t support it, then RP will not respond to the packed registers. In such cases one could send an unpacked  register to RP to check if the RP supports it or fallback to data register and then discover the RP capability.
>  
> Thanks,
> Anish 
>  
>

---

From: Michael McBride <[email-masked]>
Date: Fri, 14 Feb 2020 23:55:46 +0000

Thank you to those who reviewed and commented on the draft. And to those who authored the draft. We have support to move it forward. I’ll now shepherd it through to the iesg.

mike

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Thursday, January 30, 2020 4:40 PM
To: [email-masked]
Subject: [pim] draft-ietf-pim-null-register-packing wglc

We are going to start a new wglc for https://www.ietf.org/id/draft-ietf-pim-null-register-packing-04.txt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-pim-null-register-packing-04.txt&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C5e2a5752769e4ca214a908d7a5e62e03%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637160280361940922&sdata=WzPrhT3GT1Wr9WEHV%2FWmClhpzZScuFfW%2FZXFFcC1NaQ%3D&reserved=0> which was updated based upon comments during the first wglc (please see below). Since we received only one comment, and really no one showing wglc support, we are issuing a new wglc.

thanks,
mike

From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Ramakrishnan Chokkanathapuram (ramaksun)
Sent: Tuesday, October 15, 2019 11:37 AM
To: Anish Peter <[email-masked]<mailto:[email-masked]>>; Mike McBride <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc

Hello Anish,

Thanks,
Ramki

From: pim <[email-masked]<mailto:[email-masked]>> on behalf of Anish Peter <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2019 at 7:20 AM
To: Mike McBride <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc

Hi all,

  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.
       ##Ramki##  Not sure if using LSB or MSB has an advantage here. I am not sure if the pim-reserved-bits mandates such thing.

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

    0                   1                   2                   3

   |                                                               |

   |                                                               |

Register-stop

    0                   1                   2                   3

Thanks,

Anish

On Thu, Aug 29, 2019 at 6:58 AM Mike McBride <[email-masked]<mailto:mmcbride7@gmail..com>> wrote:
PIMers,

thanks,
mike

https://tools.ietf.org/html/draft-ietf-pim-null-register-packing-03<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-pim-null-register-packing-03&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C5e2a5752769e4ca214a908d7a5e62e03%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637160280361940922&sdata=QL%2FAM0Zd7cPDybu5ybsa%2Fs%2BOrEGXCYhW7Rf69NWbLIA%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C5e2a5752769e4ca214a908d7a5e62e03%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637160280361950919&sdata=84iGrqyEdDrlIZZA71YOuGsipv%2BQkB9w%2Fnnt%2F%2F9xd0o%3D&reserved=0>