From tom.taylor.stds@gmail.com  Tue Sep  4 10:24:35 2012
Return-Path: <tom.taylor.stds@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 D3C5411E80A3; Tue,  4 Sep 2012 10:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level: 
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAjvvTDIyOBd; Tue,  4 Sep 2012 10:24:33 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61611E809A; Tue,  4 Sep 2012 10:24:33 -0700 (PDT)
Received: by iabz21 with SMTP id z21so10593730iab.31 for <multiple recipients>; Tue, 04 Sep 2012 10:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=uInKgck3rHPNGRoCS4vJxra2J+OfJAqw7AxL06kepwk=; b=C/IjW9lbEf+zQ0pGHzerPdDcwfL3B15bztgF9SoFGcc3gaC0yy8RNFeewKlf+jSxKL oRVNjyQ+AoFr+Pm98AV/KfYJaRKsPQDGypjfDCSHm1QdC7qORZCmcrwxiRoOvxJ9d6Pq bS7WwbWngcD8pM6ow3NyLWvwzonVbOpfPYmfGPVLXDv5/lAjno4TM2CTkdSc2vBkO7Py oESImdLmccSEnxvK3ZjbwrTaBrM5woYrBMVs+TZUxFOsBE2iS3qn5VgAsb3nf92QH9W4 TE4XpTwPkaRPX9nUtmCuYwBHF1FLY2fa3YwAzqMIb+IHl1SmJkb385KcsPSGAo35v3Cv uVQA==
Received: by 10.50.194.138 with SMTP id hw10mr14959891igc.60.1346779472876; Tue, 04 Sep 2012 10:24:32 -0700 (PDT)
Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id ce6sm13005034igb.1.2012.09.04.10.24.31 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:24:32 -0700 (PDT)
Message-ID: <5046394E.7090805@gmail.com>
Date: Tue, 04 Sep 2012 13:24:30 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: routing-discussion@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120904-0, 04/09/2012), Outbound message
X-Antivirus-Status: Clean
Cc: pim@ietf.org
Subject: [pim] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Sep 2012 17:24:35 -0000

PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses 
to the authors and the PIM WG only, so the broader community doesn't get 
bombarded with responses. This message is also being sent to the OSPF 
and ISIS WGs.

draft-lts-pim-hello-mtu-00.txt was inspired by customer reports of 
multicast routing hangups caused by MTU mismatches at the two ends of a 
link. The end with the larger MTU sends a message within its MTU size 
that is discarded at the other end because it is larger than that end's 
MTU size. The proposal in draft-lts-pim-hello-mtu-00.txt was for 
adjacent routers to exchange information on their MTUs on each link, 
then restrict message sizes to the smaller of the MTUs.

Working Group discussion in Vancouver raised the obvious question: do 
MTU mismatches cause problems for other routing protocols? And do any of 
these protocols have a solution to the problem?

I raised the issue of the effect of MTU mismatches on the NANOG list.
There were quite a few responses. Amongst other comments:

- OSPF hangs at a particular point in the state machine and fails to 
come up. Debugging can take a while if you don't think of MTU mismatch 
as a possible cause.

- Cisco has published a note on the subject, to be found at
 
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
(sorry about the wrapping).

- BGP can hang after a link flap when two specific products [identities 
omitted] are at the two ends of the link and the configured MTUs are 
identical, because one end includes the ethernet overhead and the other 
doesn't.

- a good MTU debugging tool can be found at
    http://www.elifulkerson.com/projects/mturoute.php


This message is written to ask the broader routing community what, if 
anything, routing protocols should do about identifying MTU mismatches, 
and beyond that, accommodating them. As requested above, please direct 
responses to the authors and the PIM WG only.

Tom Taylor

