Re: [mpls] Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 at ietf.org mailing lists by 2008-04-25. Exceptionally,
> comments may be sent to iesg at 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
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.