Subject: [PWE3] Proposed G.8110.1 Amendment 1 Laision response

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Mar 2007 17:16:34 +0000

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

---

From: "O'Connor, Don" <[email-masked]>
Date: Wed, 21 Mar 2007 13:00:37 -0500

Stewart

In your proposed liaison response you indicate

"The PWE3 WG agrees with the concerns expressed by the MFA"

The MFA concerns include the following

"One of the major capabilities missing in the T-MPLS

•	Authentication of OAM messages with MD5 or other."

It is not clear if this pertains to 

1) Single segment S-PE to S-PE across an ICI

2) MS-PW from T-PE to T-PE across an ICI and Single segment S-PE to S-PE across an ICI

Does this mean that the PWE3 WG also supports this concept for PWE3 work on MS-PW OAM ?

The current draft-ietf-pwe3-segmented-pw-04.txt (which covers MS-PW VCCV OAM) indicates

"An example is the inter-AS L2VPN scenario where the ultimate
            PEs reside in different provider networks (ASes) and it is
            the practice to MD5-key all control traffic exchanged
            between two networks. Technically a SS-PW could be used but
            this would require MD5-keying on ALL ultimate source and
            destination PE nodes. An MS-PW allows the providers to
            confine MD5 key administration to just the PW switching
            points connecting the two domains."

The current segmented-pw draft does not yet address how to apply BFD (including BFD MD5 authentication) for MS-PW VCCV OAM

So maybe it is too early to give total agreement with all MFA concerns until all these issues are addressed and agreed in PWE3

Regards

Don

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 12:17 PM
To: pwe3; Mark Townsley; Jari Arkko
Cc: George Swallow ((swallow)); [email-masked]; Danny McPherson
Subject: [PWE3] Proposed G.8110.1 Amendment 1 Laision response

- Stewart

===============

2	Generic requirements

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Mar 2007 18:24:48 +0000

How about

"The PWE3 WG agrees with many of the concerns expressed by the MFA"

- Stewart

---

From: "O'Connor, Don" <[email-masked]>
Date: Wed, 21 Mar 2007 14:39:40 -0500

Stewart

Your revision of the liaison in OK my me. On the broader issue I suggest / offer the following

1) PWE3 / MS-PW VCCV / segmented-pw needs more work / consideration of

1) Use of BFD for a continuous continuity check (including support for protection switching fault detection), both per segment and EE

2) Multi-domain security

For multi-domain security, my guess is that T-MPLS (Y.17tom) and Ethernet OAM (Y.1731 / 802.1ag) already claim a solution which is based on the use of ME Levels and filtering on ME Levels at the domain edge.

On first glance it would appear that ITU T-MPLS OAM and Ethernet Y.1731 / 802.1ag is ahead of PWE3 on the multi-domain security issue.

If one of the VCCV options is to use Y.1731 / 802.1ag (which could be modified  for non-Ethernet clients) - then the security gap would be closed (along with gaining other functionality - PM measurement, AIS / RDI fault propagation, etc)

Regards

Don

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 1:25 PM
To: O'Connor, Don
Cc: pwe3; Mark Townsley; Jari Arkko; George Swallow ((swallow));
[email-masked]; Danny McPherson
Subject: Re: [PWE3] Proposed G.8110.1 Amendment 1 Laision response

How about

- Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 22 Mar 2007 15:05:21 +0100

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

> Sent: Wednesday, March 21, 2007 6:17 PM

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 10:23:32 -0400

I prefer something closer to Stewart's earlier
statement:

"Although the PWE3 WG agrees with the concerns expressed by
the MFA, we intend will perform a further detailed review
of G.8110.1 Amendment 1 and will respond in time for the
ITU SG15 meeting in June.  The PWE3 WG also requests
that SG15 inform the PWE3 WG with the result of the SG15
analysis of these concerns."

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 22 Mar 2007 10:58:56 -0400

Italo, 

> 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.
> 
> "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 

Since PWE3 intends to perform a detailed review of the proposal
I don't think at this point in time PWE3 is in position
to conclude that it "has not found other major issues than 
those identified by the MFA forum". 

Hamid.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Mar 2007 16:21:15 +0100

> those identified by the MFA forum". 
Thanks Hamid, absence of proof is not proof of absence.

Please note that the ITU (T)MPLS work has been taking huge resources from
the PWE3 & MPLS ADs and chairs. Since last summer one week of
1AD + 2WG  chairs, and one week of 2WG chairs  to ensure that the first
version of T-MPLS  complied with the IETF PWE3/MPLS architecture -
and when we did find an error it took significant time to negotiate the
changes needed for compliance in multiple ITU groups across multiple
documents.

Plus the work on the current set of documents needing review....

There are six that need working on at

https://datatracker.ietf.org/public/liaisons.cgi

i.e. the G.8110.1 amendment above and five others.

The PWE3 chairs  would appreciate any comments on those documents.

Thanks

Stewart

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 28 Mar 2007 10:46:01 -0400

Hi Stewart, 

> >> "The PWE3 WG will perform a further review of G.8110.1 Amendment 1 
> >> 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.
> >>
> 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."
> >>
> >>     
> >
> > Since PWE3 intends to perform a detailed review of the proposal I 
> > don't think at this point in time PWE3 is in position to 
> conclude that 
> > it "has not found other major issues than those identified 
> by the MFA 
> > forum".
> >
> > Hamid.
> >   
> Please note that the ITU (T)MPLS work has been taking huge 
> resources from the PWE3 & MPLS ADs and chairs. Since last 
> summer one week of 1AD + 2WG  chairs, and one week of 2WG 
> chairs  to ensure that the first version of T-MPLS  complied 
> with the IETF PWE3/MPLS architecture - and when we did find 
> an error it took significant time to negotiate the changes 
> needed for compliance in multiple ITU groups across multiple 
> documents.
> 

I think one of the issue I see from the thread discussions
is it looks that MPLS and PWE3 WG (IETF) are not comfortable 
with the use of MPLS acronym (and technology) in 
ITU <T>-MPLS work. 

Though the (G)MPLS change process did actually define 
the process of extending MPLS by other SDO, it did not 
address the case where other SDOs standardize technologies 
that use some of IETF MPLS-based documents and then label 
or identify these technologies as being "<X>-MPLS-based".

I think it is up to the MPLS WG (and IETF in general) to 
evaluate whether such use of MPLS is *okay* (using the
change process) and is as well *okay* to call the proposed 
technology <X>-MPLS. 

It looks from the T-MPLS discussion here that it looks
not enough that a proposal uses an IETF defined MPLS label, 
removes IP, turns off some MPLS features and adds new non 
IETF MPLS/PWE3 capabilities for the end result to be qualified 
as <X>-MPLS. This creates additional confusions (on what version
of MPLS each SDO means) and leads to all these 
lengthy time consuming liaison processes just to get common
understanding of the intent and compliancy to IETF MPLS
architecture/RFCs. 

On the other hand, with respect to using MPLS in
transport networks for example, there is actually no work 
in MPLS working group that clarifies how MPLS works 
in Non-IP environment. 

I think MPLS WG should describe in an internet-draft
the "Application of MPLS in Non-IP Network 
Environment" (I assume some of it is already captured in Stewart 
pwe3-transport draft). And Stewart's draft should refer to 
that work too.

That draft can be liaised to other SDOs that intend to use MPLS 
in non IP environment (along with the change process document).  
 
Hamid.