From tom.taylor.stds@gmail.com  Tue Sep  4 10:26:06 2012
Return-Path: <tom.taylor.stds@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 4E10E11E80A5; Tue,  4 Sep 2012 10:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level: 
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp9sfLqiIlcb; Tue,  4 Sep 2012 10:26:05 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3D11E809A; Tue,  4 Sep 2012 10:26:04 -0700 (PDT)
Received: by ieak13 with SMTP id k13so6185418iea.31 for <multiple recipients>; Tue, 04 Sep 2012 10:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=FmrRoAU9M6iHwODZMqRfofHEtfVF24AXfRefMuKB9Oc=; b=CHmbWAFcwWu9MlJnDiW59Klfz1mY8dKbS6WoZIiaLTuiX1vdJftsnlY7fbDS40OmAK zYUuqIoEhHQfoeLGi5v7XCsdU1OzM0BDFdqCzNxfH575As3ExxkTxCgnEvWeb2b80VWW GIZplOzgGyPSHJ1JrOuObBQp23QYHTzDHcPed5uTwP9Ww4hje/RokIM/CFj933e7SX8X +U6C58bxMEkUupsA+QLowBxpjB9S6EFvls6zDosHsIJ60RWvmF5nSDhB9S/nXX6DyrYb 6MU/SAXAPRbGLfcllYcAw38ECCyg0B0Idw4IT3yxzjmFu3HA5/hXTosITja4mlrkkX2p I0Hw==
Received: by 10.50.171.100 with SMTP id at4mr786878igc.73.1346779564512; Tue, 04 Sep 2012 10:26:04 -0700 (PDT)
Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id wg9sm13137010igb.0.2012.09.04.10.26.02 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:26:03 -0700 (PDT)
Message-ID: <504639A9.9000409@gmail.com>
Date: Tue, 04 Sep 2012 13:26:01 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: ospf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120904-0, 04/09/2012), Outbound message
X-Antivirus-Status: Clean
Cc: pim@ietf.org
Subject: [pim] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Sep 2012 17:26:06 -0000

PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses 
to the authors and the PIM WG only, so the broader community doesn't get 
bombarded with responses. This message is also being sent to the 
Routing-Discussion and ISIS WGs.

draft-lts-pim-hello-mtu-00.txt was inspired by customer reports of 
multicast routing hangups caused by MTU mismatches at the two ends of a 
link. The end with the larger MTU sends a message within its MTU size 
that is discarded at the other end because it is larger than that end's 
MTU size. The proposal in draft-lts-pim-hello-mtu-00.txt was for 
adjacent routers to exchange information on their MTUs on each link, 
then restrict message sizes to the smaller of the MTUs.

Working Group discussion in Vancouver raised the obvious question: do 
MTU mismatches cause problems for other routing protocols? And do any of 
these protocols have a solution to the problem?

I raised the issue of the effect of MTU mismatches on the NANOG list.
There were quite a few responses. Amongst other comments:

- OSPF hangs at a particular point in the state machine and fails to 
come up. Debugging can take a while if you don't think of MTU mismatch 
as a possible cause.

- Cisco has published a note on the subject, to be found at

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
(sorry about the wrapping).

- BGP can hang after a link flap when two specific products [identities 
omitted] are at the two ends of the link and the configured MTUs are 
identical, because one end includes the ethernet overhead and the other 
doesn't.

- a good MTU debugging tool can be found at
    http://www.elifulkerson.com/projects/mturoute.php


This message is written to ask the broader routing community what, if 
anything, routing protocols should do about identifying MTU mismatches, 
and beyond that, accommodating them. As requested above, please direct 
responses to the authors and the PIM WG only.

Tom Taylor

From tom.taylor.stds@gmail.com  Tue Sep  4 10:27:00 2012
Return-Path: <tom.taylor.stds@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 0012421E805D; Tue,  4 Sep 2012 10:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level: 
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTu7md11pW6O; Tue,  4 Sep 2012 10:26:59 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA87811E809A; Tue,  4 Sep 2012 10:26:58 -0700 (PDT)
Received: by iabz21 with SMTP id z21so10598872iab.31 for <multiple recipients>; Tue, 04 Sep 2012 10:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=oDJxvlJWTmAP4q6T16PwacHklmyMFPue8Wo0/qW4TAk=; b=xRK5LWTR/TwA3JcfzQ0RlMHCWXos7KWkiG4MZnlZN2gDfJmQ6GuYrPewTAtm3Xmyts 2NXAD+VrrhoqfrV7pkF5yZqjOzkchQINNs96sXv2A729auKvPVRjFR0QBsLd44UWUZFh xNKxItHlu8+j+piD3ah5oSCcyqkEP+caLaVP6o8ry95nwTfK1FHN8UeLYmBkHfeYhhJq 2I5gcEDmQT1TNKylKjGddFZpnfgZwSaeE+0u6ekRnRktFG988HHyo2ocz3UIk8dwnqRR vWqHx0YKreKn7cnEHL2ZWcxao861NkiiHRMMM+MBOvkbUMp+CnagtCKeAU+5DYdJ9BHK CN9A==
Received: by 10.50.5.133 with SMTP id s5mr2572382igs.49.1346779618552; Tue, 04 Sep 2012 10:26:58 -0700 (PDT)
Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id wm7sm27065636igb.6.2012.09.04.10.26.56 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:26:57 -0700 (PDT)
Message-ID: <504639DF.3060500@gmail.com>
Date: Tue, 04 Sep 2012 13:26:55 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: isis-wg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120904-0, 04/09/2012), Outbound message
X-Antivirus-Status: Clean
Cc: pim@ietf.org
Subject: [pim] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Sep 2012 17:27:00 -0000

PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses 
to the authors and the PIM WG only, so the broader community doesn't get 
bombarded with responses. This message is also being sent to the 
Routing-Discussion and OSPF WGs.

draft-lts-pim-hello-mtu-00.txt was inspired by customer reports of 
multicast routing hangups caused by MTU mismatches at the two ends of a 
link. The end with the larger MTU sends a message within its MTU size 
that is discarded at the other end because it is larger than that end's 
MTU size. The proposal in draft-lts-pim-hello-mtu-00.txt was for 
adjacent routers to exchange information on their MTUs on each link, 
then restrict message sizes to the smaller of the MTUs.

Working Group discussion in Vancouver raised the obvious question: do 
MTU mismatches cause problems for other routing protocols? And do any of 
these protocols have a solution to the problem?

I raised the issue of the effect of MTU mismatches on the NANOG list.
There were quite a few responses. Amongst other comments:

- OSPF hangs at a particular point in the state machine and fails to 
come up. Debugging can take a while if you don't think of MTU mismatch 
as a possible cause.

- Cisco has published a note on the subject, to be found at

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
(sorry about the wrapping).

- BGP can hang after a link flap when two specific products [identities 
omitted] are at the two ends of the link and the configured MTUs are 
identical, because one end includes the ethernet overhead and the other 
doesn't.

- a good MTU debugging tool can be found at
    http://www.elifulkerson.com/projects/mturoute.php


This message is written to ask the broader routing community what, if 
anything, routing protocols should do about identifying MTU mismatches, 
and beyond that, accommodating them. As requested above, please direct 
responses to the authors and the PIM WG only.

Tom Taylor

From tom.taylor.stds@gmail.com  Tue Sep  4 11:20:02 2012
Return-Path: <tom.taylor.stds@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 B66FC21E804E for <pim@ietfa.amsl.com>; Tue,  4 Sep 2012 11:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.29
X-Spam-Level: 
X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.309,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrkcAAw07nie for <pim@ietfa.amsl.com>; Tue,  4 Sep 2012 11:20:01 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7611E80A4 for <pim@ietf.org>; Tue,  4 Sep 2012 11:20:00 -0700 (PDT)
Received: by iabz21 with SMTP id z21so10705948iab.31 for <pim@ietf.org>; Tue, 04 Sep 2012 11:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=fPkd+I2IAoK6xNxKjTmVSbbDkWAdC0Jf1zBA7H5slAc=; b=rddjAJ7IxiaS4Nd7jqMEUVP8nEwv3OI3u883HETbTVIBZqM3xCllx+mjqpdFgpspCP 0gQ+SNLsT2Ii+tDfD7opOm5UE0MGEPWX4qcbzM73J+ZzWO20UPRNE6krWLGPKO4UFVzR Wkptsz80fdmt/4gil8z/qGHtlrETUjJTgatmUKNhnNXgwYM+ZeHO+pt/uBWCOs847FF2 uAk+tFMmhARHuWdihUXkWUAiMSaGfoZ9ksa2vsIFC0FTS6oGWuEpuDlo1riu9cP+O9J+ uvfO9mhdKebrEvugf+rRKSXmfy/b5ZRYJhwhvjVFFd6NIlE45iAHoxEGXP9x9BqaPzvm a9oA==
Received: by 10.50.156.170 with SMTP id wf10mr15306868igb.27.1346782800106; Tue, 04 Sep 2012 11:20:00 -0700 (PDT)
Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id ch4sm13159111igb.2.2012.09.04.11.19.58 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:19:59 -0700 (PDT)
Message-ID: <5046464D.5060302@gmail.com>
Date: Tue, 04 Sep 2012 14:19:57 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: pim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120904-0, 04/09/2012), Outbound message
X-Antivirus-Status: Clean
Subject: [pim] Apologies for spamming
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Sep 2012 18:20:02 -0000

Sorry I forgot to delete PIM from my messages to the OSPF and ISIS WGs.

Tom Taylor

