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

From: The IESG <[email-masked]>
Date: Fri, 11 Apr 2008 12:00:49 -0700 (PDT)

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
[email-masked] mailing lists by 2008-04-25. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-encaps-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14250&rfc_flag=0

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Apr 2008 12:40:56 +0300 (EEST)

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Apr 2008 13:11:39 -0400

> seems vital to understanding and implementing this RFC.

Done.

> introduced in this document.

Done.

> what may or may not happen in a non-compliant decapsulator).

The new standard is not interoperable with  the old, but we are not aware of
any MPLS multicast deployments that  would be impacted.  I'll add a sentence
or two about this.

> Should this be described for completeness or explicitly declared out 

I would like to declare this to be out of scope.

> s/The former "multicast codepoint"/The latter "multicast codepoint"

That's not  a typo.  Instead of  "former multicast codepoint"  I could write
"the codepoint  formerly known as  the multicast codepoint", but  that would
make the abstract longer ;-)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2008 09:28:39 +0300 (EEST)

> any MPLS multicast deployments that  would be impacted.  I'll add a sentence

Sounds good.  Is it feasible to consider the failure modes of a 
non-upgraded implementation neighboring an upgraded implementation? 
It seems possible (even likely) that non-upgraded implementations 
exist even if those would not be widely deployed.

> I would like to declare this to be out of scope.

I have no preference about this provided that the WG makes some 
decision on this.

> make the abstract longer ;-)

How about "formerly defined multicast codepoint" if you're still 
concerned over this :-)