The MPLS WG Archive

["Italo Busi" <italo.busi@alcatel-lucent.it>]

Stewart,

I feel a little bit unconfortable with the second part of the proposed liaison:

"The PWE3 WG will perform a further review of G.8110.1 Amendment 1 and will
respond in time for the ITU SG15 meeting in June."

It sounds like the draft has not been read at all. I do not think this is a
polite message we wish to give to ITU.

I would propose to smoote a little bit the message with something like:

"The PWE3 WG has not found other major issues than those identified by the MFA
Forum, however it will perform a further detailed review of G.8110.1 Amendment 1
and will respond in time for the ITU SG15 meeting in June."

Thanks, Italo

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Wednesday, March 21, 2007 6:17 PM
> To: pwe3; Mark Townsley; Jari Arkko
> Cc: George Swallow ((swallow)); mpls@ietf.org; Danny McPherson
> Subject: [PWE3] Proposed G.8110.1 Amendment 1 Laision response
>
>
> In response to the following liaison
>
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=287
> concerning G.8110.1 Amendment 1
>
> I propose that we respond with the following
> statement:
>
> "The PWE3 WG agrees with the concerns expressed by the MFA
> and wishes to be copied on the result of the SG15 analysis
> of these concerns.
>
> "The PWE3 WG will perform a further review of G.8110.1
> Amendment 1 and will respond in time for the ITU SG15
> meeting in June."
>
> I need to send this out in the next couple of days
> in time for their interim meeting next week.
>
> I append the MFA text of the MFA liaison response.
>
> - Stewart
>
> ===============
>
> The MFA Forum thanks ITU-T SG 15 for the liaisons from
> Q12/15, (from Geneva meeting) on an amendment to G.8110.1
> covering the architectural aspects of T-MPLS unidirectional
> p2mp connections, T-MPLS OAM and T-MPLS survivability.
>
> The MFA Forum also appreciates and thanks Q12/15 for asking
> for comments on the proposed draft G.8110.1 Amendment 1.
> The text below provides comments on the draft Amendment 1.
>
> 1	Point-to-multipoint connections
>
> The text for point-to-multipoint connections does not provide
> any details. The current text only indicates that a unidirectional
> point-to-multipoint sub-network connection broadcasts the
> traffic from the root to a number of leaves. The Recommendation
> G.8110.1 describes the functional architecture of Transport
> MPLS using the components in G.8110. However, Recommendation
> G.8110 does not specify any details of point-to-multipoint LSPs
> and therefore it is insufficient to base G.8110.1 on G.8110
> alone.
>
> With out providing additional details, it is not possible
> specify the point-to-multipoint LSPs. Some of the missing
> details are: Next hop label forwarding entries or packet
> replication; FEC; data plane (e.g., tree or point to
> point); Label assignment and Hierarchy.
>
> Just as Recommendation G.8110 referred to the base IETF
> Recommendations in its scope (e.g., RFC 3031, etc.), the
> MFA Forum suggests that G.8110.1 similarly refer in its
> scope to the base IETF RFCs on point to multipoint to
> provide these details. As was done previously, it is
> necessary to describe the functional architecture of MPLS
> point-to-multipoint using the modeling methodology
> described in ITU-T Recs G.805 and G.809. Following the same
> method used to develop G.8110 therefore, the basis for this
> work is the MPLS point-to-multipoint specification in the
> following IETF RFCs (Drafts).
>
> IETF defines data plane for p2mp connections, two label
> distribution protocols for setting up p2mp connections
> (RSVP-TE and LDP). IETF defines two possible applications
> of p2mp connections: 2547 VPNs and VPLS.
>
> IETF also extends MPLS architecture by defining
> upstream-assigned labels and the notion of context-specific
> label space. IETF defines extensions to RSVP-TE and
> LDP to support distribution of upstream-assigned labels.
> Upstream-assigned labels are used for (a) optimizing p2mp
> operations over multi-access media (LANs), and (b)
> p2mp LSP hierarchy. The list of relevant Internet Drafts:
> p2mp Data plane:
>      draft-ietf-mpls-multicast-encaps
>
> p2mp Label distribution protocols (for information):
>      draft-ietf-mpls-ldp-p2mp
>      draft-ietf-mpls-rsvp-te-p2mp
>
> Upstream assigned labels:
>      draft-ieft-mpls-upstream-label
>
> Extensions to RSVP-TE and LDP in support of upstream-
> assigned labels (for information):
>      draft-ietf-mpls-rsvp-upstream
>      draft-ietf-mpls-ldp-upstream
>
> p2mp OAM (for information):
>
>    draft-ietf-mpls-p2mp-oam-reqs
>    draft-ietf-mpls-p2mp-lsp-ping
>
>
> It is not clear what is supported in T-MPLS for point-to-
> multipoint connections.
>
> 1.1	EtherType for Point-to-multipoint frames
>
> T-MPLS uses the same data-link protocol ID (e.g. EtherType),
> frame format and forwarding semantics as defined for MPLS
> frames.  For point-to-point frames EtherType 0x8847 is
> used over Ethernet interfaces. It is not clear from the
> current draft how Ethertype is used after point-to-multipoint
> connections are added.
>
> IETF is working updating RFC 3032 MPLS Multicast
> Encapsulations. RFC 3032 established two data link layer
> codepoints for MPLS: one to indicate that the data link
> layer frame is carrying an MPLS unicast packet, and the
> other to indicate that the data link layer frame is
> carrying an MPLS multicast packet.  The new specification
> updates  RFC3032 by redefining the meaning of these two
> codepoints.
>
> The former "multicast codepoint" is now to be used only
> on multi-access media, and it is to mean "the top label
> of the following label stack is an upstream-assigned
> label".  The former "unicast codepoint" is to be used
> in all other cases.  Whether the data link layer payload
> is a unicast MPLS packet or a multicast MPLS packet is
> now to be determined by looking up the top label, rather
> than by the codepoint.
>
> The new draft also specifies “MAC DA” field of an
> Ethernet frame which carries MPLS multicast packet.
> Please see IETF draft “MPLS Multicast Encapsulations”
> draft-ietf-mpls-multicast-encaps-02.txt, September 2006.
>
> 1.2	OAM support for Point-to-multipoint
>
> Point-to multipoint LSPs are unidirectional. However,
> there is T-MPLS OAM information, such as BDI,
> “Linktrace-Reply” and “Loopback-Reply”, that should be
> transmitted from the leaves to the root.
>
> The architecture does not specify how the data is
> transmitted from the leaves to the root. With out this
> capability it is not possible to support some of the
> OAM capabilities.
>
> 2	Generic requirements
>
> One of the major capabilities missing in the T-MPLS
> architecture is security capabilities. The following
> security capabilities are suggested for inclusion.
> These requirements are derived from the MFA Forum
> Service provider council MPLS-ICI requirements. Since
> T-MPLS supports NNI, these requirements are applicable.
> The capabilities are:
>
> •	Authentication of OAM messages with MD5 or other.
> •	Control of labels used over NNI
> •	IPSec all tunnels over which control messages
>          are exchanged.
>
> The MFA Forum thanks ITU-T SG 15 for the opportunity
> to provide comments and suggestions in relation to
> T-MPLS as a packet transport network technology.
> Further, the MFA Forum is interested in receiving
> updates on this and the work you are initiating to
> address control plane aspects.
>
> The MFA Forum meets from March 6-8, 2007 in Chicago, IL USA.
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls