Re: Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard

Pekka Savola <pekkas@netcore.fi> Thu, 17 April 2008 09:41 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70F63A6FEC; Thu, 17 Apr 2008 02:41:38 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0543A6FEB; Thu, 17 Apr 2008 02:41:37 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FARhff6ppFkz; Thu, 17 Apr 2008 02:41:31 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3196A28C521; Thu, 17 Apr 2008 02:40:30 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m3H9exee014442; Thu, 17 Apr 2008 12:40:59 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m3H9euHE014439; Thu, 17 Apr 2008 12:40:57 +0300
Date: Thu, 17 Apr 2008 12:40:56 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
Subject: Re: Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard
In-Reply-To: <20080411190049.330E528C23B@core3.amsl.com>
Message-ID: <alpine.LRH.1.10.0804171226270.14062@netcore.fi>
References: <20080411190049.330E528C23B@core3.amsl.com>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6807/Thu Apr 17 01:25:48 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: mpls@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 11 Apr 2008, The IESG wrote:
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
>
> - 'MPLS Multicast Encapsulations '
>   <draft-ietf-mpls-multicast-encaps-07.txt> as a Proposed Standard
>
> 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 2008-04-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.

I did not look into this in detail because I claim no expertise in 
MPLS, but...

I believe this document needs a normative reference to 
draft-ietf-mpls-upstream-label (now in Last Call) because the whole 
concept of upstream labels is introduced in that document and it 
seems vital to understanding and implementing this RFC.

IANA considerations section should describe how IANA should reword the 
"unicast codepoint" and "multicast codepoint" assignment fields.  It 
seems clear that these should be renamed to better reflect the reality 
introduced in this document.

The document does not describe the impact (of lack thereof) of 
redefining the usage of existing codepoints and modifying existing 
standards (e.g. the MPLS-in-IP and MPLS-in-GRE encapsulation rules and 
what may or may not happen in a non-compliant decapsulator).

Section 6 gives instructions how to handle unicast and multicast 
destination address.  It does not describe how to handle the v4 255/8 
broadcast address and it's debatable which category would apply if a 
packet was sent to a regular broadcast address such as 192.0.2.255/24. 
Should this be described for completeness or explicitly declared out 
of scope?

editorial comment
-----------------

Abstract is a bit long and has a typo:
s/The former "multicast codepoint"/The latter "multicast codepoint"


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf