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

Jeff Tantsura <jefftant.ietf@gmail.com> Thu, 06 February 2020 06:20 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292E6120127 for <pim@ietfa.amsl.com>; Wed, 5 Feb 2020 22:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaEUuVZ_DDyd for <pim@ietfa.amsl.com>; Wed, 5 Feb 2020 22:20:32 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E03120100 for <pim@ietf.org>; Wed, 5 Feb 2020 22:20:32 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id z12so2216502pgl.4 for <pim@ietf.org>; Wed, 05 Feb 2020 22:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bnwGNLjOkfYG2vy2P3gbKd91BoW9v/5bd4x8Pg62HvQ=; b=K1U6tkcxa+4cVEXGn1z/pe3W9jV9VfLwobGntUNOK9AlBv4H6iOj8Qu60it3kVq9ky KoLqUsaBNlj0W60Kev61CyOWpTMWK1ssOdDHcgIWDan9TaK3SPtvPUs9VtS7skaEjtMG N/N6xD/B0UtO5TXBE91xwMYwf5aStKagcceB+X3n+M9F3vxMtPrKTccLfIdtJlqeoSfN v7JakhwHqcnKAoGSS7/1nBW10aKzxqFtmhEyaisqYHk01wUfpTA6KeeC3xrG8FPB293E 9bLY/SRAcoPGvExQUUT4hVNS7LG7oXe66e1VZCY47Nds5A8exoShu9gaggv7JnZ6oahk BB/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=bnwGNLjOkfYG2vy2P3gbKd91BoW9v/5bd4x8Pg62HvQ=; b=c9HD5OMRXk3payXiE4bYyMfheq/Av5THUhzNmlwRP0gDSizySFhWdBbnar4cim45tW kZf0cZgAq1rIF0ZqGwcmBibiMtPMgUCAP4pV1PKKJSUK4HhyaTo9iwnXvK5cQMEbPMYK JrEvSKSHZpeMpxum/p+x65zC0ZyoipfutbvScqJvZzeEKajoYclgw01TAIeHn+lErCD+ mXdrZZdmVGKTVv5rH/hW+H4Hau9480BMNoiacpv/9bRH427Q9611bjQ9xokTEv1kpBaD hUDuQ5BayjuTqRKPu5NsQM3XPANiQ+OA77yiBq000XgbPiXzQxjrqvg4HTR6o2AzOIk8 P/fw==
X-Gm-Message-State: APjAAAVISlO1CCGDxOi1MKr2XyaPdlWE9GjxuQ3LPhV4D3cMqrntb3PW jCK0f97bMyf+rBLA1/RSBYpvso6F
X-Google-Smtp-Source: APXvYqwmycCAuE2cdFSsvXVeb35mrP2SmVQ0hIKPUXQnnq1RcVuyLrhk6E26FIvHtwhECY3Dw/96RQ==
X-Received: by 2002:a63:2782:: with SMTP id n124mr1926927pgn.188.1580970031241; Wed, 05 Feb 2020 22:20:31 -0800 (PST)
Received: from ?IPv6:2607:fb90:a433:6671:f056:f5b6:d686:8f16? ([2607:fb90:a433:6671:f056:f5b6:d686:8f16]) by smtp.gmail.com with ESMTPSA id n14sm1773083pgf.79.2020.02.05.22.20.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Feb 2020 22:20:30 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-AC575DC2-03BE-4012-9729-8E1E540130EC
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 5 Feb 2020 22:20:27 -0800
Message-Id: <675472E1-100A-41FA-846E-CE25330CDA71@gmail.com>
References: <BYAPR13MB28077083071D9A073DE6FC7AF4070@BYAPR13MB2807.namprd13.prod.outlook.com>
Cc: "pim@ietf.org" <pim@ietf.org>
In-Reply-To: <BYAPR13MB28077083071D9A073DE6FC7AF4070@BYAPR13MB2807.namprd13.prod.outlook.com>
To: Michael McBride <michael.mcbride@futurewei.com>
X-Mailer: iPad Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/D525Fmu6vvhTtdMW_CkhBgWlSTU>
Subject: Re: [pim] draft-ietf-pim-null-register-packing wglc
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 06:20:35 -0000

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 <michael.mcbride@futurewei.com> wrote:
> 
> 
> 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 <pim-bounces@ietf.org> On Behalf Of Ramakrishnan Chokkanathapuram (ramaksun)
> Sent: Tuesday, October 15, 2019 11:37 AM
> To: Anish Peter <anish.ietf@gmail.com>om>; Mike McBride <mmcbride7@gmail.com>
> Cc: pim@ietf.org
> 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 <pim-bounces@ietf.org> on behalf of Anish Peter <anish.ietf@gmail.com>
> Date: Wednesday, September 4, 2019 at 7:20 AM
> To: Mike McBride <mmcbride7@gmail.com>
> Cc: "pim@ietf.org" <pim@ietf.org>
> 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 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 
>  
>  
> On Thu, Aug 29, 2019 at 6:58 AM Mike McBride <mmcbride7@gmail.com> 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
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim