The MPLS WG Archive

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

Monique, Tom,

the question we need to answer is: have we identified issues with the current
draft so far (in addition to the ones identified by MFA Forum)?

If no additional issues have been identified it is better to communicate. Or, if
some additional issues have been identified it is better to list them.

Of course, there is time for an additional review before the June meeting. I am
not against keeping the door open for a further review, but I think we should
communicate the result of the review held till now.

Tom's proposal seems better because it could be interpreted in this way (i.e. no
other issues, other than those raised by MFA Forum, identified so far, but need
to perform futher detailed review) but the first part of the message (i.e. i.e.
no other issues, other than those raised by MFA Forum, identified so far) is
hidden and suject to personal interpretation.

Thanks, Italo

> -----Original Message-----
> From: Monique Morrow [mailto:mmorrow@cisco.com]
> Sent: Thursday, March 22, 2007 3:40 PM
> To: Italo Busi; Stewart Bryant; pwe3; Mark Townsley; Jari Arkko
> Cc: mpls@ietf.org
> Subject: Re: [mpls] RE: [PWE3] Proposed G.8110.1 Amendment 1 Laision
> response
>
>
> Italo,
>
> I believe that the wording is just fine .
>
> As an ITU participant ; I see nothing impolite about it, as a further review
> shall determine whether or not there are major issues.
>
> Regards,
> Monique
>
>
>
> On 22/3/07 10:05 am, "Italo Busi" <italo.busi@alcatel-lucent.it> wrote:
>
> > 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
>

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