The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: [PWE3] Fwd: I-DACTION:draft-bryant-pwe3-mpls-transport-00.txt
On Mar 22, 2007:4:32 PM, at 4:32 PM, O'Connor, Don wrote: > Tom, > > Please see my replies below > > Regards > > Don > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, March 22, 2007 1:00 PM > To: O'Connor, Don > Cc: Danny McPherson; pwe3 ((((((((((((((((E-mail)))))))))))))))) WG; > Swallow George; mpls@ietf.org; Townsley Mark; Ward David; Ross Callon > Subject: Re: [PWE3] Fwd: I-D > ACTION:draft-bryant-pwe3-mpls-transport-00.txt > > > > Hi, > >> I do not support draft-bryant-pwe3-mpls-transport-00.txt as a WG >> draft for the following reasons >> >> 1) Transport MPLS as pursued by ITU encompasses functionality that >> overlaps work in multiple IETF WGs. A minimum subset is PWE3 and >> MPLS. Work in CCAMP is also most probably relevant. Without >> companion work in the MPLS WG on a T-MPLS implementation profile, >> draft-bryant-pwe3-mpls-transport-00.txt serves no useful purpose > > Although Townsley and Ross/Ward should declare > which WGs are most relevant for this draft, my two > cents are that although PWE3 and MPLS are surely relevant to the > draft as-written, I don't see where CCAMP (or any other WG) > needs to be involved other than PWE3 since the purpose of > the draft is to show how the requirements for T-MPLS can > be solved using a few "off the shelf" and already deployed > protocols. > > [Don - CCAMP involvement may not be needed in the near term, but my > view is that it would be needed in the longer term if a more > comprehensive relationship is developed between ITU SG 15 and IETF > for Transport MPLS standardization (including the Control Plane > aspects). For example for Transport Multi-Segment Pseudowires the > preferred signaling solution could be GMPLS RSVP-TE rather than LDP] Perhaps. FYI, our draft, as-written supports both static and signaled paths via GMPLS/RSVP-TE. From section 4.2: In this section we describe the profile when RSVP-TE [] or the bi- directional support in GMPLS [] are used to configure the MPLS PSN used to provide the transport LSPs. >> I suggest that a first necessary step is that the appropriate Area >> Directors consider whether or not they want to take on the entire >> task of generating a complete Transport MPLS implementation profile >> based on current RFC / ID / extensions and doing it right and >> comprehensively. WG charters should be updated appropriately > > Why do charters need to be updated? If you have read the draft, > we have shown how a "comprehensive T-MPLS solution" can be built only > using existing (and deployed) protocols. What you are advocating is > slowing down the progress on this issue with needless procedural > process. > > [Don - My understanding is that the goals / perceived applications > of Transport MPLS go beyond the Ethernet Port connectivity scenario > in the existing draft. I think a longer term commitment is needed > than just the draft in question. Consequently a potential > appropriate step would be charter updates for PWE3 and MPLS WGs. As > a near term minimum I think the MPLS WG should agree to work on > Transport MPLS RFCs. Section 4 of the draft in question could be > used as a starting basis for an ID on Transport MPLS LSPs. My > understanding is that ITU also wishes to support P2MP Transport > MPLS LSPs. So this would require an implantation profile from the > MPLS WG.] I still don't see why the charters need to be updated per se, except perhaps to add milestones for these work items explicitly. Whether or not that is necessary is again up to the chairs/ADs, but IMHO it is unnecessary. >> In its present form draft-bryant-pwe3-mpls-transport-00.txt is an >> incomplete attempt at addressing a portion of what ITU SG 15 and >> ITU SG 13 are pursuing for Transport MPLS > > Perhaps you could elaborate on this statement? > > [Don - I will offer several examples - Multi-Segment Transport > Pseudowires, protection switching as defined in G.8131, Transport > MPLS Ring Protection, OAM as defined in Y.17tor / Y.17tom, ID on > Transport MPLS LSPs including P2MP, Control Plane LDP per segmented > PWs may not be the appropriate solution] >> If IETF leadership decides that they would like to pursue a >> comprehensive Transport MPLS implementation profile, it should be >> done in cooperation and coordination with leadership in ITU SG 15 >> and SG 13. I would support such as effort if it is done in this >> context. To date draft-bryant-pwe3-transport-00.txt does not fall >> into this category > > I think the point is that the IETF leadership has already > decided to pursue T-MPLS by virtue of it being a true subset of > MPLS/PWE3. I don't see why any further procedural actions are > necessary to move this work forward. > > [Don - I think a more comprehensive longer term commitment is > needed beyond draft-bryant] > >> 2) draft-bryant-pwe3-mpls-transport-00.txt does not adequately >> address Transport MPLS OAM and Protection Switching requirements > > Please be specific. > > [Don - please see G.8131,G.8031, Y.17tor / Y.17tom] > >> 2A) Protection Switching - linear protection switching coordinated >> by an appropriate OAM protocol is required. It is necessary to meet >> the requirements of G.8131 > > Please be specific. > > [Don - please see the detailed functionality in G.8131 and G.8031] > >> 2B) Current pseudowire VCCC OAM lacks - Maintenance Entity Levels, >> MEP / MIP, AIS / RDI, PM measurement. It is necessary to provide >> the functionality being developed for Y.17tom > > Although this is true, adding these is not difficult, and > is something that is already being discussed as part of the MH-VCCV > work. > > [Don - One potential way to add the missing OAM functionality is > to: 1) Allocate VCCV code points for "Y.1731 / 802.1ag for > pseudowires" and 2)modify Y.1731 / 802.1ag for use with VCCV (e.g. > use AII rather than Ethernet SA / DA] Another is to modify y.17tom (which is a fantastic way to name a document I might add!) to reference y.1714. We have in fact already made recent contributions to do so. And of course, as I said, to add MIP/MEPs to MH-VCCV. --Tom > > --Tom > > > >> >> Regards >> >> Don >> >> >> -----Original Message----- >> From: Danny McPherson [mailto:danny@tcb.net] >> Sent: Thursday, March 22, 2007 4:31 AM >> To: pwe3 ((((((((E-mail)))))))) WG >> Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls- >> transport-00.txt >> >> >> >> Folks, >> As discussed in the meeting, I'd like to solicit WG feedback on >> adopting this as a WG document. If you're in favor or opposed >> to adopting this please speak up now. >> >> -danny >> >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> Date: October 16, 2006 1:50:01 PM MDT >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Application of PWE3 to MPLS Transport Networks >>> Author(s) : S. Bryant >>> Filename : draft-bryant-pwe3-mpls-transport-00.txt >>> Pages : 13 >>> Date : 2006-10-16 >>> >>> A need has been identified to identify a strict subset of the PWE3 >>> over MPLS pseudowire functionality suitable for the >>> construction of >>> transport networks. This draft describes the IETF recommended >>> profile >>> for such cases. This document describes the IETF-recommended >>> profile >>> for such a configuration. In particular the profile of an RFC4448 >>> PWE3 Ethernet pseudowire that can be used to address these >>> requirements is described. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-mpls- >>> transport-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-bryant-pwe3-mpls-transport-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-bryant-pwe3-mpls-transport-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2006-10-16113713.I-D@ietf.org> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> _______________________________________________ >> 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
|
|