From asmirnov@cisco.com  Thu Sep  6 07:33:47 2012
Return-Path: <asmirnov@cisco.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 985D321F8652 for <pim@ietfa.amsl.com>; Thu,  6 Sep 2012 07:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCKtyT3DRRHQ for <pim@ietfa.amsl.com>; Thu,  6 Sep 2012 07:33:46 -0700 (PDT)
Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3295D21F862B for <pim@ietf.org>; Thu,  6 Sep 2012 07:33:46 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q86EXXok028102; Thu, 6 Sep 2012 16:33:34 +0200 (CEST)
Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q86EXUAN020986; Thu, 6 Sep 2012 16:33:30 +0200 (CEST)
Message-ID: <5048B43A.7080209@cisco.com>
Date: Thu, 06 Sep 2012 16:33:30 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Tom Taylor <tom.taylor.stds@gmail.com>
References: <504640A5.1090302@gmail.com>
In-Reply-To: <504640A5.1090302@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 06 Sep 2012 11:12:59 -0700
Cc: pim@ietf.org
Subject: Re: [pim] [OSPF] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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 Sep 2012 14:33:47 -0000

    Hi Tom,
    first thing to acknowledge at the beginning of any MTU-related 
discussion is that there is no single MTU, there exists one MTU per 
protocol (on every level of OSI model). To give you an example - IPv4 
MTU is not necessarily the same as IPv6 MTU and they are definitely 
different than MTU for bridged PDUs. So strictly speaking your questions 
are incorrectly formulated. I presume you are talking about IPv4 MTU. 
This distinction is very important when single routing protocol somehow 
handles more than one net protocol. Say, ISIS runs on top of CLNS (and 
thus checks CLNS MTU) but is widely used to route IPv4 (and IPv6).
    The second thing, there exists MTU mismatch by configuration and 
actual MTU mismatch when configuration on both ends is identical but 
datagrams of that size cannot be exchanged (say, due to intermediate 
lower-level equipment on the link or due to software defect etc). So, 
against which one of them do you want to protect?

    In brief - ISIS in its original concept sends MTU-sized Hellos and 
thus can discover actual CLNS MTU mismatches. OSPF communicates 
configured MTU in some packets during exchange with neighbor and thus 
can discover MTU misconfiguration (OSPFv2 - IPv4, OSPFv3 - IPv6). BGP 
doesn't have its own MTU mechanism and relies on TCP's path MTU discovery.
    All routing protocols are bad in handling MTU mismatches for network 
protocol other than their native one.

    And finally my personal take - PIM shouldn't try to discover MTU 
mismatch.

Anton



On 09/04/2012 07:55 PM, Tom Taylor wrote:
> PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses
> to the authors and the PIM WG only, so the broader community doesn't get
> bombarded with responses. This message is also being sent to the
> Routing-Discussion and ISIS WGs.
>
> draft-lts-pim-hello-mtu-01.txt was inspired by customer reports of
> multicast routing hangups caused by MTU mismatches at the two ends of a
> link. The end with the larger MTU sends a message within its MTU size
> that is discarded at the other end because it is larger than that end's
> MTU size. The proposal in draft-lts-pim-hello-mtu-01.txt was for
> adjacent routers to exchange information on their MTUs on each link,
> then restrict message sizes to the smaller of the MTUs.
>
> Working Group discussion in Vancouver raised the obvious question: do
> MTU mismatches cause problems for other routing protocols? And do any of
> these protocols have a solution to the problem?
>
> I raised the issue of the effect of MTU mismatches on the NANOG list.
> There were quite a few responses. Amongst other comments:
>
> - OSPF hangs at a particular point in the state machine and fails to
> come up. Debugging can take a while if you don't think of MTU mismatch
> as a possible cause.
>
> - Cisco has published a note on the subject, to be found at
>
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
>
> (sorry about the wrapping).
>
> - BGP can hang after a link flap when two specific products [identities
> omitted] are at the two ends of the link and the configured MTUs are
> identical, because one end includes the ethernet overhead and the other
> doesn't.
>
> - a good MTU debugging tool can be found at
>     http://www.elifulkerson.com/projects/mturoute.php
>
>
> This message is written to ask the broader routing community what, if
> anything, routing protocols should do about identifying MTU mismatches,
> and beyond that, accommodating them. As requested above, please direct
> responses to the authors and the PIM WG only.
>
> Tom Taylor
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>


From tony.li@tony.li  Thu Sep  6 09:14:32 2012
Return-Path: <tony.li@tony.li>
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 346B121F8698 for <pim@ietfa.amsl.com>; Thu,  6 Sep 2012 09:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.477
X-Spam-Level: 
X-Spam-Status: No, score=-98.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJigbPAM5lca for <pim@ietfa.amsl.com>; Thu,  6 Sep 2012 09:14:31 -0700 (PDT)
Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 9900121F8630 for <pim@ietf.org>; Thu,  6 Sep 2012 09:14:31 -0700 (PDT)
Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta12.emeryville.ca.mail.comcast.net with comcast id volX1j0040vp7WLACsEWBd; Thu, 06 Sep 2012 16:14:30 +0000
Received: from sjc-vpn5-1951.cisco.com ([128.107.239.233]) by omta05.emeryville.ca.mail.comcast.net with comcast id vsDr1j00J52qHCY8RsDyYq; Thu, 06 Sep 2012 16:14:25 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Tony Li <tony.li@tony.li>
In-Reply-To: <504639DF.3060500@gmail.com>
Date: Thu, 6 Sep 2012 09:13:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCF22389-0841-4674-BC64-B43CD12597A5@tony.li>
References: <504639DF.3060500@gmail.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Mailman-Approved-At: Thu, 06 Sep 2012 11:12:59 -0700
Cc: isis-wg@ietf.org, pim@ietf.org
Subject: Re: [pim] [Isis-wg] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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 Sep 2012 16:14:32 -0000

On Sep 4, 2012, at 10:26 AM, Tom Taylor wrote:

> This message is written to ask the broader routing community what, if =
anything, routing protocols should do about identifying MTU mismatches, =
and beyond that, accommodating them. As requested above, please direct =
responses to the authors and the PIM WG only.


Well, you've now gone and spammed each of the routing groups =
individually.  Is this helping?

The BGP issue is a known TCP path MTU implementation problem. =20

The OSPF issue should be addressed by the OSPF WG.

And, more generally, yes, it's good for protocols to work around/detect =
and report MTU mismatches. =20

Regards,
Tony


From ginsberg@cisco.com  Thu Sep  6 10:28:45 2012
Return-Path: <ginsberg@cisco.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 5875521F8717; Thu,  6 Sep 2012 10:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5F+9I-n8lhY; Thu,  6 Sep 2012 10:28:44 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 93FFE21F86FA; Thu,  6 Sep 2012 10:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1388; q=dns/txt; s=iport; t=1346952524; x=1348162124; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0nNIF6bMhobmiQnPztySMC5gayiyfcPvy4tdJPonzAM=; b=csfLG+JWJ9ZYVqdAXb4c2Imm6HcPoORktR7J0XkXyMgmdsQ6tHRZ+Dh2 xRXZ8JnqmnBoCUbmEAwtwlv47rjJCeGAhnunWoflIPdGKfomBKTExjJpy z2PCZClaaKEEzfEHdUp6vrFhEpiM7fHgTj7biP7MfAKcLVL/og+FxeXtU Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOjbSFCtJV2b/2dsb2JhbABFu0GBB4IgAQEBBAEBAQ8BJzEDCwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgMDoduC5sRoC4EixGFZWADpA+BZ4Jj
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="119023783"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 06 Sep 2012 17:28:44 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q86HShqW027511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 17:28:44 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.253]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 12:28:43 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Tony Li <tony.li@tony.li>, Tom Taylor <tom.taylor.stds@gmail.com>
Thread-Topic: [Isis-wg] MTU mismatches and routing hangups
Thread-Index: AQHNjElPxTWZLWD8yUewlb8PogIP15d90HOA///AjwA=
Date: Thu, 6 Sep 2012 17:28:43 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F117C74DA@xmb-aln-x02.cisco.com>
References: <504639DF.3060500@gmail.com> <CCF22389-0841-4674-BC64-B43CD12597A5@tony.li>
In-Reply-To: <CCF22389-0841-4674-BC64-B43CD12597A5@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.107.163.64]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005
x-tm-as-result: No--46.085000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 06 Sep 2012 11:12:59 -0700
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] [Isis-wg] MTU mismatches and routing hangups
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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 Sep 2012 17:28:45 -0000

You might also find RFC 3719 Section 6 informative as regards IS-IS - thoug=
h I warn you that not all IS-IS experts are of the same mind in regards to =
the use of hello padding. :-)

   Les


