The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2007-Mar> msg00267



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Proposed G.8110.1 Amendment 1 Laision response

  • From: Stewart Bryant <stbryant@cisco.com>
  • Date: Wed, 21 Mar 2007 17:16:34 +0000
  • Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass (sig from cisco.com/amsdkim2001 verified; );
  • Cc: mpls@ietf.org
  • DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6455; t=1174497412;x=1175361412; c=relaxed/simple; s=amsdkim2001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=stbryant@cisco.com;z=From:=20Stewart=20Bryant=20<stbryant@cisco.com>|Subject:=20Proposed=20G.8110.1=20Amendment=201=20Laision=20response|Sender:=20; bh=Vhr9gl17dhAqG6DFzeYP0/Xi4Bim02vAAiVPYhfBoB0=;b=jySS0Lf3d2aR49drtRi+fwP9HySK2QEUFZBlPu5i3SagQuwOMEcVyQTihiLJXUIF/lgfoaqfZb/R1JopPSDnZUKZbtrK9sfHSJw5Lanu3DD1SFSPttvEwF7lzJeZnzi2;
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

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.

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