> -----Original Message-----
> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behal=
f Of
> Tony Li
> Sent: Thursday, September 06, 2012 9:14 AM
> To: Tom Taylor
> Cc: Cathy Zhou(Qian); isis-wg@ietf.org; pim@ietf.org
> Subject: Re: [Isis-wg] MTU mismatches and routing hangups
>=20
>=20
> On Sep 4, 2012, at 10:26 AM, Tom Taylor wrote:
>=20
> > This message is written to ask the broader routing community what, if
> anything, routing protocols should do about identifying MTU mismatches, a=
nd
> beyond that, accommodating them. As requested above, please direct respon=
ses
> to the authors and the PIM WG only.
>=20
>=20
> Well, you've now gone and spammed each of the routing groups individually=
.
> Is this helping?
>=20
> The BGP issue is a known TCP path MTU implementation problem.
>=20
> The OSPF issue should be addressed by the OSPF WG.
>=20
> And, more generally, yes, it's good for protocols to work around/detect a=
nd
> report MTU mismatches.
>=20
> Regards,
> Tony
>=20
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

From adrian@olddog.co.uk  Wed Sep 19 09:46:03 2012
Return-Path: <adrian@olddog.co.uk>
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 15EBC21F846F for <pim@ietfa.amsl.com>; Wed, 19 Sep 2012 09:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Level: 
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbHlpD534FUz for <pim@ietfa.amsl.com>; Wed, 19 Sep 2012 09:46:02 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 044A721F84AF for <pim@ietf.org>; Wed, 19 Sep 2012 09:46:01 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8JGk067019382 for <pim@ietf.org>; Wed, 19 Sep 2012 17:46:00 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8JGjxqR019372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <pim@ietf.org>; Wed, 19 Sep 2012 17:46:00 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <pim@ietf.org>
References: <20120911195154.12873.14196.idtracker@ietfa.amsl.com>
In-Reply-To: <20120911195154.12873.14196.idtracker@ietfa.amsl.com>
Date: Wed, 19 Sep 2012 17:45:58 +0100
Message-ID: <070601cd9686$3f37fbb0$bda7f310$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEWjhAAClrq2tRiIrNGznytfoICPJj/8DyA
Content-Language: en-gb
Subject: [pim] FW: Last Call: <draft-ietf-v6ops-ivi-icmp-address-06.txt> (Stateless	Source Address Mapping for ICMPv6 Packets) to Best Current Practice
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: <http://www.ietf.org/mail-archive/web/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: Wed, 19 Sep 2012 16:46:03 -0000

Hi PIM WG,

Please be aware and comment as necessary.

Adrian

> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> bounces@ietf.org] On Behalf Of The IESG
> Sent: 11 September 2012 20:52
> To: IETF-Announce
> Cc: v6ops@ietf.org
> Subject: Last Call: <draft-ietf-v6ops-ivi-icmp-address-06.txt> (Stateless
Source
> Address Mapping for ICMPv6 Packets) to Best Current Practice
> 
> 
> The IESG has received a request from the IPv6 Operations WG (v6ops) to
> consider the following document:
> - 'Stateless Source Address Mapping for ICMPv6 Packets'
>   <draft-ietf-v6ops-ivi-icmp-address-06.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2012-09-25. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    A stateless IPv4/IPv6 translator may receive ICMPv6 packets
>    containing non IPv4-translatable addresses as the source.  These
>    packets should be passed across the translator as ICMP packets
>    directed to the IPv4 destination.  This document presents
>    recommendations for source address translation in ICMPv6 headers to
>    handle such cases.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.



From stig@venaas.com  Mon Sep 24 13:19:52 2012
Return-Path: <stig@venaas.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 AAA7521F88CA for <pim@ietfa.amsl.com>; Mon, 24 Sep 2012 13:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.671
X-Spam-Level: 
X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0DGzKcGa7oh for <pim@ietfa.amsl.com>; Mon, 24 Sep 2012 13:19:52 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A1C7E21F8623 for <pim@ietf.org>; Mon, 24 Sep 2012 13:19:51 -0700 (PDT)
Received: from [IPv6:2001:420:301:1004:6ddc:c7d3:7e17:506f] (unknown [IPv6:2001:420:301:1004:6ddc:c7d3:7e17:506f]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6E3CA7FF2 for <pim@ietf.org>; Mon, 24 Sep 2012 22:19:49 +0200 (CEST)
Message-ID: <5060C052.70808@venaas.com>
Date: Mon, 24 Sep 2012 13:19:30 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "pim@ietf.org" <pim@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [pim] PIM survey for operators (round 2)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 24 Sep 2012 20:19:52 -0000

The IETF pim working group is conducting a survey in order to advance
the PIM Sparse Mode spec on the IETF Standards Track, and would like
input from operators. The survey ends October 24th.

Please note that we did this survey previously with a deadline in July.
But owing to unforeseen circumstances we need to restart this survey.
We are acutely aware that this is an additional burden on the people
who took the time to respond before. We hope that they will re-send
their responses - maybe they are still filed in their sent emails.

Please see below for more information.

thank you,
pim chairs Mike & Stig
----

Introduction:

PIM-SM was first published as RFC 2117 in 1997 and then again as
RFC 2362 in 1998.  The protocol was classified as Experimental in
both of these documents.  The PIM-SM protocol specification was
then rewritten in whole and advanced to Proposed Standard as
RFC 4601 in 2006. Considering the multiple independent
implementations developed and the successful operational
experience gained, the IETF has decided to advance the PIM-SM
routing protocol to Draft Standard.  This survey intends to
provide supporting documentation to advance the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol
from IETF Proposed Standard to Draft Standard. (Due to RFC 6410,
now the intention is to progress it to Internet Standard.  Draft 
Standard is no longer used.)

This survey is issued on behalf of the IETF PIM Working Group.

The responses will be collected by a neutral third-party and kept
strictly confidential; only the final combined results will be
published.  Tim Chown and Bill Atwood have agreed to anonymize the
response to this Questionnaire. They have a long experience with 
multicast but have no direct financial interest in this matter, nor
ties to any of the vendors involved.  Tim is working at University of
Southampton, UK, and he has been active in the IETF for many years,
including the mboned working group, and he is a co-chair of the 6renum
working group.  Bill is at Concordia University, Montreal, Canada, and
he has been an active participant in the IETF pim working group for
over ten years, especially in the area of security.

Please send questionnaire responses addressed to them both. The
addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca.
Please include the string "RFC 4601 bis Questionnaire" in the subject
field.

Before answering the questions, please complete the following background
information.

Name of the Respondent:
Affiliation/Organization:
Contact Email:
Provide description of PIM deployment:
Do you wish to keep the information provided confidential:

Questions:

1       Have you deployed PIM-SM in your network?

2       How long have you had PIM-SM deployed in your network?
        Do you know if your deployment is based on the most recent
        RFC4601?

3       Have you deployed PIM-SM for IPv6 in your network?

4       Are you using equipment with different (multi-vendor) PIM-SM
        implementations for your deployment?

5       Have you encountered any inter-operability or backward-
        compatibility issues amongst differing implementations?
        If yes, what are your concerns about these issues?

6       Have you deployed both dense mode and sparse mode in your
        network?

        If yes, do you route between these modes using features such
        as *,*,RP or PMBR?

7       To what extent have you deployed PIM functionality, like BSR,
        SSM, and Explicit Tracking?

8       Which RP mapping mechanism do you use: Static, AutoRP, or BSR?

9       How many RPs have you deployed in your network?

10      If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446)
        or Anycast-RP using PIM (RFC 4610)?

11      Do you have any other comments on PIM-SM deployment in your
        network?

From stig@venaas.com  Mon Sep 24 13:24:59 2012
Return-Path: <stig@venaas.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 993FC21F88D4 for <pim@ietfa.amsl.com>; Mon, 24 Sep 2012 13:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.29
X-Spam-Level: 
X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIvlCL9nZqjT for <pim@ietfa.amsl.com>; Mon, 24 Sep 2012 13:24:59 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id B369521F88CE for <pim@ietf.org>; Mon, 24 Sep 2012 13:24:58 -0700 (PDT)
Received: from [IPv6:2001:420:301:1004:6ddc:c7d3:7e17:506f] (unknown [IPv6:2001:420:301:1004:6ddc:c7d3:7e17:506f]) by ufisa.uninett.no (Postfix) with ESMTPSA id DBD847FF2 for <pim@ietf.org>; Mon, 24 Sep 2012 22:24:56 +0200 (CEST)
Message-ID: <5060C18D.60409@venaas.com>
Date: Mon, 24 Sep 2012 13:24:45 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "pim@ietf.org" <pim@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [pim] PIM survey for implementors (round 2)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 24 Sep 2012 20:24:59 -0000

The IETF pim working group is conducting a survey in order to advance
the PIM Sparse Mode spec on the IETF Standards Track, and would like
input from implementors. The survey ends October 24th.

Please note that we did this survey previously with a deadline in July.
But owing to unforeseen circumstances we need to restart this survey.
We are acutely aware that this is an additional burden on the people
who took the time to respond before. We hope that they will re-send
their responses - maybe they are still filed in their sent emails.

Please see below for more information.

thank you,
pim chairs Mike & Stig
----

Introduction:

PIM-SM was first published as RFC 2117 in 1997 and then again as RFC
2362 in 1998.  The protocol was classified as Experimental in both of
these documents.  The PIM-SM protocol specification was then rewritten
in whole and advanced to Proposed Standard as RFC 4601 in 2006.
Considering the multiple independent implementations developed and the
successful operational experience gained, the IETF has decided to
advance the PIM-SM routing protocol to Draft Standard.  This survey
intends to provide supporting documentation to advance the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF
Proposed Standard to Draft Standard. (Due to RFC 6410, now the
intention is to progress it to Internet Standard.  Draft Standard is
not used anymore.)

This survey is issued on behalf of the IETF PIM Working Group.

The responses will be collected by a neutral third-party and kept
strictly confidential; only the final combined results will be
published.  Tim Chown and Bill Atwood have agreed to anonymize the
response to this Questionnaire. They have a long experience with 
multicast but have no direct financial interest in this matter, nor
ties to any of the vendors involved.  Tim is working at University of
Southampton, UK, and he has been active in the IETF for many years,
including the mboned working group, and he is a co-chair of the 6renum
working group.  Bill is at Concordia University, Montreal, Canada, and
he has been an active participant in the IETF pim working group for
over ten years, especially in the area of security.

Please send questionnaire responses addressed to them both. The
addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca.
Please include the string "RFC 4601 bis Questionnaire" in the subject
field.

Before answering the questions, please fill the following background 
information.

Name of the Respondent:
Affiliation/Organization:
Contact Email:
Provide description of PIM implementation:
Do you wish to keep the information provided confidential:

Questions:

1       Have you implemented PIM-SM?

2       Is the PIM-SM implementation based on RFC 2632 or RFC 4601?

3       Have you implemented (*,*, RP) state of RFC 4601? What is the
         rationale behind implementing or omitting (*,*,RP)?

4       Have you implemented the PMBR as specified in RFC 4601 and
         RFC 2715?
         What is the rationale behind implementing or omitting PMBR?

5       Have you implemented other features and functions of RFC 4601:
                 - SSM
                 - Join Suppression
                 - Explicit tracking
                 - Register mechanism
                 - SPT switchover at last-hop router
                 - Assert mechanism
                 - Hashing of group to RP mappings

6       Does your PIM-SM implementation support IPv6?

7       Have you encountered any inter-operability issues with other
         PIM implementations in trials or in the field?

8       Do you have any other comments or concerns about PIM-SM as
         specified in RFC4601?

From stig@venaas.com  Wed Sep 26 10:40:53 2012
Return-Path: <stig@venaas.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 BFADB21F85B4 for <pim@ietfa.amsl.com>; Wed, 26 Sep 2012 10:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.368
X-Spam-Level: 
X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7whh+L+wQ35 for <pim@ietfa.amsl.com>; Wed, 26 Sep 2012 10:40:53 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 2866921F85AD for <pim@ietf.org>; Wed, 26 Sep 2012 10:40:53 -0700 (PDT)
Received: from [IPv6:2001:420:301:1004:4dd:6234:f29c:32c2] (unknown [IPv6:2001:420:301:1004:4dd:6234:f29c:32c2]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8CE68801B for <pim@ietf.org>; Wed, 26 Sep 2012 19:40:51 +0200 (CEST)
Message-ID: <50633E21.3030505@venaas.com>
Date: Wed, 26 Sep 2012 10:40:49 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "pim@ietf.org" <pim@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [pim] pop-count issue, your input wanted
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 26 Sep 2012 17:40:53 -0000

As part of the IESG review of draft-ietf-pim-pop-count-06.txt,
someone questioned that the Transit and Stub oif-List counts are
only 2 octets.

This means that with pop-count, we currently have a limit on 64k
transit or stub oifs that can be counted for a tree. So if there
are more than 64k hosts, or more than 64k pim routers, we cannot
count them.

Do you have any thoughts on whether we should extend these to 4
octets?

I think the alternatives are more or less these:

1. Not change anything, 65535 means 65535 or more oifs.

2. Introduce an exponential encoding, allowing larger values than
    65535 but with less precision for large counts. Sort of like
    max resp time etc in IGMP/MLD.

3. Extend in the future if needed. One could add a new 16 bit
    option that is only included if the count is bigger than 64k,
    to store additional 16 bits.

4. Simply extend to 32 bits.

The semantics of the 2 could be different. The PIM count is likely
to be smaller than the host count. So stub bigger than transit. But
I suggest keeping them the same.

Thoughts?

Stig