From nabil.n.bitar@verizon.com Wed Jan 2 08:29:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278D021F8652 for ; Wed, 2 Jan 2013 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzp1I63vYcX2 for ; Wed, 2 Jan 2013 08:29:27 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 177DF21F8650 for ; Wed, 2 Jan 2013 08:29:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 02 Jan 2013 16:29:22 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.84,396,1355097600"; d="scan'208,217";a="388991598" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi02.verizon.com with ESMTP; 02 Jan 2013 16:29:22 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Wed, 2 Jan 2013 11:29:21 -0500 To: Lizhong Jin , "rtg-ads@tools.ietf.org" Date: Wed, 2 Jan 2013 11:28:27 -0500 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Thread-Index: Ac3pBlGh4iSFOq7wS1K09nI2dTNg8w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD08F4B46DC50nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 16:29:29 -0000 --_000_CD08F4B46DC50nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks for your review and comments and sorry for a late reply. Please, see= inline. Thanks, Nabil From: Lizhong Jin > Date: Tuesday, August 14, 2012 8:34 AM To: "rtg-ads@tools.ietf.org" > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" >, "rtg-dir@ietf.org" > Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Reviewer: Lizhong Jin Review Date: Aug, 14th, 2012 IETF LC End Date: Aug, 20th, 2012 Intended Status: Standard track Summary: 1.I have some minor concerns about this document that I think should be res= olved before publication. Comments: Basically, this document is well written and I believe the mechanism has be= en implemented and deployed in real networks. There are only some parts of = the document that need to be clarified to avoid misunderstanding. Major Issues: No major issues found. Minor Issues: 2.2. Abstract Defect States A PW forward defect indication received on PE1 impacts the ability of PE1 to receive traffic on the PW. [Lizhong] "PW forward defect" only refers to one mechanism above, should it= be "PW receive defect"? PE1 receives a a forward defect indication and enters the receive def= ect state. That is really what is in the text now. This terminology is also= used in RFC 6310. The text as it is is correct and consistent. 4.1. Use of Native Service (NS) Notification - Sending of AIS frames from the local MEP to the MEP on the remote PE when the MEP needs to convey PE receive defects, and when CCM transmission is disabled. [Lizhong] "PE receive defects" refer to PE AC receive defects or both AC an= d PE receive defects? Section 4.1 lists the mechanisms used for fault notification on the PSN si= de only upfront. Section 6.1 "PW Receive Defect entry procedures" specified how the mechanis= ms in section 4.1 can be used when receive defect is detected on the PW. Pl= ease, look at the paragraph before last in that section. Section 6.5 "AC Receive Defect Entry Procedures" describes how the mechanis= ms used in section 4.1 are used when AC receive defect state is entered. Pl= ease, look at the 4th paragraph in that section. - Suspension of CCM frames transmission from the local MEP to the peer MEP on the remote PE to convey PE receive defects, when CCM transmission is enabled. [Lizhong] "PE receive defects" refer to PE AC receive defects or both AC an= d PE receive defects? Please, see above answer. The same applies here. 4.2. Use of PW Status notification for MPLS PSNs There are also scenarios where a PE carries out PW label withdrawal instead of PW status notification. These include administrative disablement of the PW or loss of Target LDP session with the peer PE. [Lizhong] There is another PW/AC status signaling method by using label wit= hdraw method when PW status notificationis not supported. Is it intentional= ly ignored? I am not sure I understand the comment as the text you quoted is refer= ing to PW label withdrawal as an alternative for status notification. Isn't= that what you are referring to? 4.3. Use of BFD Diagnostic Codes When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using the OAM capability sub-TLV signaled as part of the interface parameter TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128. [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface parameters = sub-TLV", right? Suggest to align with terminology in RFC5085. Will do. Here is the iterated text: When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using the VCCV parameter field signaled as a sub-tlv of the interface parameters TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128. 5. Ethernet AC Defect States Entry or Exit Criteria [Lizhong] context of AC receive/transmit defect entry is duplicated with th= at in section 2.2. Is it possible to make the context more simple, either i= n section 2.2 or 5.1? There is overlap. I am proposing to merge text related to conditions f= or entering the defect states in section 2.2 into 5.1 and reduce the overl= ap . I believe that addresses that point. If that is OK with you, I will do= that and send as part of the updated document. 6. Ethernet AC and PW Defect States Interworking [Lizhong] RFC2119 words should be used in this section, e.g, "must" should = be "MUST". Done. 6.1. PW Receive Defect Entry Procedures [Lizhong] this section does not describe the mechanism to enter PW receive = defect state, is it same with that in section 2.2? Section 6.1 discusses the actions when the PE enters the PW receive de= fect state not the criteria to enter that state. However, as you pointed ou= t section 2.2 describes criteria for entering receive defect state. It is s= imilar to that in RFC6310. That is why it wa sin section 2.2 only as a revi= ew. However, a better organization would be to have a parallel section to 5= .1 is. To streamline things, I will do the same as proposed in the previou= s similar comments. That is, merge text from section 2.2 into 6.1. If that= is OK with you, I will do that and send as part of the updated document. <= NB> Further, when PE1 enters the Receive Defect state, it must assume that PE2 has no knowledge of the defect and must send reverse defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is done via either a PW Status notification message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 had been negotiated. [Lizhong] why CV type of 0x20 is missed here? Done. It should be as in other places in the document. There is one ad= ditional place, where that will be corrected as well. Thanks. 6.2. PW Receive Defect Exit Procedures [Lizhong] this section does not describe the mechanism to exit PW receive d= efect state? This section describes what actions must happen when the PE exits the = PW receive defect state and not what needs to happen to exit the PW receive= defect state. The PW receive and transmit defect state entry and exit crit= eria are summarized in section 2.2 and are common with what is described in= RFC 6310, as highlighted in section 4 and that is why they were thought a= s being summarized and not included later. However, again I think with the = changes above, and to make it clearer based on the comment, I can consolid= ate that in a section that says PW Receive Defect State Entry and Exit crit= eria, and similarly PW Transmit Defect state and Exit criteria that paralle= l those of the the AC. Will that address that point? If PW receive defect was established via notification from PE2 or via loss of control adjacency, no additional action is needed, since PE2 is expected to be aware of the defect clearing. [Lizhong] the above description is incorrect in this section. The exit of P= W receive defect should be described, not enter of PW receive defect. Per above, this section describes what action PE1 needs to take when i= t exits the receive defect state. It is not describing how it enters or exi= ts the receive defect state. 6.3. PW Transmit Defect Entry Procedures - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. [Lizhong] shouldn't the entry of PW transmit defect be signaled to remote P= E? I do not see such text here. It was assumed per section 4 to be the same in rfc 6310 since this is = failure that pertains to the PSN side. However, for completeness here and c= onsistency, I agree we should include it. I will include the following per = rfc 6310. "If the PW failure was detected by PE1 without receiving reverse defect not= ification from PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST notify PE2 by sending FDI." 6.4. PW Transmit Defect Exit Procedures - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. [Lizhong] same comment as for previous section, shouldn't the exit of PW tr= ansmit defect be signaled to remote PE? I do not see such text here. Yes, and will include the following in-line with above response: PE1 MUST clear the FDI to PE2, if applicable. 6.5. AC Receive Defect Entry Procedures When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1. [Lizhong] is there any relationship between notification mechanism in CE do= main and mechanism in PE domain. I mean if the AC uses NS OAM to detect def= ect in CE domain, does NS OAM between PEs have any priority to apply? When NS OAM is supported PSN-facing and the fault notification functio= ns are enabled as described, then they are used for fault notification. Is = that the question? Nits: There are some nits that need to resolve. Please check link: http://tools.i= etf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-= iwk-06.txt Yes. That will be taken care of in the updated version. Regards Lizhong --_000_CD08F4B46DC50nabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lizhong,
Thanks for your review and c= omments and sorry for a late reply. Please, see inline.

Thanks,
Nabil

=
From: Lizhong Jin <lizhong.jin@zte.com.cn>
Date: Tuesday, August 14, 2012 8:34 AM
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" <draft-ietf-pwe3-= mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-di= r@ietf.org>
Subject: [RT= G-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt


Hello,

<= font size=3D"2" face=3D"sans-serif">I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to revie= w all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the revie= w is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comment= s are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. =

Document: draft-ietf-pwe3-mpls= -eth-oam-iwk-06.txt
Reviewer: Lizhong Jin
Review Date: Aug, 14th, 2012
IETF LC End Date: Aug, 20th, 20= 12
Intended Status: Standard= track

Summary:1.I have some minor concerns about t= his document that I think should be resolved before publication.

= Comments:
Basically, this document is well written and I believe the mechanism has been implemented and deployed in real netwo= rks. There are only some parts of the document that need to be clarified to avoid misunderstanding.

= Major Issues:
No major issue= s found.

Minor Issues:
2.2.  Abstract Defect St= ates
A PW forward defect in= dication received on PE1 impacts the ability
= of PE1 to receive traffic on the PW.
[Lizhong] "PW forward defec= t" only refers to one mechanism above, should it be "PW receive defect"?

 
4.1. Use of Nati= ve Service (NS) Notification  

    - S= ending of AIS frames from the local MEP to the MEP on the
remote PE when the MEP needs to convey PE receive defects, and when
CCM transmission is disabled.  
[Lizhong] "PE receive defects" refer to PE AC receive defects or both AC and PE receive defects?

=
&l= t;NB>
 Section 4.1 lists the mechanisms used for fault notification on= the PSN side only upfront.
Section 6.1 "PW Receive Defect entry procedures" s= pecified how the mechanisms in section 4.1 can be used when receive defect = is detected on the PW. Please, look at the paragraph before last in that se= ction.
<NB>
    = - Suspension of CCM frames transmission from the local MEP to
the p= eer MEP on the remote PE to convey PE receive defects, when
CCM transmissio= n is enabled.  
[Lizhong] "PE rece= ive defects" refer to PE AC receive defects or both AC and PE receive defects?

<NB> Please, see above answer. The same appli= es here.


4.2. Use of PW Status notification for MPLS PSNs  

There are also sce= narios where a PE carries out PW label withdrawal
instead = of PW status notification. These include administrative
disablement of th= e PW or loss of Target LDP session with the peer
PE. [Lizhong] There is another PW/AC status signaling method by using label withdraw method when PW status notification= is not supported. Is it intentionally ignored?

=
<NB> I am not sure I understand the comment as the text you quot= ed is refering to PW label withdrawal as an alternative for status notifica= tion. Isn't that what you are referring to?


4.3. Use of BFD Diagnostic Codes

When using VCCV, the control channel (CC) type and Connectivity
Verification = (CV) Type are agreed on between the peer PEs using the
OAM capab= ility sub-TLV signaled as part of the interface parameter
TLV when usin= g FEC 129 and the interface parameter sub-TLV when
using FEC 128. &n= bsp;
[Lizhong] the "OAM capability sub-TL= V" refer to "VCCV interface parameters sub-TLV", right? Suggest to align with terminology in RFC5085.

= <NB> Will do. Here is the iterated text:
When using VCCV, the control channel (CC) type and Connectivity =
Verification (CV) Type are agreed on bet= ween the peer PEs using the 
VCCV pa= rameter field signaled as a sub-tlv of the interface parameters
<= font size=3D"2" face=3D"sans-serif" style=3D"font-family: Calibri, sans-ser= if; font-size: 14px; ">TLV when using FEC 129 and the interface parameter s= ub-TLV when 
using FEC 128.  
<NB>

5. Ethernet AC Defect Sta= tes Entry or Exit Criteria
[Lizhong] context of AC re= ceive/transmit defect entry is duplicated with that in section 2.2. Is it possible to make the context more simple, either in section 2.2 or 5.1?
<NB> There is overlap. I am proposing to merge text= related to conditions for entering the defect states in section 2.2 into 5= .1  and reduce the overlap . I believe that addresses that point. If t= hat is OK with you, I will do that and send as part of the updated document= .


6.= Ethernet AC and PW Defect States Interworking
[Lizhong] RFC2119 words sho= uld be used in this section, e.g, "must" should be "MUST".

=
<NB> Done. <NB>

6.1. PW Receive Defect Entry Procedures
[Lizhong] this section does not describe the mechanism to enter PW receive defect state, is it same with that in section 2.2?

<NB> Section 6.1 discus= ses the actions when the PE enters the PW receive defect state not the crit= eria to enter that state. However, as you pointed out section 2.2 describes= criteria for entering receive defect state. It is similar to that in RFC63= 10. That is why it wa sin section 2.2 only as a review. However, a better o= rganization would be to have a parallel section to 5.1  is. To streaml= ine things, I will do the same as proposed in the previous similar comments= . That is, merge text from section 2.2 into 6.1.  If that is OK w= ith you, I will do that and send as part of the updated document. <NB>= ;


Fu= rther, when PE1 enters the Receive Defect state, it must assume
that PE2 ha= s no knowledge of the defect and must send reverse
defect failure not= ification to PE2. For MPLS PSN or MPLS-IP PSN,
this is don= e via either a PW Status notification message indicating
a revers= e defect; or via VCCV-BFD diagnostic code of reverse defect
if VCCV CV type o= f 0x08 had been negotiated.
[Lizhong] why CV type of 0x20 is missed here?

<NB> Done. It should be as in = other places in the document. There is one additional place, where that wil= l be corrected as well. Thanks.



6.2. PW Receive Defect Exit Proc= edures
[Lizhong] this section does not describe the mechanism to exit PW receive defect state?

=
<NB> This section describes what actions must happen when the PE= exits the PW receive defect state and not what needs to happen to exit the= PW receive defect state. The PW receive and transmit defect state entry an= d exit criteria are summarized in section 2.2 and are common with what is d= escribed in RFC 6310, as highlighted in section 4  and that is why the= y were thought as being summarized and not included later. However, again I= think with the changes above, and to make it clearer  based on the co= mment, I can consolidate that in a section that says PW Receive Defect Stat= e Entry and Exit criteria, and similarly PW Transmit Defect state and Exit = criteria that parallel those of the the AC. Will that address that point? &= lt;NB>


If PW receive defect was established via notification from PE2 or
via loss of= control adjacency, no additional action is needed,
since PE2 is expected = to be aware of the defect clearing.


[Lizhong] the above description is inc= orrect in this section. The exit of PW receive defect should be described, not enter of PW receive defect.
<NB> Per above, this se= ction describes what action PE1 needs to take when it exits the receive def= ect state. It is not describing how it enters or exits the receive defect s= tate.


- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
used for f= ault notification, PE1 must transmit E-LMI asynchronous
STATUS messa= ge with report type Single EVC Asynchronous Status
indicating that = PW is Not Active.
[Lizhong] shouldn't th= e entry of PW transmit defect be signaled to remote PE? I do not see such text here.
<NB> It was assumed per section 4 to be the same in rfc= 6310 since this is failure that pertains to the PSN side. However, for com= pleteness here and consistency, I agree we should include it. I will includ= e the following per rfc 6310.
"If the PW failure was detected by PE1 without receiving reverse def=
ect notification from
      PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST
      notify PE2 by sending FDI."
<NB>

6.4. PW Transmit Defec= t Exit Procedures

- If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
transmit E-LM= I asynchronous STATUS message with report type Single
EVC Asynchronous= Status indicating that PW is Active.
[Lizhong] same comment as = for previous section, shouldn't the exit of PW transmit defect be signaled to remote PE? I do not see such text here.
<NB> Yes, and will= include the following in-line with above response:
PE1 MUST clear the FDI to PE2, if applicable=
.
<NB>
<= br>
6.5. AC Receive Defect Entry Procedures

When Native Service OAM mechanism is supported on PE1, it can also
use the NS= OAM notification as specified in Section 4.1.  
[Lizhong] is there= any relationship between notification mechanism in CE domain and mechanism in PE domain. I mean if the AC uses NS OAM to detect defect in CE domain, does NS OAM between PEs have any priority to apply?
<NB> When N= S OAM is supported PSN-facing and the fault notification functions are enab= led as described, then they are used for fault notification. Is that the qu= estion? <NB>


Nits:
There are some nit= s that need to resolve. Please check link: http://tools.ietf.o= rg/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-iwk-0= 6.txt
<NB> Yes. That will be taken care of = in the updated version. <NB>
<= br>Regards
Lizhon= g --_000_CD08F4B46DC50nabilnbitarverizoncom_-- From lizhong.jin@zte.com.cn Wed Jan 2 22:29:44 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8621F88BE; Wed, 2 Jan 2013 22:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sU+5rmJFlOC; Wed, 2 Jan 2013 22:29:42 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1921F8589; Wed, 2 Jan 2013 22:29:40 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id CA3A61273D31; Thu, 3 Jan 2013 14:31:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r036TMSh030339; Thu, 3 Jan 2013 14:29:22 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Bitar, Nabil N" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 3 Jan 2013 14:28:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-03 14:29:06, Serialize complete at 2013-01-03 14:29:06 Content-Type: multipart/alternative; boundary="=_alternative 0023A8B048257AE8_=" X-MAIL: mse02.zte.com.cn r036TMSh030339 Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" , "rtg-dir@ietf.org" , rtg-dir-bounces@ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 06:29:44 -0000 This is a multipart message in MIME format. --=_alternative 0023A8B048257AE8_= Content-Type: text/plain; charset="US-ASCII" Hi Nabil, See inline for the reply. Thank you, and happy new year. Regards Lizhong rtg-dir-bounces@ietf.org wrote 2013/01/03 00:28:27: > Hi Lizhong, > Thanks for your review and comments and sorry for a late reply. > Please, see inline. > > Thanks, > Nabil > > From: Lizhong Jin > Date: Tuesday, August 14, 2012 8:34 AM > To: "rtg-ads@tools.ietf.org" > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" < > rtg-dir@ietf.org> > Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see http://www.ietf. > org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > Reviewer: Lizhong Jin > Review Date: Aug, 14th, 2012 > IETF LC End Date: Aug, 20th, 2012 > Intended Status: Standard track > > Summary: > 1.I have some minor concerns about this document that I think should > be resolved before publication. > > Comments: > Basically, this document is well written and I believe the mechanism > has been implemented and deployed in real networks. There are only > some parts of the document that need to be clarified to avoid > misunderstanding. > > Major Issues: > No major issues found. > > Minor Issues: > 2.2. Abstract Defect States > A PW forward defect indication received on PE1 impacts the ability > of PE1 to receive traffic on the PW. > [Lizhong] "PW forward defect" only refers to one mechanism above, > should it be "PW receive defect"? > > PE1 receives a a forward defect indication and enters the > receive defect state. That is really what is in the text now. This > terminology is also used in RFC 6310. The text as it is is correct > and consistent. [Lizhong] OK. > > > 4.1. Use of Native Service (NS) Notification > > - Sending of AIS frames from the local MEP to the MEP on the > remote PE when the MEP needs to convey PE receive defects, and when > CCM transmission is disabled. > [Lizhong] "PE receive defects" refer to PE AC receive defects or > both AC and PE receive defects? > > > Section 4.1 lists the mechanisms used for fault notification on the > PSN side only upfront. > Section 6.1 "PW Receive Defect entry procedures" specified how the > mechanisms in section 4.1 can be used when receive defect is > detected on the PW. Please, look at the paragraph before last in that section. > Section 6.5 "AC Receive Defect Entry Procedures" describes how the > mechanisms used in section 4.1 are used when AC receive defect state > is entered. Please, look at the 4th paragraph in that section. > [Lizhong] I am OK now. Thanks. > > - Suspension of CCM frames transmission from the local MEP to > the peer MEP on the remote PE to convey PE receive defects, when > CCM transmission is enabled. > [Lizhong] "PE receive defects" refer to PE AC receive defects or > both AC and PE receive defects? > > Please, see above answer. The same applies here. [Lizhong] OK. > > > 4.2. Use of PW Status notification for MPLS PSNs > > There are also scenarios where a PE carries out PW label withdrawal > instead of PW status notification. These include administrative > disablement of the PW or loss of Target LDP session with the peer > PE. > [Lizhong] There is another PW/AC status signaling method by using > label withdraw method when PW status notificationis not supported. > Is it intentionally ignored? > > I am not sure I understand the comment as the text you quoted > is refering to PW label withdrawal as an alternative for status > notification. Isn't that what you are referring to? [Lizhong] yes. I am not proposing to add PW label withdrawal, but want to know why it is not considered here. > > > 4.3. Use of BFD Diagnostic Codes > > When using VCCV, the control channel (CC) type and Connectivity > Verification (CV) Type are agreed on between the peer PEs using the > OAM capability sub-TLV signaled as part of the interface parameter > TLV when using FEC 129 and the interface parameter sub-TLV when > using FEC 128. > [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface > parameters sub-TLV", right? Suggest to align with terminology in RFC5085. > > Will do. Here is the iterated text: > When using VCCV, the control channel (CC) type and Connectivity > Verification (CV) Type are agreed on between the peer PEs using the > VCCV parameter field signaled as a sub-tlv of the interface parameters > TLV when using FEC 129 and the interface parameter sub-TLV when > using FEC 128. > [Lizhong] good, thanks. > > 5. Ethernet AC Defect States Entry or Exit Criteria > [Lizhong] context of AC receive/transmit defect entry is duplicated > with that in section 2.2. Is it possible to make the context more > simple, either in section 2.2 or 5.1? > > There is overlap. I am proposing to merge text related to > conditions for entering the defect states in section 2.2 into 5.1 > and reduce the overlap . I believe that addresses that point. If > that is OK with you, I will do that and send as part of the updated document. [Lizhong] that's good, thanks. > > > 6. Ethernet AC and PW Defect States Interworking > [Lizhong] RFC2119 words should be used in this section, e.g, "must" > should be "MUST". > > Done. [Lizhong] thanks. > > > 6.1. PW Receive Defect Entry Procedures > [Lizhong] this section does not describe the mechanism to enter PW > receive defect state, is it same with that in section 2.2? > > Section 6.1 discusses the actions when the PE enters the PW > receive defect state not the criteria to enter that state. However, > as you pointed out section 2.2 describes criteria for entering > receive defect state. It is similar to that in RFC6310. That is why > it wa sin section 2.2 only as a review. However, a better > organization would be to have a parallel section to 5.1 is. To > streamline things, I will do the same as proposed in the previous > similar comments. That is, merge text from section 2.2 into 6.1. If > that is OK with you, I will do that and send as part of the updated > document. [Lizhong] that's good, thanks. > > > Further, when PE1 enters the Receive Defect state, it must assume > that PE2 has no knowledge of the defect and must send reverse > defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, > this is done via either a PW Status notification message indicating > a reverse defect; or via VCCV-BFD diagnostic code of reverse defect > if VCCV CV type of 0x08 had been negotiated. > [Lizhong] why CV type of 0x20 is missed here? > > Done. It should be as in other places in the document. There is > one additional place, where that will be corrected as well. Thanks. [Lizhong] good, thanks. > > > > 6.2. PW Receive Defect Exit Procedures > [Lizhong] this section does not describe the mechanism to exit PW > receive defect state? > > This section describes what actions must happen when the PE > exits the PW receive defect state and not what needs to happen to > exit the PW receive defect state. The PW receive and transmit defect > state entry and exit criteria are summarized in section 2.2 and are > common with what is described in RFC 6310, as highlighted in section > 4 and that is why they were thought as being summarized and not > included later. However, again I think with the changes above, and > to make it clearer based on the comment, I can consolidate that in > a section that says PW Receive Defect State Entry and Exit criteria, > and similarly PW Transmit Defect state and Exit criteria that > parallel those of the the AC. Will that address that point? [Lizhong] that's good. > > > If PW receive defect was established via notification from PE2 or > via loss of control adjacency, no additional action is needed, > since PE2 is expected to be aware of the defect clearing. > > > [Lizhong] the above description is incorrect in this section. The > exit of PW receive defect should be described, not enter of PW receive defect. > Per above, this section describes what action PE1 needs to take > when it exits the receive defect state. It is not describing how it > enters or exits the receive defect state. [Lizhong] I see, ok with that. > > > 6.3. PW Transmit Defect Entry Procedures > > - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is > used for fault notification, PE1 must transmit E-LMI asynchronous > STATUS message with report type Single EVC Asynchronous Status > indicating that PW is Not Active. > [Lizhong] shouldn't the entry of PW transmit defect be signaled to > remote PE? I do not see such text here. > It was assumed per section 4 to be the same in rfc 6310 since > this is failure that pertains to the PSN side. However, for > completeness here and consistency, I agree we should include it. I > will include the following per rfc 6310. > "If the PW failure was detected by PE1 without receiving reverse > defect notification from > PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST > notify PE2 by sending FDI." > [Lizhong] that's good, thanks. > > 6.4. PW Transmit Defect Exit Procedures > > - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must > transmit E-LMI asynchronous STATUS message with report type Single > EVC Asynchronous Status indicating that PW is Active. > [Lizhong] same comment as for previous section, shouldn't the exit > of PW transmit defect be signaled to remote PE? I do not see such text here. > Yes, and will include the following in-line with above response: > PE1 MUST clear the FDI to PE2, if applicable. > [Lizhong] that's good, thanks. > > > 6.5. AC Receive Defect Entry Procedures > > When Native Service OAM mechanism is supported on PE1, it can also > use the NS OAM notification as specified in Section 4.1. > [Lizhong] is there any relationship between notification mechanism > in CE domain and mechanism in PE domain. I mean if the AC uses NS > OAM to detect defect in CE domain, does NS OAM between PEs have any > priority to apply? > When NS OAM is supported PSN-facing and the fault notification > functions are enabled as described, then they are used for fault > notification. Is that the question? [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are supported on the PE, which one should be applied? Is there any priority among the three? > > > Nits: > There are some nits that need to resolve. Please check link: http: > //tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf- > pwe3-mpls-eth-oam-iwk-06.txt > Yes. That will be taken care of in the updated version. [Lizhong] thank you. > > Regards > Lizhong --=_alternative 0023A8B048257AE8_= Content-Type: text/html; charset="US-ASCII"
Hi Nabil,
See inline for the reply. Thank you, and happy new year.

Regards
Lizhong
 

rtg-dir-bounces@ietf.org wrote 2013/01/03 00:28:27:

> Hi Lizhong,
> Thanks for your review and comments and sorry for a late reply.
> Please, see inline.
>
> Thanks,
> Nabil
>
> From: Lizhong Jin <lizhong.jin@zte.com.cn>
> Date: Tuesday, August 14, 2012 8:34 AM
> To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
> Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" <draft-
> ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" <
> rtg-dir@ietf.org>
> Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
>
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review
> is to provide assistance to the Routing ADs. For more information
> about the Routing Directorate, please see http://www.ietf.
> org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
> Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
> Reviewer: Lizhong Jin
> Review Date: Aug, 14th, 2012
> IETF LC End Date: Aug, 20th, 2012
> Intended Status: Standard track
>
> Summary:
> 1.I have some minor concerns about this document that I think should
> be resolved before publication.
>
> Comments:
> Basically, this document is well written and I believe the mechanism
> has been implemented and deployed in real networks. There are only
> some parts of the document that need to be clarified to avoid
> misunderstanding.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
> 2.2.  Abstract Defect States
> A PW forward defect indication received on PE1 impacts the ability
> of PE1 to receive traffic on the PW.
> [Lizhong] "PW forward defect" only refers to one mechanism above,
> should it be "PW receive defect"?
>
> <NB> PE1 receives a a forward defect indication  and enters the
> receive defect state. That is really what is in the text now. This
> terminology is also used in RFC 6310. The text as it is is correct
> and consistent. <NB>
[Lizhong] OK.
>
>  
> 4.1. Use of Native Service (NS) Notification  
>
>     - Sending of AIS frames from the local MEP to the MEP on the
> remote PE when the MEP needs to convey PE receive defects, and when
> CCM transmission is disabled.  
> [Lizhong] "PE receive defects" refer to PE AC receive defects or
> both AC and PE receive defects?
>
> <NB>
>  Section 4.1 lists the mechanisms used for fault notification on the
> PSN side only upfront.
> Section 6.1 "PW Receive Defect entry procedures" specified how the
> mechanisms in section 4.1 can be used when receive defect is
> detected on the PW. Please, look at the paragraph before last in that section.
> Section 6.5 "AC Receive Defect Entry Procedures" describes how the
> mechanisms used in section 4.1 are used when AC receive defect state
> is entered. Please, look at the 4th paragraph in that section.
> <NB>
[Lizhong] I am OK now. Thanks.

>  
>     - Suspension of CCM frames transmission from the local MEP to
> the peer MEP on the remote PE to convey PE receive defects, when
> CCM transmission is enabled.  
> [Lizhong] "PE receive defects" refer to PE AC receive defects or
> both AC and PE receive defects?
>
> <NB> Please, see above answer. The same applies here.
[Lizhong] OK.
>
>
> 4.2. Use of PW Status notification for MPLS PSNs  
>
> There are also scenarios where a PE carries out PW label withdrawal
> instead of PW status notification. These include administrative
> disablement of the PW or loss of Target LDP session with the peer
> PE.
> [Lizhong] There is another PW/AC status signaling method by using
> label withdraw method when PW status notificationis not supported.
> Is it intentionally ignored?
>
> <NB> I am not sure I understand the comment as the text you quoted
> is refering to PW label withdrawal as an alternative for status
> notification. Isn't that what you are referring to?
[Lizhong] yes. I am not proposing to add PW label withdrawal, but want to know why it is not considered here.
>
>
> 4.3. Use of BFD Diagnostic Codes
>
> When using VCCV, the control channel (CC) type and Connectivity
> Verification (CV) Type are agreed on between the peer PEs using the
> OAM capability sub-TLV signaled as part of the interface parameter
> TLV when using FEC 129 and the interface parameter sub-TLV when
> using FEC 128.  
> [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface
> parameters sub-TLV", right? Suggest to align with terminology in RFC5085.
>
> <NB> Will do. Here is the iterated text:
> When using VCCV, the control channel (CC) type and Connectivity
> Verification (CV) Type are agreed on between the peer PEs using the
> VCCV parameter field signaled as a sub-tlv of the interface parameters
> TLV when using FEC 129 and the interface parameter sub-TLV when
> using FEC 128.  
> <NB>
[Lizhong] good, thanks.

>
> 5. Ethernet AC Defect States Entry or Exit Criteria
> [Lizhong] context of AC receive/transmit defect entry is duplicated
> with that in section 2.2. Is it possible to make the context more
> simple, either in section 2.2 or 5.1?
>
> <NB> There is overlap. I am proposing to merge text related to
> conditions for entering the defect states in section 2.2 into 5.1  
> and reduce the overlap . I believe that addresses that point. If
> that is OK with you, I will do that and send as part of the updated document.
[Lizhong] that's good, thanks.
>
>
> 6. Ethernet AC and PW Defect States Interworking
> [Lizhong] RFC2119 words should be used in this section, e.g, "must"
> should be "MUST".
>
> <NB> Done. <NB>
[Lizhong] thanks.
>
>
> 6.1. PW Receive Defect Entry Procedures
> [Lizhong] this section does not describe the mechanism to enter PW
> receive defect state, is it same with that in section 2.2?
>
> <NB> Section 6.1 discusses the actions when the PE enters the PW
> receive defect state not the criteria to enter that state. However,
> as you pointed out section 2.2 describes criteria for entering
> receive defect state. It is similar to that in RFC6310. That is why
> it wa sin section 2.2 only as a review. However, a better
> organization would be to have a parallel section to 5.1  is. To
> streamline things, I will do the same as proposed in the previous
> similar comments. That is, merge text from section 2.2 into 6.1.  If
> that is OK with you, I will do that and send as part of the updated
> document. <NB>
[Lizhong] that's good, thanks.
>
>
> Further, when PE1 enters the Receive Defect state, it must assume
> that PE2 has no knowledge of the defect and must send reverse
> defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN,
> this is done via either a PW Status notification message indicating
> a reverse defect; or via VCCV-BFD diagnostic code of reverse defect
> if VCCV CV type of 0x08 had been negotiated.
> [Lizhong] why CV type of 0x20 is missed here?
>
> <NB> Done. It should be as in other places in the document. There is
> one additional place, where that will be corrected as well. Thanks.
[Lizhong] good, thanks.
>
>
>
> 6.2. PW Receive Defect Exit Procedures
> [Lizhong] this section does not describe the mechanism to exit PW
> receive defect state?
>
> <NB> This section describes what actions must happen when the PE
> exits the PW receive defect state and not what needs to happen to
> exit the PW receive defect state. The PW receive and transmit defect
> state entry and exit criteria are summarized in section 2.2 and are
> common with what is described in RFC 6310, as highlighted in section
> 4  and that is why they were thought as being summarized and not
> included later. However, again I think with the changes above, and
> to make it clearer  based on the comment, I can consolidate that in
> a section that says PW Receive Defect State Entry and Exit criteria,
> and similarly PW Transmit Defect state and Exit criteria that
> parallel those of the the AC. Will that address that point? <NB>
[Lizhong] that's good.

>
>
> If PW receive defect was established via notification from PE2 or
> via loss of control adjacency, no additional action is needed,
> since PE2 is expected to be aware of the defect clearing.
>
>
> [Lizhong] the above description is incorrect in this section. The
> exit of PW receive defect should be described, not enter of PW receive defect.
> <NB> Per above, this section describes what action PE1 needs to take
> when it exits the receive defect state. It is not describing how it
> enters or exits the receive defect state.
[Lizhong] I see, ok with that.
>
>
> 6.3. PW Transmit Defect Entry Procedures
>
> - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
> used for fault notification, PE1 must transmit E-LMI asynchronous
> STATUS message with report type Single EVC Asynchronous Status
> indicating that PW is Not Active.
> [Lizhong] shouldn't the entry of PW transmit defect be signaled to
> remote PE? I do not see such text here.
> <NB> It was assumed per section 4 to be the same in rfc 6310 since
> this is failure that pertains to the PSN side. However, for
> completeness here and consistency, I agree we should include it. I
> will include the following per rfc 6310.
> "If the PW failure was detected by PE1 without receiving reverse
> defect notification from
>       PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST
>       notify PE2 by sending FDI."
> <NB>
[Lizhong] that's good, thanks.

>
> 6.4. PW Transmit Defect Exit Procedures
>
> - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
> transmit E-LMI asynchronous STATUS message with report type Single
> EVC Asynchronous Status indicating that PW is Active.
> [Lizhong] same comment as for previous section, shouldn't the exit
> of PW transmit defect be signaled to remote PE? I do not see such text here.
> <NB> Yes, and will include the following in-line with above response:
> PE1 MUST clear the FDI to PE2, if applicable.
> <NB>
[Lizhong] that's good, thanks.

>
>
> 6.5. AC Receive Defect Entry Procedures
>
> When Native Service OAM mechanism is supported on PE1, it can also
> use the NS OAM notification as specified in Section 4.1.  
> [Lizhong] is there any relationship between notification mechanism
> in CE domain and mechanism in PE domain. I mean if the AC uses NS
> OAM to detect defect in CE domain, does NS OAM between PEs have any
> priority to apply?
> <NB> When NS OAM is supported PSN-facing and the fault notification
> functions are enabled as described, then they are used for fault
> notification. Is that the question? <NB>
[Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are supported on the PE, which one should be applied? Is there any priority among the three?
>
>
> Nits:
> There are some nits that need to resolve. Please check link: http:
> //tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-
> pwe3-mpls-eth-oam-iwk-06.txt
> <NB> Yes. That will be taken care of in the updated version. <NB>
[Lizhong] thank you.
>
> Regards
> Lizhong --=_alternative 0023A8B048257AE8_=-- From hejia@huawei.com Fri Jan 4 01:39:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251A821F8EBD; Fri, 4 Jan 2013 01:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=2.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKvZXCeWtYp1; Fri, 4 Jan 2013 01:39:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B721F8EBC; Fri, 4 Jan 2013 01:39:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANE70316; Fri, 04 Jan 2013 09:39:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 09:38:19 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 17:39:15 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.68]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 17:37:44 +0800 From: "Hejia (Jia)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-itu-t-identifiers-06.txt Thread-Index: Ac3qXyTvBrQwmw89THOMUM0w8Qx7SQ== Date: Fri, 4 Jan 2013 09:37:43 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF640C9@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: multipart/alternative; boundary="_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-itu-t-identifiers-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 09:39:39 -0000 --_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-tp-itu-t-identifiers-06.txt Reviewer: Jia He Review Date: Jan 4, 2013 IETF LC End Date: Jan 4, 2013 Intended Status: Standards Track Summary: I have one minor concern about this document that I think should be resolve= d before publication. Comments: The document is well structured and easy to understand. It is a useful draf= t that complements the MPLS-TP draft set. Major Issues: No major issues found. Minor Issues: 1) Section 7, the description of "maintenance entities" needs review. Section 7 has the following description about "maintenance entities", which= confusingly implies that MEPs or MIPs are MEs. These maintenance entities can be e.g. Maintenance Entity Group End Points (MEPs) or Maintenance Entity Group Intermediate Points (MIPs). However, there is explicit definition of "maintenance entity" in RFC 6371 (= see below), which indicates a relationship, not separately MEPs or MIPs. Maintenance Entity (ME): Some portion of a transport path that requires management bounded by two points (called MEPs), and the relationship between those points to which maintenance and monitoring operations apply Therefore, it is suggested to replace the sentence "These maintenance entit= ies can be..." with the definition of MEPs and MIPs in RFC 6371, or remove = all the definition description of MEGs, MEPs and MIPs in this paragraph and= refer to RFC 6371. Nits: Section 6 s/In stead of/Instead of Section 7 s/enties/entities Section 7.1 s/CC:ICC:UMC/CC::ICC::UMC B.R. Jia --_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been selected as the Rou= ting Directorate reviewer for this draft. The Routing Directorate seeks to = review all routing or routing-related drafts as they pass through IETF last= call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to = the Routing ADs. For more information about the Routing Directorate, please= see http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are pri= marily for the use of the Routing ADs, it would be helpful if you could con= sider them along with any other IETF Last Call comments that you receive, a= nd strive to resolve them through discussion or by updating the draft.

 

Document: draft-ietf-mpls-tp-it= u-t-identifiers-06.txt

Reviewer: Jia He

Review Date: Jan 4, 2013 <= /o:p>

IETF LC End Date: Jan 4, 2013 <= o:p>

 

Intended Status: Standards Trac= k

 

Summary:

 

I have one minor concern about = this document that I think should be resolved before publication.

 

Comments:

 

The document is well structured= and easy to understand. It is a useful draft that complements the MPLS-TP = draft set.

 

 

Major Issues:

No major issues found.

 

 

Minor Issues:

 

1) Section 7, the description o= f "maintenance entities" needs review.

 

Section 7 has the following des= cription about "maintenance entities", which confusingly implies = that MEPs or MIPs are MEs.

 

   These maintenance = entities can be e.g.  Maintenance

   Entity Group End P= oints (MEPs) or Maintenance Entity Group

   Intermediate Point= s (MIPs). 

 

However, there is explicit defi= nition of "maintenance entity" in RFC 6371 (see below), which ind= icates a relationship, not separately MEPs or MIPs.

 

   Maintenance Entity= (ME): Some portion of a transport path that

   requires managemen= t bounded by two points (called MEPs), and the

   relationship be= tween those points to which maintenance and monitoring

   operations apply

 

Therefore, it is suggested to r= eplace the sentence "These maintenance entities can be..." with t= he definition of MEPs and MIPs in RFC 6371, or remove all the definition de= scription of MEGs, MEPs and MIPs in this paragraph and refer to RFC 6371.

 

 

Nits:

 

Section 6

s/In stead of/Instead of

 

Section 7

s/enties/entities

 

Section 7.1

s/CC:ICC:UMC/CC::ICC::UMC<= /o:p>

 

 

 

B.R.

Jia

--_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_-- From nabil.n.bitar@verizon.com Fri Jan 4 10:12:47 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A18F21F8797; Fri, 4 Jan 2013 10:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXXXaJP4i1gQ; Fri, 4 Jan 2013 10:12:45 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7621F84EA; Fri, 4 Jan 2013 10:12:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 04 Jan 2013 18:12:40 +0000 From: "Bitar, Nabil N" To: Lizhong Jin , "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.84,411,1355097600"; d="scan'208,217";a="390317648" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi02.verizon.com with ESMTP; 04 Jan 2013 18:12:40 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Fri, 4 Jan 2013 13:12:40 -0500 Date: Fri, 4 Jan 2013 13:12:26 -0500 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Thread-Index: Ac3qpxVb0hPT131CQEGU3yqMaa+eoQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD0BB69D6E640nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-dir-bounces@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:12:47 -0000 --_000_CD0BB69D6E640nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks. Happy new year to you as well. Thanks for below. I am copying the only comment you still have from the bel= ow email: > When NS OAM is supported PSN-facing and the fault notification > functions are enabled as described, then they are used for fault > notification. Is that the question? [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are suppor= ted on the PE, which one should be applied? Is there any priority among the= three? > There is no priority defined among the three. On the PSN-facing side,= if all three are enabled for fault defection and notification (I don;t see= why all 3 would be enabled). The text says that how each of them can be us= ed for failure notification. A failure notification by any of the mechanism= s will bring the service down. Thanks, Nabil From: Lizhong Jin > Date: Thursday, January 3, 2013 1:28 AM To: "Bitar, Nabil N" > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" >, "rtg-ads@tools.ietf.org" >, "rtg-dir@ietf.org" >, "rtg-dir-bounce= s@ietf.org" > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.t= xt Hi Nabil, See inline for the reply. Thank you, and happy new year. Regards Lizhong rtg-dir-bounces@ietf.org wrote 2013/01/03 = 00:28:27: > Hi Lizhong, > Thanks for your review and comments and sorry for a late reply. > Please, see inline. > > Thanks, > Nabil > > From: Lizhong Jin > > Date: Tuesday, August 14, 2012 8:34 AM > To: "rtg-ads@tools.ietf.org" > > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" < > rtg-dir@ietf.org> > Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see http://www.ietf. > org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > Reviewer: Lizhong Jin > Review Date: Aug, 14th, 2012 > IETF LC End Date: Aug, 20th, 2012 > Intended Status: Standard track > > Summary: > 1.I have some minor concerns about this document that I think should > be resolved before publication. > > Comments: > Basically, this document is well written and I believe the mechanism > has been implemented and deployed in real networks. There are only > some parts of the document that need to be clarified to avoid > misunderstanding. > > Major Issues: > No major issues found. > > Minor Issues: > 2.2. Abstract Defect States > A PW forward defect indication received on PE1 impacts the ability > of PE1 to receive traffic on the PW. > [Lizhong] "PW forward defect" only refers to one mechanism above, > should it be "PW receive defect"? > > PE1 receives a a forward defect indication and enters the > receive defect state. That is really what is in the text now. This > terminology is also used in RFC 6310. The text as it is is correct > and consistent. [Lizhong] OK. > > > 4.1. Use of Native Service (NS) Notification > > - Sending of AIS frames from the local MEP to the MEP on the > remote PE when the MEP needs to convey PE receive defects, and when > CCM transmission is disabled. > [Lizhong] "PE receive defects" refer to PE AC receive defects or > both AC and PE receive defects? > > > Section 4.1 lists the mechanisms used for fault notification on the > PSN side only upfront. > Section 6.1 "PW Receive Defect entry procedures" specified how the > mechanisms in section 4.1 can be used when receive defect is > detected on the PW. Please, look at the paragraph before last in that sec= tion. > Section 6.5 "AC Receive Defect Entry Procedures" describes how the > mechanisms used in section 4.1 are used when AC receive defect state > is entered. Please, look at the 4th paragraph in that section. > [Lizhong] I am OK now. Thanks. > > - Suspension of CCM frames transmission from the local MEP to > the peer MEP on the remote PE to convey PE receive defects, when > CCM transmission is enabled. > [Lizhong] "PE receive defects" refer to PE AC receive defects or > both AC and PE receive defects? > > Please, see above answer. The same applies here. [Lizhong] OK. > > > 4.2. Use of PW Status notification for MPLS PSNs > > There are also scenarios where a PE carries out PW label withdrawal > instead of PW status notification. These include administrative > disablement of the PW or loss of Target LDP session with the peer > PE. > [Lizhong] There is another PW/AC status signaling method by using > label withdraw method when PW status notificationis not supported. > Is it intentionally ignored? > > I am not sure I understand the comment as the text you quoted > is refering to PW label withdrawal as an alternative for status > notification. Isn't that what you are referring to? [Lizhong] yes. I am not proposing to add PW label withdrawal, but want to k= now why it is not considered here. > > > 4.3. Use of BFD Diagnostic Codes > > When using VCCV, the control channel (CC) type and Connectivity > Verification (CV) Type are agreed on between the peer PEs using the > OAM capability sub-TLV signaled as part of the interface parameter > TLV when using FEC 129 and the interface parameter sub-TLV when > using FEC 128. > [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface > parameters sub-TLV", right? Suggest to align with terminology in RFC5085. > > Will do. Here is the iterated text: > When using VCCV, the control channel (CC) type and Connectivity > Verification (CV) Type are agreed on between the peer PEs using the > VCCV parameter field signaled as a sub-tlv of the interface parameters > TLV when using FEC 129 and the interface parameter sub-TLV when > using FEC 128. > [Lizhong] good, thanks. > > 5. Ethernet AC Defect States Entry or Exit Criteria > [Lizhong] context of AC receive/transmit defect entry is duplicated > with that in section 2.2. Is it possible to make the context more > simple, either in section 2.2 or 5.1? > > There is overlap. I am proposing to merge text related to > conditions for entering the defect states in section 2.2 into 5.1 > and reduce the overlap . I believe that addresses that point. If > that is OK with you, I will do that and send as part of the updated docum= ent. [Lizhong] that's good, thanks. > > > 6. Ethernet AC and PW Defect States Interworking > [Lizhong] RFC2119 words should be used in this section, e.g, "must" > should be "MUST". > > Done. [Lizhong] thanks. > > > 6.1. PW Receive Defect Entry Procedures > [Lizhong] this section does not describe the mechanism to enter PW > receive defect state, is it same with that in section 2.2? > > Section 6.1 discusses the actions when the PE enters the PW > receive defect state not the criteria to enter that state. However, > as you pointed out section 2.2 describes criteria for entering > receive defect state. It is similar to that in RFC6310. That is why > it wa sin section 2.2 only as a review. However, a better > organization would be to have a parallel section to 5.1 is. To > streamline things, I will do the same as proposed in the previous > similar comments. That is, merge text from section 2.2 into 6.1. If > that is OK with you, I will do that and send as part of the updated > document. [Lizhong] that's good, thanks. > > > Further, when PE1 enters the Receive Defect state, it must assume > that PE2 has no knowledge of the defect and must send reverse > defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, > this is done via either a PW Status notification message indicating > a reverse defect; or via VCCV-BFD diagnostic code of reverse defect > if VCCV CV type of 0x08 had been negotiated. > [Lizhong] why CV type of 0x20 is missed here? > > Done. It should be as in other places in the document. There is > one additional place, where that will be corrected as well. Thanks. [Lizhong] good, thanks. > > > > 6.2. PW Receive Defect Exit Procedures > [Lizhong] this section does not describe the mechanism to exit PW > receive defect state? > > This section describes what actions must happen when the PE > exits the PW receive defect state and not what needs to happen to > exit the PW receive defect state. The PW receive and transmit defect > state entry and exit criteria are summarized in section 2.2 and are > common with what is described in RFC 6310, as highlighted in section > 4 and that is why they were thought as being summarized and not > included later. However, again I think with the changes above, and > to make it clearer based on the comment, I can consolidate that in > a section that says PW Receive Defect State Entry and Exit criteria, > and similarly PW Transmit Defect state and Exit criteria that > parallel those of the the AC. Will that address that point? [Lizhong] that's good. > > > If PW receive defect was established via notification from PE2 or > via loss of control adjacency, no additional action is needed, > since PE2 is expected to be aware of the defect clearing. > > > [Lizhong] the above description is incorrect in this section. The > exit of PW receive defect should be described, not enter of PW receive de= fect. > Per above, this section describes what action PE1 needs to take > when it exits the receive defect state. It is not describing how it > enters or exits the receive defect state. [Lizhong] I see, ok with that. > > > 6.3. PW Transmit Defect Entry Procedures > > - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is > used for fault notification, PE1 must transmit E-LMI asynchronous > STATUS message with report type Single EVC Asynchronous Status > indicating that PW is Not Active. > [Lizhong] shouldn't the entry of PW transmit defect be signaled to > remote PE? I do not see such text here. > It was assumed per section 4 to be the same in rfc 6310 since > this is failure that pertains to the PSN side. However, for > completeness here and consistency, I agree we should include it. I > will include the following per rfc 6310. > "If the PW failure was detected by PE1 without receiving reverse > defect notification from > PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST > notify PE2 by sending FDI." > [Lizhong] that's good, thanks. > > 6.4. PW Transmit Defect Exit Procedures > > - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must > transmit E-LMI asynchronous STATUS message with report type Single > EVC Asynchronous Status indicating that PW is Active. > [Lizhong] same comment as for previous section, shouldn't the exit > of PW transmit defect be signaled to remote PE? I do not see such text he= re. > Yes, and will include the following in-line with above response: > PE1 MUST clear the FDI to PE2, if applicable. > [Lizhong] that's good, thanks. > > > 6.5. AC Receive Defect Entry Procedures > > When Native Service OAM mechanism is supported on PE1, it can also > use the NS OAM notification as specified in Section 4.1. > [Lizhong] is there any relationship between notification mechanism > in CE domain and mechanism in PE domain. I mean if the AC uses NS > OAM to detect defect in CE domain, does NS OAM between PEs have any > priority to apply? > When NS OAM is supported PSN-facing and the fault notification > functions are enabled as described, then they are used for fault > notification. Is that the question? [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are suppor= ted on the PE, which one should be applied? Is there any priority among the= three? > > > Nits: > There are some nits that need to resolve. Please check link: http: > //tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf- > pwe3-mpls-eth-oam-iwk-06.txt > Yes. That will be taken care of in the updated version. [Lizhong] thank you. > > Regards > Lizhong --_000_CD0BB69D6E640nabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
Thanks. Ha= ppy new year to you as well. 
Thanks for below. I am copying= the only comment you still have from the below email:

=
> <NB> When NS OAM is su= pported PSN-facing and the fault notification 
> functions are e= nabled as described, then they are used for fault 
> notificatio= n. Is that the question? <NB> 
[Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW s= tatus are supported on the PE, which one should be applied? Is there any pr= iority among the three?
>=  

<NB2> There is no priori= ty defined among the three. On the PSN-facing side, if all three are enable= d for fault defection and notification (I don;t see why all 3 would be enab= led). The text says that how each of them can be used for failure notificat= ion. A failure notification by any of the mechanisms will bring the service= down.

Thanks,
Nabil

From: Lizhong Jin <lizhong.jin@zte.com.cn>
Date: Thursday, January 3, 2013 1:28 AM
To: "Bitar, Nabil N" <nabil.n.bitar@one.verizon.com>Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk= .all@tools.ietf.org" <draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.or= g>, "rtg-ads@tools.ietf.or= g" <rtg-ads@tools.ietf.org= >, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-dir-bounces@ietf.org" <rtg-dir-bounces@ietf.org>
Subject: Re: [RTG-DIR] RtgDir review: dr= aft-ietf-pwe3-mpls-eth-oam-iwk-06.txt


<= font size=3D"2" face=3D"sans-serif">Hi Nabil,
See inline for the reply. Thank you, and happy new year.=

Regards
Lizhong
 

= rtg-dir-bounces@ietf.org wr= ote 2013/01/03 00:28:27:

> Hi Lizhong,
> Thank= s for your review and comments and sorry for a late reply.
> Please, see inline.
&g= t;
> Thanks,
> Nabil
>
> From: Lizhong Jin <lizhon= g.jin@zte.com.cn>
> Date: Tuesday, August 14, 2012 8:34 AM
> To: "rtg-ads@tools.ietf.org<= /a>" <rtg-ads@tools.ietf.org>
> Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" <draft- > ietf-= pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" <
> rtg-dir@ietf.org>
> Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.= txt
>
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
= > draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information
= > about the Routing Directorate, please see = http://www.ietf.
> org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
> Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
> Reviewer: Lizhong Jin
> Review Date: Aug, 14th, 2012
> IETF LC End Date: Aug, 20th, 2012
> Intended Status: Standard track
>
> Summary:
> 1.I have some minor concerns about this document that I think should > be resolved before publication.
>
> Comments:
> Basically, this document is well written and I believe the mechanism > has been implemented and deployed in real networks. There are only > some parts of the document that need to be clarified to avoid
> misunderstanding.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
> 2.2.  Abstract Defect States
> A PW forward defect indication received on PE1 impacts the ability > of PE1 to receive traffic on the PW.
> [Lizhong] "PW forward defect" only refers to one mechanism above,
= > should it be "PW receive defect"?
>
> <NB> PE1 receives a a forward defect indication  and enters= the
> receive defect state. That is really what is in the text now. This > terminology is also used in RFC 6310. The text as it is is correct > and consistent. <NB>
[Lizhong] OK.
> >  
> 4.1. Use of Native Service (NS) Notification  
>
>     - Sending of AIS frames from the local MEP to the MEP on= the
> remote PE when the MEP needs to convey PE receive defects, and when > CCM transmission is disabled.  
> [Lizhong] "PE receive defects" refer to PE AC receive defects or
> both AC and PE receive defects?
>
> <NB>
>  = Section 4.1 lists the mechanisms used for fault notification on the
> PSN side only upfront.
> Section 6.1 "PW Receive Defect entry procedures" specified how the
> mechanisms in section 4.1 can be used when receive defect is
> detected on the PW. Please, look at the paragraph before last in that = section.
> Section 6.5 "A= C Receive Defect Entry Procedures" describes how the
> mechanisms used in section 4.1 are used when AC receive defect state > is entered. Please, look at the 4th paragraph in that section. =
> <NB>
[Lizhong] I am OK now. Thanks.
>  
>     - Suspension of CCM frames transm= ission from the local MEP to
> the peer MEP on the remote PE to convey PE receive defects, when
> CCM transmission is enabled.  
> [Lizhong] "PE receive defects" refer to PE AC receive defects or
> both AC and PE receive defects?
>
> <NB> Please, see above answer. The same applies here. [Lizhong] OK.
>
>
> 4.2. Use of PW Status notification for MPLS PSNs  
>
> There are also scenarios where a PE carries out PW label withdrawal > instead of PW status notification. These include administrative
> disablement of the PW or loss of Target LDP session with the peer
= > PE.
> [Lizhong] There is another PW/AC status signaling method by using
= > label withdraw method when PW status notificationis not supported. > Is it intentionally ignored?
>
> <NB> I am not sure I understand the comment as the text you quot= ed
> is refering to PW label withdrawal as an alternative for status
> notification. Isn't that what you are referring to?
[Lizhong] yes. I am not proposing to add PW l= abel withdrawal, but want to know why it is not considered here.
= >
>
> 4.3. Use of BFD Diagnostic Codes
>
> When using VCCV, the control channel (CC) type and Connectivity
> Verification (CV) Type are agreed on between the peer PEs using the > OAM capability sub-TLV signaled as part of the interface parameter > TLV when using FEC 129 and the interface parameter sub-TLV when
> using FEC 128.  
> [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface
> parameters sub-TLV", right? Suggest to align with terminology in RFC50= 85.
>
> <NB> Will do. Here is the iterated text:
> When using VCCV, the control channel (CC) t= ype and Connectivity
> Verification (CV) Type are agreed on between the peer PEs using the > VCCV parameter field signaled as a sub-tlv of the interface parameters=
> TLV when using FEC 129 and the interface parameter sub-TLV when
> using FEC 128.  
= > <NB>
[Lizhong] g= ood, thanks.

>
> 5. Ethernet AC Defect States Entry or Exit Criteria
> [Lizhong] context of AC receive/transmit defect entry is duplicated > with that in section 2.2. Is it possible to make the context more
= > simple, either in section 2.2 or 5.1?
>
> <NB> There is overlap. I am proposing to merge text related to <= br> > conditions for entering the defect states in section 2.2 into 5.1 &nbs= p;
> and reduce the overlap . I believe that addresses that point. If
> that is OK with you, I will do that and send as part of the updated do= cument.
[Lizhong] that's goo= d, thanks.
>
>
> 6. Ethernet AC and PW Defect States Interworking
> [Lizhong] RFC2119 words should be used in this section, e.g, "must" > should be "MUST".
>=
> <NB> Done. <NB>
[Lizhong] thanks.
>= ;
>
> 6.1. PW Receive Defect Entry Procedures
> [Lizhong] this section does not describe the mechanism to enter PW > receive defect state, is it same with that in section 2.2?
= >
> <NB> Section 6.1 discusses the actions when the PE enters the PW=
> receive defect state not the criteria to enter that state. However, > as you pointed out section 2.2 describes criteria for entering
> receive defect state. It is similar to that in RFC6310. That is why > it wa sin section 2.2 only as a review. However, a better
> organization would be to have a parallel section to 5.1  is. To <= br> > streamline things, I will do the same as proposed in the previous
= > similar comments. That is, merge text from section 2.2 into 6.1.  = ;If
> that is OK with you, I will do that and send as part of the updated > document. <NB>
[= Lizhong] that's good, thanks.
>
>
> Further, when PE1 enters the Receive Defect state, it must assume
= > that PE2 has no knowledge of the defect and must send reverse
> defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN,
> this is done via either a PW Status notification message indicating > a reverse defect; or via VCCV-BFD diagnostic code of reverse defect > if VCCV CV type of 0x08 had been negotiated.
> [Lizhong] why CV type of 0x20 is missed here?
>
> <NB> Done. It should be as in other places in the document. Ther= e is
> one additional place, where that will be corrected as well. Thanks.
[Lizhong] good, thanks.
>
>
>
> 6.2. PW Receive Defect Exit Procedures
> [Lizhong] this section does not describe the mechanism to exit PW
= > receive defect state?
= >
> <NB> This section describes what actions must happen when the PE=
> exits the PW receive defect state and not what needs to happen to
= > exit the PW receive defect state. The PW receive and transmit defect > state entry and exit criteria are summarized in section 2.2 and are > common with what is described in RFC 6310, as highlighted in section > 4  and that is why they were thought as being summarized and not =
> included later. However, again I think with the changes above, and > to make it clearer  based on the comment, I can consolidate that = in
> a section that says PW Receive Defect State Entry and Exit criteria, > and similarly PW Transmit Defect state and Exit criteria that
> parallel those of the the AC. Will that address that point? <NB>=
[Lizhong] that's good.

>
>
> If PW receive defect was established via notification from PE2 or
= > via loss of control adjacency, no additional action is needed,
> since PE2 is expected to be aware of the defect clearing.
<= font size=3D"2" face=3D"sans-serif">>
>
> [Lizhong] the above description is incorrect in this section. The
= > exit of PW receive defect should be described, not enter of PW receive= defect.
> <NB> Per= above, this section describes what action PE1 needs to take
> when it exits the receive defect state. It is not describing how it > enters or exits the receive defect state.
[Lizhong] I see, ok with that.
>
>
> 6.3. PW Transmit Defect Entry Procedures
>
> - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
= > used for fault notification, PE1 must transmit E-LMI asynchronous
= > STATUS message with report type Single EVC Asynchronous Status
> indicating that PW is Not Active.
> [Lizhong] shouldn't the entry of PW transmit defect be signaled to > remote PE? I do not see such text here.
> <NB> It was assumed per section 4 to be the sa= me in rfc 6310 since
> this is failure that pertains to the PSN side. However, for
> completeness here and consistency, I agree we should include it. I > will include the following per rfc 6310.
> "If the PW failure was detected by PE1 without rece= iving reverse
> defect notification from
>       PE2, PE1 MUST assume PE2 has no knowledge of the = defect and MUST
>       notify PE2 by sending FDI."
> <NB>
[Lizhong] that's good, thanks.

>
> 6.4. PW Transmit Defect Exit Procedures
>
> - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
> transmit E-LMI asynchronous STATUS message with report type Single > EVC Asynchronous Status indicating that PW is Active.
> [Lizhong] same comment as for previous section, shouldn't the exit > of PW transmit defect be signaled to remote PE? I do not see such text= here.
> <NB> Yes, = and will include the following in-line with above response:
> PE1 MUST clear the FDI to PE2, if appl= icable.
> <NB>
[Lizhong] that's good, thanks.<= /font>

>
>
> 6.5. AC Receive Defect Entry Procedures
>
> When Native Service OAM mechanism is supported on PE1, it can also > use the NS OAM notification as specified in Section 4.1.  
> [Lizhong] is there any relationship between notification mechanism > in CE domain and mechanism in PE domain. I mean if the AC uses NS
= > OAM to detect defect in CE domain, does NS OAM between PEs have any > priority to apply?
>= ; <NB> When NS OAM is supported PSN-facing and the fault notification
> functions are enabled as described, then they are used for fault
> notification. Is that the question? <NB>
[Lizhong] Similar. And I mean, if NS OAM, VCCV-B= FD and PW status are supported on the PE, which one should be applied? Is t= here any priority among the three?
>
>
> Nits:
> There are some nits that need to resolve. Please check link: http:
= > //tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-
> pwe3-mpls-eth-oam-iwk-06.txt
> <NB> Yes. That will be taken care of in the updated versi= on. <NB>
[Lizhong] tha= nk you.
>
> Regards
> Lizhong
--_000_CD0BB69D6E640nabilnbitarverizoncom_-- From lizhong.jin@zte.com.cn Fri Jan 4 17:36:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2621F8617; Fri, 4 Jan 2013 17:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mRyPmGKr+5f; Fri, 4 Jan 2013 17:36:53 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01C21F85CC; Fri, 4 Jan 2013 17:36:52 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id ED0EB1924074; Sat, 5 Jan 2013 09:36:39 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E94BB716A5E; Sat, 5 Jan 2013 09:26:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r051aWUX053870; Sat, 5 Jan 2013 09:36:32 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Bitar, Nabil N" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Sat, 5 Jan 2013 09:35:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-05 09:36:11, Serialize complete at 2013-01-05 09:36:11 Content-Type: multipart/alternative; boundary="=_alternative 0008D91B48257AEA_=" X-MAIL: mse02.zte.com.cn r051aWUX053870 Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" , "rtg-dir@ietf.org" , "Bitar, Nabil N" , "rtg-dir-bounces@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 01:36:57 -0000 This is a multipart message in MIME format. --=_alternative 0008D91B48257AEA_= Content-Type: text/plain; charset="US-ASCII" > > When NS OAM is supported PSN-facing and the fault notification > > functions are enabled as described, then they are used for fault > > notification. Is that the question? > [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are > supported on the PE, which one should be applied? Is there any > priority among the three? > > > > There is no priority defined among the three. On the PSN- > facing side, if all three are enabled for fault defection and > notification (I don;t see why all 3 would be enabled). The text says > that how each of them can be used for failure notification. A > failure notification by any of the mechanisms will bring the service down. [Lizhong] The text in draft says: "When NS OAM is not supported on PE1, and for PW over MPLS PSN or MPLS-IP PSN, forward defect notification is done via either PW Status message indicating a forward defect or via VCCV-BFD diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had been negotiated." I thought NS OAM was prioritied, but the following says: "When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1." Then I doubt if NS OAM is prioritied. To be frankly, I haven't met the scenario to have two options supported, but it does seem to be reasonable to happen. If there is implementation to have both NS OAM and PW status, or NS OAN and VCCV-BFD supported on the PE, there would be interoperation issue if we do not have any prioritization. Thanks Lizhong > > Thanks, > Nabil > > From: Lizhong Jin > Date: Thursday, January 3, 2013 1:28 AM > To: "Bitar, Nabil N" > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-ads@tools.ietf.org" < > rtg-ads@tools.ietf.org>, "rtg-dir@ietf.org" , " > rtg-dir-bounces@ietf.org" > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > > > Hi Nabil, > See inline for the reply. Thank you, and happy new year. > > Regards > Lizhong > > > rtg-dir-bounces@ietf.org wrote 2013/01/03 00:28:27: > > > Hi Lizhong, > > Thanks for your review and comments and sorry for a late reply. > > Please, see inline. > > > > Thanks, > > Nabil > > > > From: Lizhong Jin > > Date: Tuesday, August 14, 2012 8:34 AM > > To: "rtg-ads@tools.ietf.org" > > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" > ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" < > > rtg-dir@ietf.org> > > Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > > > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > > draft. The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review > > is to provide assistance to the Routing ADs. For more information > > about the Routing Directorate, please see http://www.ietf. > > org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing > > ADs, it would be helpful if you could consider them along with any > > other IETF Last Call comments that you receive, and strive to > > resolve them through discussion or by updating the draft. > > > > Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt > > Reviewer: Lizhong Jin > > Review Date: Aug, 14th, 2012 > > IETF LC End Date: Aug, 20th, 2012 > > Intended Status: Standard track > > > > Summary: > > 1.I have some minor concerns about this document that I think should > > be resolved before publication. > > > > Comments: > > Basically, this document is well written and I believe the mechanism > > has been implemented and deployed in real networks. There are only > > some parts of the document that need to be clarified to avoid > > misunderstanding. > > > > Major Issues: > > No major issues found. > > > > Minor Issues: > > 2.2. Abstract Defect States > > A PW forward defect indication received on PE1 impacts the ability > > of PE1 to receive traffic on the PW. > > [Lizhong] "PW forward defect" only refers to one mechanism above, > > should it be "PW receive defect"? > > > > PE1 receives a a forward defect indication and enters the > > receive defect state. That is really what is in the text now. This > > terminology is also used in RFC 6310. The text as it is is correct > > and consistent. > [Lizhong] OK. > > > > > > 4.1. Use of Native Service (NS) Notification > > > > - Sending of AIS frames from the local MEP to the MEP on the > > remote PE when the MEP needs to convey PE receive defects, and when > > CCM transmission is disabled. > > [Lizhong] "PE receive defects" refer to PE AC receive defects or > > both AC and PE receive defects? > > > > > > Section 4.1 lists the mechanisms used for fault notification on the > > PSN side only upfront. > > Section 6.1 "PW Receive Defect entry procedures" specified how the > > mechanisms in section 4.1 can be used when receive defect is > > detected on the PW. Please, look at the paragraph before last in > that section. > > Section 6.5 "AC Receive Defect Entry Procedures" describes how the > > mechanisms used in section 4.1 are used when AC receive defect state > > is entered. Please, look at the 4th paragraph in that section. > > > [Lizhong] I am OK now. Thanks. > > > > > - Suspension of CCM frames transmission from the local MEP to > > the peer MEP on the remote PE to convey PE receive defects, when > > CCM transmission is enabled. > > [Lizhong] "PE receive defects" refer to PE AC receive defects or > > both AC and PE receive defects? > > > > Please, see above answer. The same applies here. > [Lizhong] OK. > > > > > > 4.2. Use of PW Status notification for MPLS PSNs > > > > There are also scenarios where a PE carries out PW label withdrawal > > instead of PW status notification. These include administrative > > disablement of the PW or loss of Target LDP session with the peer > > PE. > > [Lizhong] There is another PW/AC status signaling method by using > > label withdraw method when PW status notificationis not supported. > > Is it intentionally ignored? > > > > I am not sure I understand the comment as the text you quoted > > is refering to PW label withdrawal as an alternative for status > > notification. Isn't that what you are referring to? > [Lizhong] yes. I am not proposing to add PW label withdrawal, but > want to know why it is not considered here. > > > > > > 4.3. Use of BFD Diagnostic Codes > > > > When using VCCV, the control channel (CC) type and Connectivity > > Verification (CV) Type are agreed on between the peer PEs using the > > OAM capability sub-TLV signaled as part of the interface parameter > > TLV when using FEC 129 and the interface parameter sub-TLV when > > using FEC 128. > > [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface > > parameters sub-TLV", right? Suggest to align with terminology in RFC5085. > > > > Will do. Here is the iterated text: > > When using VCCV, the control channel (CC) type and Connectivity > > Verification (CV) Type are agreed on between the peer PEs using the > > VCCV parameter field signaled as a sub-tlv of the interface parameters > > TLV when using FEC 129 and the interface parameter sub-TLV when > > using FEC 128. > > > [Lizhong] good, thanks. > > > > > 5. Ethernet AC Defect States Entry or Exit Criteria > > [Lizhong] context of AC receive/transmit defect entry is duplicated > > with that in section 2.2. Is it possible to make the context more > > simple, either in section 2.2 or 5.1? > > > > There is overlap. I am proposing to merge text related to > > conditions for entering the defect states in section 2.2 into 5.1 > > and reduce the overlap . I believe that addresses that point. If > > that is OK with you, I will do that and send as part of the > updated document. > [Lizhong] that's good, thanks. > > > > > > 6. Ethernet AC and PW Defect States Interworking > > [Lizhong] RFC2119 words should be used in this section, e.g, "must" > > should be "MUST". > > > > Done. > [Lizhong] thanks. > > > > > > 6.1. PW Receive Defect Entry Procedures > > [Lizhong] this section does not describe the mechanism to enter PW > > receive defect state, is it same with that in section 2.2? > > > > Section 6.1 discusses the actions when the PE enters the PW > > receive defect state not the criteria to enter that state. However, > > as you pointed out section 2.2 describes criteria for entering > > receive defect state. It is similar to that in RFC6310. That is why > > it wa sin section 2.2 only as a review. However, a better > > organization would be to have a parallel section to 5.1 is. To > > streamline things, I will do the same as proposed in the previous > > similar comments. That is, merge text from section 2.2 into 6.1. If > > that is OK with you, I will do that and send as part of the updated > > document. > [Lizhong] that's good, thanks. > > > > > > Further, when PE1 enters the Receive Defect state, it must assume > > that PE2 has no knowledge of the defect and must send reverse > > defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, > > this is done via either a PW Status notification message indicating > > a reverse defect; or via VCCV-BFD diagnostic code of reverse defect > > if VCCV CV type of 0x08 had been negotiated. > > [Lizhong] why CV type of 0x20 is missed here? > > > > Done. It should be as in other places in the document. There is > > one additional place, where that will be corrected as well. Thanks. > [Lizhong] good, thanks. > > > > > > > > 6.2. PW Receive Defect Exit Procedures > > [Lizhong] this section does not describe the mechanism to exit PW > > receive defect state? > > > > This section describes what actions must happen when the PE > > exits the PW receive defect state and not what needs to happen to > > exit the PW receive defect state. The PW receive and transmit defect > > state entry and exit criteria are summarized in section 2.2 and are > > common with what is described in RFC 6310, as highlighted in section > > 4 and that is why they were thought as being summarized and not > > included later. However, again I think with the changes above, and > > to make it clearer based on the comment, I can consolidate that in > > a section that says PW Receive Defect State Entry and Exit criteria, > > and similarly PW Transmit Defect state and Exit criteria that > > parallel those of the the AC. Will that address that point? > [Lizhong] that's good. > > > > > > > If PW receive defect was established via notification from PE2 or > > via loss of control adjacency, no additional action is needed, > > since PE2 is expected to be aware of the defect clearing. > > > > > > [Lizhong] the above description is incorrect in this section. The > > exit of PW receive defect should be described, not enter of PW > receive defect. > > Per above, this section describes what action PE1 needs to take > > when it exits the receive defect state. It is not describing how it > > enters or exits the receive defect state. > [Lizhong] I see, ok with that. > > > > > > 6.3. PW Transmit Defect Entry Procedures > > > > - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is > > used for fault notification, PE1 must transmit E-LMI asynchronous > > STATUS message with report type Single EVC Asynchronous Status > > indicating that PW is Not Active. > > [Lizhong] shouldn't the entry of PW transmit defect be signaled to > > remote PE? I do not see such text here. > > It was assumed per section 4 to be the same in rfc 6310 since > > this is failure that pertains to the PSN side. However, for > > completeness here and consistency, I agree we should include it. I > > will include the following per rfc 6310. > > "If the PW failure was detected by PE1 without receiving reverse > > defect notification from > > PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST > > notify PE2 by sending FDI." > > > [Lizhong] that's good, thanks. > > > > > 6.4. PW Transmit Defect Exit Procedures > > > > - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must > > transmit E-LMI asynchronous STATUS message with report type Single > > EVC Asynchronous Status indicating that PW is Active. > > [Lizhong] same comment as for previous section, shouldn't the exit > > of PW transmit defect be signaled to remote PE? I do not see such text here. > > Yes, and will include the following in-line with above response: > > PE1 MUST clear the FDI to PE2, if applicable. > > > [Lizhong] that's good, thanks. > > > > > > > 6.5. AC Receive Defect Entry Procedures > > > > When Native Service OAM mechanism is supported on PE1, it can also > > use the NS OAM notification as specified in Section 4.1. > > [Lizhong] is there any relationship between notification mechanism > > in CE domain and mechanism in PE domain. I mean if the AC uses NS > > OAM to detect defect in CE domain, does NS OAM between PEs have any > > priority to apply? > > When NS OAM is supported PSN-facing and the fault notification > > functions are enabled as described, then they are used for fault > > notification. Is that the question? > [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are > supported on the PE, which one should be applied? Is there any > priority among the three? > > > > > > Nits: > > There are some nits that need to resolve. Please check link: http: > > //tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf- > > pwe3-mpls-eth-oam-iwk-06.txt > > Yes. That will be taken care of in the updated version. > [Lizhong] thank you. > > > > Regards > > Lizhong --=_alternative 0008D91B48257AEA_= Content-Type: text/html; charset="US-ASCII"
> > <NB> When NS OAM is supported PSN-facing and the fault notification
> > functions are enabled as described, then they are used for fault
> > notification. Is that the question? <NB>
> [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are
> supported on the PE, which one should be applied? Is there any
> priority among the three?
> >
>
> <NB2> There is no priority defined among the three. On the PSN-
> facing side, if all three are enabled for fault defection and
> notification (I don;t see why all 3 would be enabled). The text says
> that how each of them can be used for failure notification. A
> failure notification by any of the mechanisms will bring the service down.
[Lizhong] The text in draft says:
"When NS OAM is not supported on PE1, and for PW over MPLS PSN or
     MPLS-IP PSN, forward defect notification is done via either PW
     Status message indicating a forward defect or via VCCV-BFD
     diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had
     been negotiated."
I thought NS OAM was prioritied, but the following says:
"When Native Service OAM mechanism is supported on PE1, it can also
     use the NS OAM notification as specified in Section 4.1."
Then I doubt if NS OAM is prioritied. To be frankly, I haven't met the scenario to have two options supported, but it does seem to be reasonable to happen. If there is implementation to have both NS OAM and PW status, or NS OAN and VCCV-BFD supported on the PE, there would be interoperation issue if we do not have any prioritization.

Thanks
Lizhong

>
> Thanks,
> Nabil
>
> From: Lizhong Jin <lizhong.jin@zte.com.cn>
> Date: Thursday, January 3, 2013 1:28 AM
> To: "Bitar, Nabil N" <nabil.n.bitar@one.verizon.com>
> Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" <draft-
> ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-ads@tools.ietf.org" <
> rtg-ads@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "
> rtg-dir-bounces@ietf.org" <rtg-dir-bounces@ietf.org>
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
>
>
> Hi Nabil,
> See inline for the reply. Thank you, and happy new year.
>
> Regards
> Lizhong
>  
>
> rtg-dir-bounces@ietf.org wrote 2013/01/03 00:28:27:
>
> > Hi Lizhong,
> > Thanks for your review and comments and sorry for a late reply.
> > Please, see inline.
> >
> > Thanks,
> > Nabil
> >
> > From: Lizhong Jin <lizhong.jin@zte.com.cn>
> > Date: Tuesday, August 14, 2012 8:34 AM
> > To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
> > Cc: "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" <draft-
> > ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org>, "rtg-dir@ietf.org" <
> > rtg-dir@ietf.org>
> > Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
> >
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review
> > is to provide assistance to the Routing ADs. For more information
> > about the Routing Directorate, please see http://www.ietf.
> > org/iesg/directorate/routing.html
> >
> > Although these comments are primarily for the use of the Routing
> > ADs, it would be helpful if you could consider them along with any
> > other IETF Last Call comments that you receive, and strive to
> > resolve them through discussion or by updating the draft.
> >
> > Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
> > Reviewer: Lizhong Jin
> > Review Date: Aug, 14th, 2012
> > IETF LC End Date: Aug, 20th, 2012
> > Intended Status: Standard track
> >
> > Summary:
> > 1.I have some minor concerns about this document that I think should
> > be resolved before publication.
> >
> > Comments:
> > Basically, this document is well written and I believe the mechanism
> > has been implemented and deployed in real networks. There are only
> > some parts of the document that need to be clarified to avoid
> > misunderstanding.
> >
> > Major Issues:
> > No major issues found.
> >
> > Minor Issues:
> > 2.2.  Abstract Defect States
> > A PW forward defect indication received on PE1 impacts the ability
> > of PE1 to receive traffic on the PW.
> > [Lizhong] "PW forward defect" only refers to one mechanism above,
> > should it be "PW receive defect"?
> >
> > <NB> PE1 receives a a forward defect indication  and enters the
> > receive defect state. That is really what is in the text now. This
> > terminology is also used in RFC 6310. The text as it is is correct
> > and consistent. <NB>
> [Lizhong] OK.
> >
> >  
> > 4.1. Use of Native Service (NS) Notification  
> >
> >     - Sending of AIS frames from the local MEP to the MEP on the
> > remote PE when the MEP needs to convey PE receive defects, and when
> > CCM transmission is disabled.  
> > [Lizhong] "PE receive defects" refer to PE AC receive defects or
> > both AC and PE receive defects?
> >
> > <NB>
> >  Section 4.1 lists the mechanisms used for fault notification on the
> > PSN side only upfront.
> > Section 6.1 "PW Receive Defect entry procedures" specified how the
> > mechanisms in section 4.1 can be used when receive defect is
> > detected on the PW. Please, look at the paragraph before last in
> that section.
> > Section 6.5 "AC Receive Defect Entry Procedures" describes how the
> > mechanisms used in section 4.1 are used when AC receive defect state
> > is entered. Please, look at the 4th paragraph in that section.
> > <NB>
> [Lizhong] I am OK now. Thanks.
>
> >  
> >     - Suspension of CCM frames transmission from the local MEP to
> > the peer MEP on the remote PE to convey PE receive defects, when
> > CCM transmission is enabled.  
> > [Lizhong] "PE receive defects" refer to PE AC receive defects or
> > both AC and PE receive defects?
> >
> > <NB> Please, see above answer. The same applies here.
> [Lizhong] OK.
> >
> >
> > 4.2. Use of PW Status notification for MPLS PSNs  
> >
> > There are also scenarios where a PE carries out PW label withdrawal
> > instead of PW status notification. These include administrative
> > disablement of the PW or loss of Target LDP session with the peer
> > PE.
> > [Lizhong] There is another PW/AC status signaling method by using
> > label withdraw method when PW status notificationis not supported.
> > Is it intentionally ignored?
> >
> > <NB> I am not sure I understand the comment as the text you quoted
> > is refering to PW label withdrawal as an alternative for status
> > notification. Isn't that what you are referring to?
> [Lizhong] yes. I am not proposing to add PW label withdrawal, but
> want to know why it is not considered here.
> >
> >
> > 4.3. Use of BFD Diagnostic Codes
> >
> > When using VCCV, the control channel (CC) type and Connectivity
> > Verification (CV) Type are agreed on between the peer PEs using the
> > OAM capability sub-TLV signaled as part of the interface parameter
> > TLV when using FEC 129 and the interface parameter sub-TLV when
> > using FEC 128.  
> > [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface
> > parameters sub-TLV", right? Suggest to align with terminology in RFC5085.
> >
> > <NB> Will do. Here is the iterated text:
> > When using VCCV, the control channel (CC) type and Connectivity
> > Verification (CV) Type are agreed on between the peer PEs using the
> > VCCV parameter field signaled as a sub-tlv of the interface parameters
> > TLV when using FEC 129 and the interface parameter sub-TLV when
> > using FEC 128.  
> > <NB>
> [Lizhong] good, thanks.
>
> >
> > 5. Ethernet AC Defect States Entry or Exit Criteria
> > [Lizhong] context of AC receive/transmit defect entry is duplicated
> > with that in section 2.2. Is it possible to make the context more
> > simple, either in section 2.2 or 5.1?
> >
> > <NB> There is overlap. I am proposing to merge text related to
> > conditions for entering the defect states in section 2.2 into 5.1  
> > and reduce the overlap . I believe that addresses that point. If
> > that is OK with you, I will do that and send as part of the
> updated document.
> [Lizhong] that's good, thanks.
> >
> >
> > 6. Ethernet AC and PW Defect States Interworking
> > [Lizhong] RFC2119 words should be used in this section, e.g, "must"
> > should be "MUST".
> >
> > <NB> Done. <NB>
> [Lizhong] thanks.
> >
> >
> > 6.1. PW Receive Defect Entry Procedures
> > [Lizhong] this section does not describe the mechanism to enter PW
> > receive defect state, is it same with that in section 2.2?
> >
> > <NB> Section 6.1 discusses the actions when the PE enters the PW
> > receive defect state not the criteria to enter that state. However,
> > as you pointed out section 2.2 describes criteria for entering
> > receive defect state. It is similar to that in RFC6310. That is why
> > it wa sin section 2.2 only as a review. However, a better
> > organization would be to have a parallel section to 5.1  is. To
> > streamline things, I will do the same as proposed in the previous
> > similar comments. That is, merge text from section 2.2 into 6.1.  If
> > that is OK with you, I will do that and send as part of the updated
> > document. <NB>
> [Lizhong] that's good, thanks.
> >
> >
> > Further, when PE1 enters the Receive Defect state, it must assume
> > that PE2 has no knowledge of the defect and must send reverse
> > defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN,
> > this is done via either a PW Status notification message indicating
> > a reverse defect; or via VCCV-BFD diagnostic code of reverse defect
> > if VCCV CV type of 0x08 had been negotiated.
> > [Lizhong] why CV type of 0x20 is missed here?
> >
> > <NB> Done. It should be as in other places in the document. There is
> > one additional place, where that will be corrected as well. Thanks.
> [Lizhong] good, thanks.
> >
> >
> >
> > 6.2. PW Receive Defect Exit Procedures
> > [Lizhong] this section does not describe the mechanism to exit PW
> > receive defect state?
> >
> > <NB> This section describes what actions must happen when the PE
> > exits the PW receive defect state and not what needs to happen to
> > exit the PW receive defect state. The PW receive and transmit defect
> > state entry and exit criteria are summarized in section 2.2 and are
> > common with what is described in RFC 6310, as highlighted in section
> > 4  and that is why they were thought as being summarized and not
> > included later. However, again I think with the changes above, and
> > to make it clearer  based on the comment, I can consolidate that in
> > a section that says PW Receive Defect State Entry and Exit criteria,
> > and similarly PW Transmit Defect state and Exit criteria that
> > parallel those of the the AC. Will that address that point? <NB>
> [Lizhong] that's good.
>
> >
> >
> > If PW receive defect was established via notification from PE2 or
> > via loss of control adjacency, no additional action is needed,
> > since PE2 is expected to be aware of the defect clearing.
> >
> >
> > [Lizhong] the above description is incorrect in this section. The
> > exit of PW receive defect should be described, not enter of PW
> receive defect.
> > <NB> Per above, this section describes what action PE1 needs to take
> > when it exits the receive defect state. It is not describing how it
> > enters or exits the receive defect state.
> [Lizhong] I see, ok with that.
> >
> >
> > 6.3. PW Transmit Defect Entry Procedures
> >
> > - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
> > used for fault notification, PE1 must transmit E-LMI asynchronous
> > STATUS message with report type Single EVC Asynchronous Status
> > indicating that PW is Not Active.
> > [Lizhong] shouldn't the entry of PW transmit defect be signaled to
> > remote PE? I do not see such text here.
> > <NB> It was assumed per section 4 to be the same in rfc 6310 since
> > this is failure that pertains to the PSN side. However, for
> > completeness here and consistency, I agree we should include it. I
> > will include the following per rfc 6310.
> > "If the PW failure was detected by PE1 without receiving reverse
> > defect notification from
> >       PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST
> >       notify PE2 by sending FDI."
> > <NB>
> [Lizhong] that's good, thanks.
>
> >
> > 6.4. PW Transmit Defect Exit Procedures
> >
> > - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
> > transmit E-LMI asynchronous STATUS message with report type Single
> > EVC Asynchronous Status indicating that PW is Active.
> > [Lizhong] same comment as for previous section, shouldn't the exit
> > of PW transmit defect be signaled to remote PE? I do not see such text here.
> > <NB> Yes, and will include the following in-line with above response:
> > PE1 MUST clear the FDI to PE2, if applicable.
> > <NB>
> [Lizhong] that's good, thanks.
>
> >
> >
> > 6.5. AC Receive Defect Entry Procedures
> >
> > When Native Service OAM mechanism is supported on PE1, it can also
> > use the NS OAM notification as specified in Section 4.1.  
> > [Lizhong] is there any relationship between notification mechanism
> > in CE domain and mechanism in PE domain. I mean if the AC uses NS
> > OAM to detect defect in CE domain, does NS OAM between PEs have any
> > priority to apply?
> > <NB> When NS OAM is supported PSN-facing and the fault notification
> > functions are enabled as described, then they are used for fault
> > notification. Is that the question? <NB>
> [Lizhong] Similar. And I mean, if NS OAM, VCCV-BFD and PW status are
> supported on the PE, which one should be applied? Is there any
> priority among the three?
> >
> >
> > Nits:
> > There are some nits that need to resolve. Please check link: http:
> > //tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-
> > pwe3-mpls-eth-oam-iwk-06.txt
> > <NB> Yes. That will be taken care of in the updated version. <NB>
> [Lizhong] thank you.
> >
> > Regards
> > Lizhong --=_alternative 0008D91B48257AEA_=-- From jmh@joelhalpern.com Wed Jan 9 17:46:58 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED801F0CF5; Wed, 9 Jan 2013 17:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5xM+UiU3WbS; Wed, 9 Jan 2013 17:46:58 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1231F0C6A; Wed, 9 Jan 2013 17:46:58 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7F8B2A36F6; Wed, 9 Jan 2013 17:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8D7741C0B58; Wed, 9 Jan 2013 17:46:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 62BAA1C07B6; Wed, 9 Jan 2013 17:46:55 -0800 (PST) Message-ID: <50EE1D8F.6050407@joelhalpern.com> Date: Wed, 09 Jan 2013 20:46:55 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 01:46:59 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-p2p-measurement-07.txt Reviewer: Joel M. Halpern Review Date: 9-Januar-2013 IETF LC End Date: 21-January-2013 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Generally, this is a well written and readable specification addressing an understandable problem. Major Issues: Minor Issues: I had not realized until section 4.3 that NUM (and the structure of the message) had to allow for the desired limit on the Address Accumulation. (I had originally inferred a rather painful strategy.) Could this be stated earlier in the document please? Can the first sentence of the text in the nested bullet on Source Routed Address vectors ("When the Measurement Request is traveling along a Source Route...") be moved before the description of the bits (sorry, it may need to be slightly reworded to do so.) This restriction is very helpful in understand the behaviors defined by the various flags in the message header. (Also, if it wouldn't bother the ROLL/RPL experts too much, a comment about he root not needing to add a source route for a local RPLInstance would complete the picture nicely. I am merely inferring this behavior from the fact that accumulate is allowed with hop-by-hop and local RPLInstances.) It appears that the loop prevention requirement on source routes requires every router that handles the packet to examine every entry in the source route to make sure that the inspecting router does not appear anywhere except a the current index entry. ("MUST ensure that o address appears more than once" in section 5.1, and text in section 5.3.) That would seem to be a significant cost, for no obvious benefit. Why is it required? (Yes, I have read the last bullet of section 9. This seems to be a very expensive set of extra protections. Given that the index gets increment, the cost of a loop seems pretty small.) I section 5.2 and 5.3, how can the processing node determine the "Address vector is present in the received message" if the Num field is 0? Nits: Could the first bullet in section 5.1 be re-ordered so that the condition ("if it does not know how to reach the End Point") occurs before the "MUST discard". As written, the reader is startled by thinking that the first thing the root must do is discard the request. Could the same be done to the second and third paragraphs of 5.2? And the second and third paragraphs of section 5.3? And the second paragraph of section 5.4? (The third paragraph of 5.4 has things in the order which I think is clearer for the reader.) The last sentence of the next to last paragraph of 5.5 could also be reversed, although for some unknown reason I find that one less bothersome. Section 7, second paragraph could also be usefully reversed. I presume that all the "dropped with no further processing" is not intended to preclude updating error counters and similar actions. Is there a place that could be said? Yours, Joel M. Halpern From prvs=72081a62a=mukul@uwm.edu Mon Jan 14 23:43:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0321F8B11; Mon, 14 Jan 2013 23:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An5A0tHCJhQN; Mon, 14 Jan 2013 23:43:48 -0800 (PST) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9221F8B0C; Mon, 14 Jan 2013 23:43:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIoH9VB/AAAB/2dsb2JhbAA6CoY6t1GDEQEBBSNIDgwPFAYCDRkCWQaILAylPoJAhzCHBQSBI4tZBYMagRMDiGGCcYcGgzOGWolvgxSBRwEfBBo Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3E4C21209DF; Tue, 15 Jan 2013 01:43:47 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWvuD0D1dh64; Tue, 15 Jan 2013 01:43:46 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EEECE120960; Tue, 15 Jan 2013 01:43:46 -0600 (CST) Date: Tue, 15 Jan 2013 01:43:46 -0600 (CST) From: Mukul Goyal To: "Joel M. Halpern" Message-ID: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <50EE1D8F.6050407@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu X-Mailman-Approved-At: Tue, 15 Jan 2013 01:38:14 -0800 Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:43:49 -0000 Hi Joel Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at: https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt I will include these changes in the new version to be posted at the conclusion of the last call. Please see my response to your comments below and let me know if the modifications to the draft look OK to you. Thanks Mukul ----- Original Message ----- Document: draft-ietf-roll-p2p-measurement-07.txt Reviewer: Joel M. Halpern Review Date: 9-Januar-2013 IETF LC End Date: 21-January-2013 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Generally, this is a well written and readable specification addressing an understandable problem. Major Issues: Minor Issues: --------------------------------------------------------- [JH] I had not realized until section 4.3 that NUM (and the structure of the message) had to allow for the desired limit on the Address Accumulation. (I had originally inferred a rather painful strategy.) Could this be stated earlier in the document please? [MG] Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3. [JH] Can the first sentence of the text in the nested bullet on Source Routed Address vectors ("When the Measurement Request is traveling along a Source Route...") be moved before the description of the bits (sorry, it may need to be slightly reworded to do so.) This restriction is very helpful in understand the behaviors defined by the various flags in the message header. [MG] Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2. [JH] (Also, if it wouldn't bother the ROLL/RPL experts too much, a comment about he root not needing to add a source route for a local RPLInstance would complete the picture nicely. I am merely inferring this behavior from the fact that accumulate is allowed with hop-by-hop and local RPLInstances.) [MG] To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified. BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route. [JH] It appears that the loop prevention requirement on source routes requires every router that handles the packet to examine every entry in the source route to make sure that the inspecting router does not appear anywhere except a the current index entry. ("MUST ensure that o address appears more than once" in section 5.1, and text in section 5.3.) That would seem to be a significant cost, for no obvious benefit. Why is it required? (Yes, I have read the last bullet of section 9. This seems to be a very expensive set of extra protections. Given that the index gets increment, the cost of a loop seems pretty small.) [MG] You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section. [JH] I section 5.2 and 5.3, how can the processing node determine the "Address vector is present in the received message" if the Num field is 0? [MG] Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere. [JH] Nits: Could the first bullet in section 5.1 be re-ordered so that the condition ("if it does not know how to reach the End Point") occurs before the "MUST discard". As written, the reader is startled by thinking that the first thing the root must do is discard the request. Could the same be done to the second and third paragraphs of 5.2? And the second and third paragraphs of section 5.3? And the second paragraph of section 5.4? (The third paragraph of 5.4 has things in the order which I think is clearer for the reader.) [MG] Done. [JH] The last sentence of the next to last paragraph of 5.5 could also be reversed, although for some unknown reason I find that one less bothersome. [MG] OK. I did not change this particular sentence. [JH] Section 7, second paragraph could also be usefully reversed. [MG] Done. [JH] I presume that all the "dropped with no further processing" is not intended to preclude updating error counters and similar actions. Is there a place that could be said? [MG] Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...). Thanks Mukul From jmh@joelhalpern.com Tue Jan 15 11:51:03 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E611E809A; Tue, 15 Jan 2013 11:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d79S98oX769y; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6481B11E8099; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 164A7A6672; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5E298181116; Tue, 15 Jan 2013 11:51:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-60.clppva.east.verizon.net [70.106.135.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E7015181112; Tue, 15 Jan 2013 11:50:58 -0800 (PST) Message-ID: <50F5B320.2050108@joelhalpern.com> Date: Tue, 15 Jan 2013 14:50:56 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mukul Goyal References: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:51:04 -0000 Thank you very much. These changes very nicely address my concerns. I can understood why you chose not to make the one change about route construction restrictions. Your modified text does help that somewhat, without being verbose, and I can live with that. Yours, Joel On 1/15/2013 2:43 AM, Mukul Goyal wrote: > Hi Joel > > Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at: > > https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt > > I will include these changes in the new version to be posted at the conclusion of the last call. > > Please see my response to your comments below and let me know if the modifications to the draft look OK to you. > > Thanks > Mukul > > ----- Original Message ----- > > Document: draft-ietf-roll-p2p-measurement-07.txt > > Reviewer: Joel M. Halpern > Review Date: 9-Januar-2013 > IETF LC End Date: 21-January-2013 > Intended Status: Experimental > > Summary: I have some minor concerns about this document that I think > should be resolved before publication. > > Comments: > Generally, this is a well written and readable specification > addressing an understandable problem. > > Major Issues: > > Minor Issues: > --------------------------------------------------------- > [JH] > I had not realized until section 4.3 that NUM (and the structure of > the message) had to allow for the desired limit on the Address > Accumulation. (I had originally inferred a rather painful strategy.) > Could this be stated earlier in the document please? > > [MG] > Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3. > > [JH] > Can the first sentence of the text in the nested bullet on Source > Routed Address vectors ("When the Measurement Request is traveling along > a Source Route...") be moved before the description of the bits (sorry, > it may need to be slightly reworded to do so.) This restriction is very > helpful in understand the behaviors defined by the various flags in the > message header. > > [MG] > Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2. > > [JH] > (Also, if it wouldn't bother the ROLL/RPL experts too > much, a comment about he root not needing to add a source route for a > local RPLInstance would complete the picture nicely. I am merely > inferring this behavior from the fact that accumulate is allowed with > hop-by-hop and local RPLInstances.) > > [MG] > To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place > for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified. > > BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route. > > [JH] > It appears that the loop prevention requirement on source routes > requires every router that handles the packet to examine every entry in > the source route to make sure that the inspecting router does not appear > anywhere except a the current index entry. ("MUST ensure that o address > appears more than once" in section 5.1, and text in section 5.3.) That > would seem to be a significant cost, for no obvious benefit. Why is it > required? (Yes, I have read the last bullet of section 9. This seems > to be a very expensive set of extra protections. Given that the index > gets increment, the cost of a loop seems pretty small.) > > [MG] > You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section. > > [JH] > I section 5.2 and 5.3, how can the processing node determine the > "Address vector is present in the received message" if the Num field is 0? > > [MG] > Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere. > > [JH] > Nits: > Could the first bullet in section 5.1 be re-ordered so that the > condition ("if it does not know how to reach the End Point") occurs > before the "MUST discard". As written, the reader is startled by > thinking that the first thing the root must do is discard the request. > Could the same be done to the second and third paragraphs of 5.2? > And the second and third paragraphs of section 5.3? > And the second paragraph of section 5.4? (The third paragraph of > 5.4 has things in the order which I think is clearer for the reader.) > > [MG] > Done. > > [JH] > The last sentence of the next to last paragraph of 5.5 could also > be reversed, although for some unknown reason I find that one less > bothersome. > > [MG] > OK. I did not change this particular sentence. > > [JH] > Section 7, second paragraph could also be usefully reversed. > > [MG] > Done. > > [JH] > I presume that all the "dropped with no further processing" is not > intended to preclude updating error counters and similar actions. Is > there a place that could be said? > > [MG] > Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...). > > Thanks > Mukul > From russw@riw.us Wed Jan 16 18:24:04 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF011E809C; Wed, 16 Jan 2013 18:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LONGWORDS=1.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzWMWRBSVYyW; Wed, 16 Jan 2013 18:24:03 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B385C1F0CF5; Wed, 16 Jan 2013 18:24:03 -0800 (PST) Received: from [216.53.138.131] (helo=[10.96.7.37]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tvf98-0004KU-Sk; Wed, 16 Jan 2013 18:24:03 -0800 Message-ID: <50F760C5.4030700@riw.us> Date: Wed, 16 Jan 2013 21:24:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-security-threats-00.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 02:24:04 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-security-threats-00.txt Reviewer: Russ White Review Date: 16 January 2013 IETF LC End Date: unknown Intended Status: Informational Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: Philosophically, this document seems to treat routing as an "entity," that operates by itself, independent of other systems, within a network. In real networks, routing is primarily used to provide for forwarding, so security should really be couched in terms of how breaches in routing security impact forwarding. The direction taken in this draft leads to a single end --the encryption of all routing information carried through the network. I would really like to see routing security take a more creative turn, seeing routing as a part of an overall system, rather than as an end to end flow of information that must be secured in its own right --as "just another data stream." Specifically, the goals in section 3.4 would necessarily be resolvable only through the use of some form encrypted transport of routing information, which could easily overcome any possible low powered device in complexity and difficulty. It seems, to me, a better overall goal would be to ensure the routing database accurately reflects the actual state of the network topology, allowing for any means that will reach this goal, whether or not they include cryptography. A wider net is more likely to produce a stronger set of available options. The problems noted in section 4 are, in fact, countered with proposals in sections 5 and 6 that only propse cryptographic mechanisms generally planned around encrypting routing exchanges and/or signing routing information on the wire, adding weight to my thoughts above. It seems, to me, that sections 5 and 6 should be moved to a separate draft, so the general overview of the problems and possible solutions are decoupled a bit, to allow “breathing room,” for possible alternate solutions. == My one concern about section 3.2 is one of the implications carried in the statement, “non-repudiation will involve providing some ability to allow traceability or network management review of participants of the routing process including the ability to determine the events and actions leading to a particular routing state.” This implies, at least to me, that the actual processing of routing updates need to be logged in a way that prevents tampering at every node, as well as the actual routing updates received, transmitted, and otherwise handled by each node in the network — especially since routing is not always atomic, but rather timing dependent. How this particular “possible requirement,” might be implanted in a way that is practical. == The taxonomy in section 4 appears to be solid. == Overall, I found the writing style to be a bit opaque/obtuse — difficult to read in parts, perhaps a little “research,” if that makes sense. Some specific comments on the first few paragraphs are below, but I didn’t spend a great deal of time working through specific grammar issues throughout the entire document. == This document presents a framework for securing Routing Over LLNs (ROLL)... Using an acronym to expand another acronym will probably confuse at least some readers. LLNs also needs to be explained at it's first use. == Security, in essence, entails implementing measures to ensure controlled state changes... I'm not certain what's meant by "controlled," here, or how it relates to security. Is "unsecured," information about state changes therefore "uncontrolled?" Is "verifiable," what you're after here, or perhaps, "authorized," or... ?? == State changes would thereby involve proper authorization for actions, authentication, and potentially confidentiality, but also proper order of state changes through timeliness (since seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation). Perhaps something like: Securing information about state changes would include ensuring devices match their claimed role (authentication), transmitted state changes are correct and allowed through policy (authorization), state changes are only visible to authorized devices (confidentiality), and operations are taken in the proper order (timeliness and atomicity). == An asset implies an important system component (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In network routing, assets lie in the routing information, routing process, and node's physical resources. That is, the access to, corruption, or loss of these elements adversely affects system routing. Perhaps something like: In the control plane context, an asset is information about the network, processes used to manage and manipulate this data, and the physical devices on which this data is stored and manipulated. The corruption or loss of these assets may adversely impact the control plane of the network. (Note you shouldn't imply any such breach "will," disrupt routing, because routing systems are, at base, designed to be resilient to information loss and corruption. There are some situations where loss or corruption will result in misrouted or lost data flows, but there are others where it will not.) == In network routing, a point of access refers to the point of entry facilitating communication with or other interaction with a system component in order to use system resources to either manipulate information or gain knowledge of the information contained within the system. Perhaps something like: Within the same context, a point of access is an interface or protocol that facilitates interaction between control plane components. == Security of the routing protocol must be focused on the assets of the routing nodes and the points of access of the information exchanges and information storage that may permit routing compromise. This sentence doesn't add to the flow of thought, so I would just remove it. == The identification of routing assets and points of access hence provides a basis for the identification of associated threats and attacks. Perhaps something like: Identifying these assets and points of access will provide a basis for enumerating the attack surface of the control plane. == This subsection identifies assets and points of access of a generic routing process with a level-0 data flow diagram [Yourdon1979] revealing how the routing protocol interacts with its environment. In particular, the use of the data flow diagram allows for a clear, concise model of the routing functionality; it also has the benefit of showing the manner in which nodes participate in the routing process, thus providing context when later threats and attacks are considered. Perhaps something like: A level-0 data flow diagram [Yourdon1979] is used here to identify the assets and points of access within a generic routing process. The use of a data flow diagram allows for a clear and concise model of the way in which routing nodes interact and process information, and hence provides a context for threats and attacks. Major Issues: My primary concern is the general philosophy within the draft --see my comments above. The working group may decide this philosophy is acceptable/good, but it should be brought out onto the table and discussed, and some explanation of why this path was chosen provided in the draft, rather than assumed, IMHO. Minor Issues: Writing style, as indicated in my comments above. == HTH :-) Russ From julien.meuric@orange.com Fri Jan 18 09:00:31 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D425121F886C; Fri, 18 Jan 2013 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id she4GI-90vr8; Fri, 18 Jan 2013 09:00:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id F325021F8863; Fri, 18 Jan 2013 09:00:30 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 990741074002; Fri, 18 Jan 2013 18:05:15 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 90CDC1074001; Fri, 18 Jan 2013 18:05:15 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 18:00:30 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 18:00:29 +0100 Message-ID: <50F97FAC.3010903@orange.com> Date: Fri, 18 Jan 2013 18:00:28 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2013 17:00:29.0878 (UTC) FILETIME=[520BAD60:01CDF59D] Cc: draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org, "rtg-dir@ietf.org" , "ccamp@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-lmp-behavior-negotiation-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:00:32 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 Reviewer: Julien Meuric Review Date: 18 January 2013 IETF LC End Date: 21 January 2013 Intended Status: Standards Track *Summary:* This document is basically ready for publication, but has nits that should be considered prior to it. *Comments:* This document is clearly written and easy to understand. The defined mechanism is simple and well specified. *Nits:* Abstract -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more accurate to me. It would also align on the phrase used in the introduction. The resulting "Generalized Multiprotocol Label Switching (GMPLS)-controlled networks" may be checked with the RFC Editor. Introduction - s/LMP node/LMP-capable node/ - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] - s/the message types from/the types from/ [repetition of "message"] Section 2.2 - s/MAY include, HelloConfig/MAY include HelloConfig/ Section 3.1 - s/number of MBZ bits field/number of bits in MBZ field/ Section 4 - s/[RFC4202] defined/[RFC4202]-defined/ Section 9.2 - I tend to think that [LMP TEST] should now reference draft-cecczhang-ccamp-gmpls-g709v3-lmp Enjoy the week-end, Julien From cpignata@cisco.com Sat Jan 19 16:44:35 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2305A21F8554; Sat, 19 Jan 2013 16:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAoay4H1oWlt; Sat, 19 Jan 2013 16:44:29 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B83A721F854E; Sat, 19 Jan 2013 16:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16324; q=dns/txt; s=iport; t=1358642669; x=1359852269; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ztco0YIDOwpV3VZVJ/6BWbnwb/PlJcsFg0xenwoins8=; b=EaVrLs7c2w3RruMj6Uy5qrFQuVvZ5sN2MLkWZ3KdPqpN9SUsRxvMIe8d gUhdPubQcmS26iFqQTqTjOf0DKxgPlgFXPzSKvtoH7t+eWxVHXkWjPCqa Y5DxZH1eh4aqxj483ISm0JQCR9e2lHgDEQCZMu5VOTZBLLfnNd7Inq+5F E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGs9+1CtJV2b/2dsb2JhbAA6Cr4+FnOCIAEEcgcSARwOVicEDg0BiBAMuyiGKYZZBQQBg0xhA5cojy2CdYFmAR8e X-IronPort-AV: E=Sophos;i="4.84,499,1355097600"; d="scan'208";a="165011040" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2013 00:44:27 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0K0iRf0013850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 00:44:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 18:44:27 -0600 From: "Carlos Pignataro (cpignata)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-opsawg-oam-overview-08.txt Thread-Index: AQHN9qdMecjM/63m70mmeKMEQIJ8hg== Date: Sun, 20 Jan 2013 00:44:26 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228D36FF@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-oam-overview.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-opsawg-oam-overview-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 00:44:35 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Carlos Pignataro Review Date: 18 January 2013 IETF LC End Date: 25 January 2013 Intended Status: Informational Summary:=20 I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. Comments: This document presents an overview of Operations, Administration, and Maint= enance (OAM) mechanisms in the IETF. This is a very useful document that us= es OAM consistently with the definition in RFC6291, and further explains th= e acronym by presenting a wider scope and a more concrete view. However, the taxonomy in which all these "mechanics" are presented is confu= sing, because they seem to intertwine the terms functions, tools, and proto= cols. These terms are used quite loosely in this document, which is counter= to its goal of providing clarity. "The beginning of wisdom is a definition= of terms", and for example, this document defines the "Continuity Check" O= AM functionality as a tool, and the ICMPv4 protocol as a tool. The overall organization of the document does not seem to help sometimes, w= ith a "Basic Terminology" section after all tools and documents are describ= ed and cited. Major Issues: The main major set of issues that I found have to do with terminology used,= which is critical for a document that attempts to bring clarity with an ov= erview of OAM mechanisms. This is described in the preceding comments. Additionally, the taxonomy in which these OAM mechanisms are presented seem= s to have gaps and gross overlaps. Section 1.3 groups "OAM toolsets" with a= network on which OAM is used (MPLS), a protocol used for OAM (BFD), a tool= (Ping and Traceroute), etc. Different protocols (e.g., both ICMPv4 and BFD= ) can be use on different networks (MPLS, IPv4, PW); they can be used in di= fferent tools for different utilities. ICMPv4 can be used in VCCV, Tracerou= te for MPLS can use ICMP or LSP Ping, BFD can be used for IP and MPLS for C= C, etc. All these different categorization vectors seem to be intertwined. This then is reflected taking Table 1, "Summary of IETF Related RFCs", as a= n example; it is not clear what is the categorization criteria. The indexes= into the table are "IP Ping and Traceroute" (these are tools -- does this = mean that there are the only OAM mechanisms for IP networks?), "BFD" (a pro= tocol which applies to IP, MPLS, Pseudowires, Tunnels, and others), "MPLS O= AM" (OAM for a particular packet switched network, some of which are BFD, b= ut are already covered in the previous meta-row), "OWAMP and TWAMP: (anothe= r protocol for IP performance metrics), and so on. A potential large amount of minor issues could compound as a major one as w= ell. Some more specific inlined comments follow. 1. Introduction =85 This document summarizes the OAM tools and mechanisms defined in the IETF. If the scope is "IETF", it should be reflected in the title. However, this = seems to contradict the whole Section 1.5, "Non-IETF OAM Documents". 1.2. Forwarding Plane vs. Management Plane This section and intended scope seems to be underspecified. In fact, the do= cument later speaks about other planes, including "user-plane", "Data plane= ", and "Test plane". Perhaps an architectural scope depiction would simplif= y this description and localize the "planes" with more precision. Minor Issues: 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation. OAM, as defined in RFC6291 (see Section 3), seems to be more broadly define= d than this first paragraph. 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). Is this generic OAM terminology ... This subsection provides a brief summary of the common tools used by OAM protocols. An OAM protocol typically supports one or more of the tools described below. o Continuity Checking (CC): Are these "OAM tools" of "OAM functions" supported by "OAM protocols"? =85 o Path Discovery / Fault Localization: An MP uses this mechanism to trace the route to a peer MP, i.e., to identify the nodes along the path to the peer MP. When a connection fails, this mechanism also allows the MP to detect the location of the failure. "the path" assumes there is a single path and not potential multi-path. Som= e OAM mechanisms included in this document support multi-path tree tracing.= There are also implications of connection-less vs. connection-oriented pro= tocols and paths, which are seemingly not covered. 1.3. The OAM toolsets This memo provides an overview of the different sets of OAM mechanisms defined by the IETF. It is intended for those with little or no familiarity with the described mechanisms. Only defined by the IETF? This contradicts a subsequent section The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). "transport environments", or "Transport Profile"? While OAM mechanisms that are applicable to other technologies exist, they are beyond the scope of this memo. How where these chosen, and others left out then? This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. IETF only (contradicting Section 1.5), and now limited to published RFCs? T= he scope could be defined before in the document, once only, and more delib= erately. The IETF has defined OAM protocols and mechanisms in several different fronts: >From the list that follows, which one is a protocol versus a mechanism, and= why are those different qualifiers mixed together in a flat list instead o= f matrixed in? o IP Ping and Traceroute: Ping is a very simple and common application for failure diagnosis that uses ICMP Echo requests, as defined in [ICMPv4], and [ICMPv6]. Five issues on this first part of this bullet: 1. Is "failure diagnostic" a new function? 2. What is defined in those two RFCs? Only ICMP and not Ping and Traceroute= . However, it is not clearly articulated. 3. It would be useful to describe where Ping with much more historical cont= ext, for example: RFC1208 ("A Glossary of Networking Terms") defines: ping: Packet internet groper. A program used to test reachability of RFC 1122 as: * Active probes such as "pinging" (i.e., using an ICMP 4. Ping for IPv4 uses ICMPv4 Echo (not Echo Request) and Echo Reply. Ping f= or IPv6 uses Echo Request *and* Echo Reply. 5. "simple" and "common" are in relationship to which baseline? In what net= work? Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to trace the path between an IP source and an IP destination, i.e., to identify the nodes along the path. There is some asymmetry of definitions where Ping is defined based on ICMP = (and not its function of reachability/CC), but traceroute is not defined ba= sed on the protocols used. Also, I have another concern on a potential over-simplification: "to trace = the path between an IP source and an IP destination", implicitly assumes th= ere is only one path. This is not the case generally, and frankly it highli= ghts the potential need of distinction in OAM for connection-less protocols= versus connection-oriented protocols (clps, cops) and implications on path= tree trace. o MPLS OAM: MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- Ping], is an OAM mechanism for point to point MPLS LSPs. It includes two main functions: Ping and Traceroute. To me, bullets like this one are quite misleading. MPLS LSP Ping is one pro= tocol and function to perform "MPLS OAM". But BFD is also used for "MPLS OA= M", and so is "ICMPv4 Echo" o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. These allow for more performance measurements (duplication, reordering, etc= ). It is not totally clear, consequently, if the enumeration is Section 1.1= is inclusive enough. 1.4. IETF OAM Documents The table includes a "Type" column, specifying the nature of each of the listed documents: =85 o Inf.: documents that define an infrastructure that is used by OAM tools. Infrastructure for OAM tools seems to not have been defined. Table 1 needs to be consistent with what is a Tool, Protocol, etc, and how = to categorize (as per comments above). For example: +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 | |Traceroute | [ICMPv4] | | | | +--------------------------------------+-----+----------+ | | Internet Control Message Protocol |Tool | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | | Version 6 (IPv6) Specification | | | | | [ICMPv6] | | | | +--------------------------------------+-----+----------+ These two RFCs do not define "Tools" (as indicated by the table). Further, = traceroute can use UDP (or any IP protocol really) and ICMP errors in addi= tion to ICMP. | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching [ICMP-Ext] | | | | +--------------------------------------+-----+----------+ Is this IP traceroute, MPLS OAM, both? Table 2 summarizes the OAM standards mentioned in this document. Table 2 seems to summarize something different. This sentence should read s= imilar to the legend of the Table. 2. Basic Terminology Basic terminology and abbreviations should have taken place before all the = previous discussion. FEC Forwarding Equivalence Class LDP Label Distribution Protocol The document says that control-plane OAM functions are out of scope. Howeve= r, some control plane functions are explained (and others are not). LSP Pin= g, for example, compares forwarding with control plane. LDP here is control= plane. 3.1.1. Ping 3.1.2. Traceroute Please note that the comments about PING and traceroute already mentioned a= pply equality to these sections. Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover the path between an IP source and an IP destination. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending This is describing a specific implementation of traceroute. Some stacks use= ICMP probes in traceroute. tcptraceroute uses, well, TCP SYNs as probes, b= ecause it is more friendly to detecting the final hop destination if it is = for example a web server. traceroute-nanog and others allow to specify whic= h IP protocol and which ports. Traceroute implementations), each with an IP Time-To-Live (TTL) value [and hop limit for IPv6] the first router in the path. That router responds by sending three ICMP Time Exceeded Messages to the Traceroute application. Traceroute This, as written, seems misleading. It does not "respond by sending three I= CMP time exceeded messages"=85=20 Note that IP routing may be asymmetric. While Traceroute reveals the path between a source and destination, it may not reveal the reverse path. See above, this also assumes "the one and only path". This reveals the path= for that specific flow used in the probes. A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These extensions augment the ICMP Destination Unreachable message, and can be used by Traceroute applications. Some extensions, for example ICMP-Int, are not only defined in the context = of Traceroute.=20 They also augment many other ICMPs beyond dest unreach. 3.3. MPLS OAM LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: 3.4.2. Generic Associated Channel The G-ACh section is a sub-section of MPLS-TP. However, this is a generic M= PLS mechanism. 3.4.3.5. Alarm Reporting Is this a management plane function? 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW-ACH]), and allows transmitting the OAM packets in-band with PW data (using CC Type 1: In-band VCCV). This describes Type 1 VCCV CC Type. However it does not describe Types 2 an= d 3=85 3.7. Summary of OAM Functions OWAMP and TWAMP also support CC and CV. 4. Security Considerations I would think that for a document chartered with providing an overview of O= AM mechanisms, a discussion of security considerations of OAM functions (ab= stracted from the protocols and tools) would be most useful, much than the = current "check every RFC we point to". Nits:=20 idnits calls out a couple nits about the References: http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-opsa= wg-oam-overview-08.txt Section 1.2: The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this :s/or/and/ ? Ping], is an OAM mechanism for point to point MPLS LSPs. It point-to-point ? An MP is a bridge interface, that is monitored by an OAM protocol :s/,// ? 3.2. Bidirectional Forwarding Detection (BFD) Has the BFD WG reviewed these sections? 3.3. MPLS OAM LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: LSP Ping is not "based" on ICMP Ping. It is modeled after the ping/tracerou= te paradigm, which is quite different! o "Ping" mode: In this mode LSP ping is used for end-to-end connectivity verification between two LERs. IP Ping is not used for connectivity verification -- it is used for continu= ity check, however the text implies they are used equivalently. 3.4.3.2. Route Tracing The document seems to use interchangeably "route trace", "path trace", and = other variations. I hope these are clear and useful! Thank you, Carlos Pignataro. From huawei.danli@huawei.com Mon Jan 21 23:22:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4994D21F8853; Mon, 21 Jan 2013 23:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=-3.168, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr01HkJ9rj0Y; Mon, 21 Jan 2013 23:22:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 07A7A21F8889; Mon, 21 Jan 2013 23:22:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOZ59716; Tue, 22 Jan 2013 07:21:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 07:21:10 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 15:21:20 +0800 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.229]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Tue, 22 Jan 2013 15:21:14 +0800 From: "Lidan (Dan)" To: Julien Meuric , "rtg-ads@tools.ietf.org" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-lmp-behavior-negotiation-09 Thread-Index: AQHN9Z1YfEeXA56mpE2FuDMjaUncdphU9SHQ Date: Tue, 22 Jan 2013 07:21:13 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> References: <50F97FAC.3010903@orange.com> In-Reply-To: <50F97FAC.3010903@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "ccamp@ietf.org" Subject: [RTG-DIR] =?gb2312?b?tPC4tDogW0NDQU1QXSBSdGdEaXIgcmV2aWV3OiBkcmFm?= =?gb2312?b?dC1pZXRmLWNjYW1wLWxtcC1iZWhhdmlvci1uZWdvdGlhdGlvbi0wOQ==?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 07:22:57 -0000 SnVsaWVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIHdlIHdpbGwgdXBkYXRlIHRoZSBkcmFm dCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4gDQoNCk9uZSBjb21tZW50IG5lZWRzIHlvdXIg Y2xhcmlmaWNhdGlvbjoNCi0gcy9mdW5jdGlvbnMgZGVmaW5lZCBpbiB0aGF0IGRvY3VtZW50L2Z1 bmN0aW9ucyBzcGVjaWZpZWQgaW4gdGhhdCB2ZXJ5IGRvY3VtZW50LyAgW3JlcGV0aXRpb24gb2Yg ImRlZmluZWQiXQ0KRm9yIGFkZGluZyAidmVyeSIsIGlzIGl0IGEgdHlwbz8NCg0KRm9yIHRoZSBy ZWZlcmVuY2UgW0xNUC1URVNUXSwgd2Ugd2lsbCBjaGVjayB3aXRoIHRoZSBhdXRob3JzIG9mIGRy YWZ0LWNlY2N6aGFuZy1jY2FtcC1nbXBscy1nNzA5djMtbG1wLCB0byBzZWUgd2hhdCdzIHRoZWly IGludGVudGlvbi4NCg0KVGhhbmsgeW91IGFnYWluIQ0KDQpEYW4NCg0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIEp1bGllbiBNZXVyaWMNCreiy83KsbzkOiAyMDEzxOox1MIxOcjVIDE6 MDANCsrVvP7IyzogcnRnLWFkc0B0b29scy5pZXRmLm9yZw0Ks63LzTogZHJhZnQtaWV0Zi1jY2Ft cC1sbXAtYmVoYXZpb3ItbmVnb3RpYXRpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGll dGYub3JnOyBjY2FtcEBpZXRmLm9yZw0K1vfM4jogW0NDQU1QXSBSdGdEaXIgcmV2aWV3OiBkcmFm dC1pZXRmLWNjYW1wLWxtcC1iZWhhdmlvci1uZWdvdGlhdGlvbi0wOQ0KDQpIZWxsbywNCg0KSSBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIA0KVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFs bCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCANCmRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcuIFRoZSBwdXJwb3NlIA0Kb2YgdGhlIHJl dmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9y ZSANCmluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2Vl IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlL3JvdXRpbmcuaHRtbA0KDQpB bHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBS b3V0aW5nIEFEcywgaXQgDQp3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0 aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgDQpMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5 b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCANCmRpc2N1c3Np b24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1jY2Ft cC1sbXAtYmVoYXZpb3ItbmVnb3RpYXRpb24tMDkNClJldmlld2VyOiBKdWxpZW4gTWV1cmljDQpS ZXZpZXcgRGF0ZTogMTggSmFudWFyeSAyMDEzDQpJRVRGIExDIEVuZCBEYXRlOiAyMSBKYW51YXJ5 IDIwMTMNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNCipTdW1tYXJ5OioNClRo aXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBu aXRzIHRoYXQgDQpzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBpdC4NCg0KKkNvbW1lbnRz OioNClRoaXMgZG9jdW1lbnQgaXMgY2xlYXJseSB3cml0dGVuIGFuZCBlYXN5IHRvIHVuZGVyc3Rh bmQuIFRoZSBkZWZpbmVkIA0KbWVjaGFuaXNtIGlzIHNpbXBsZSBhbmQgd2VsbCBzcGVjaWZpZWQu DQoNCipOaXRzOioNCkFic3RyYWN0DQotSW5zdGVhZCBvZiAiR01QTFMgbmV0d29ya3MiLCAiR01Q TFMtY29udHJvbGxlZCBuZXR3b3JrcyIgcmVhZHMgbW9yZSANCmFjY3VyYXRlIHRvIG1lLiBJdCB3 b3VsZCBhbHNvIGFsaWduIG9uIHRoZSBwaHJhc2UgdXNlZCBpbiB0aGUgDQppbnRyb2R1Y3Rpb24u IFRoZSByZXN1bHRpbmcgIkdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5n IA0KKEdNUExTKS1jb250cm9sbGVkIG5ldHdvcmtzIiBtYXkgYmUgY2hlY2tlZCB3aXRoIHRoZSBS RkMgRWRpdG9yLg0KDQpJbnRyb2R1Y3Rpb24NCi0gcy9MTVAgbm9kZS9MTVAtY2FwYWJsZSBub2Rl Lw0KLSBzL2Z1bmN0aW9ucyBkZWZpbmVkIGluIHRoYXQgZG9jdW1lbnQvZnVuY3Rpb25zIHNwZWNp ZmllZCBpbiB0aGF0IHZlcnkgDQpkb2N1bWVudC8gIFtyZXBldGl0aW9uIG9mICJkZWZpbmVkIl0N Ci0gcy90aGUgbWVzc2FnZSB0eXBlcyBmcm9tL3RoZSB0eXBlcyBmcm9tLyAgW3JlcGV0aXRpb24g b2YgIm1lc3NhZ2UiXQ0KDQpTZWN0aW9uIDIuMg0KLSBzL01BWSBpbmNsdWRlLCBIZWxsb0NvbmZp Zy9NQVkgaW5jbHVkZSBIZWxsb0NvbmZpZy8NCg0KU2VjdGlvbiAzLjENCi0gcy9udW1iZXIgb2Yg TUJaIGJpdHMgZmllbGQvbnVtYmVyIG9mIGJpdHMgaW4gTUJaIGZpZWxkLw0KDQpTZWN0aW9uIDQN Ci0gcy9bUkZDNDIwMl0gZGVmaW5lZC9bUkZDNDIwMl0tZGVmaW5lZC8NCg0KU2VjdGlvbiA5LjIN Ci0gSSB0ZW5kIHRvIHRoaW5rIHRoYXQgW0xNUCBURVNUXSBzaG91bGQgbm93IHJlZmVyZW5jZSAN CmRyYWZ0LWNlY2N6aGFuZy1jY2FtcC1nbXBscy1nNzA5djMtbG1wDQoNCg0KRW5qb3kgdGhlIHdl ZWstZW5kLA0KDQpKdWxpZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From julien.meuric@orange.com Tue Jan 22 01:08:10 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6533621F8526; Tue, 22 Jan 2013 01:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEpyT3-R2jG7; Tue, 22 Jan 2013 01:08:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B321F84D3; Tue, 22 Jan 2013 01:08:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 70BB81074003; Tue, 22 Jan 2013 10:12:57 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 658561074001; Tue, 22 Jan 2013 10:12:57 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 10:08:07 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 10:08:06 +0100 Message-ID: <50FE56F5.8040806@orange.com> Date: Tue, 22 Jan 2013 10:08:05 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Lidan (Dan)" References: <50F97FAC.3010903@orange.com> <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> In-Reply-To: <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jan 2013 09:08:06.0150 (UTC) FILETIME=[FD850260:01CDF87F] Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "ccamp@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-ccamp-lmp-behavior-negotiation-09?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 09:08:10 -0000 Hi Dan. You're welcome. I've added "very" on purpose, to emphasize what document the sentence was referring to (i.e. the RFC mentioned at the beginning of that very same sentence, not at the end of the previous one). It was just a suggestion, it isn't mandatory to keep it if you feel it's more confusing than clarifying. You may also check with a native English speaker (e.g. the RFC Editor), who I'm not. Regards, Julien Le 22/01/2013 08:21, Lidan (Dan) a écrit : > Julien, > > Thanks for the review, we will update the draft according to your comments. > > One comment needs your clarification: > - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] > For adding "very", is it a typo? > > For the reference [LMP-TEST], we will check with the authors of draft-cecczhang-ccamp-gmpls-g709v3-lmp, to see what's their intention. > > Thank you again! > > Dan > > -----邮件原件----- > å‘件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Julien Meuric > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 > Reviewer: Julien Meuric > Review Date: 18 January 2013 > IETF LC End Date: 21 January 2013 > Intended Status: Standards Track > > *Summary:* > This document is basically ready for publication, but has nits that > should be considered prior to it. > > *Comments:* > This document is clearly written and easy to understand. The defined > mechanism is simple and well specified. > > *Nits:* > Abstract > -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more > accurate to me. It would also align on the phrase used in the > introduction. The resulting "Generalized Multiprotocol Label Switching > (GMPLS)-controlled networks" may be checked with the RFC Editor. > > Introduction > - s/LMP node/LMP-capable node/ > - s/functions defined in that document/functions specified in that very > document/ [repetition of "defined"] > - s/the message types from/the types from/ [repetition of "message"] > > Section 2.2 > - s/MAY include, HelloConfig/MAY include HelloConfig/ > > Section 3.1 > - s/number of MBZ bits field/number of bits in MBZ field/ > > Section 4 > - s/[RFC4202] defined/[RFC4202]-defined/ > > Section 9.2 > - I tend to think that [LMP TEST] should now reference > draft-cecczhang-ccamp-gmpls-g709v3-lmp > > > Enjoy the week-end, > > Julien > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Jan 22 06:25:48 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4021F87FB for ; Tue, 22 Jan 2013 06:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.41 X-Spam-Level: X-Spam-Status: No, score=-101.41 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7M68IwCyRWz for ; Tue, 22 Jan 2013 06:25:47 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id A0E0A21F8865 for ; Tue, 22 Jan 2013 06:25:47 -0800 (PST) Received: (qmail 13441 invoked by uid 0); 22 Jan 2013 14:25:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 22 Jan 2013 14:25:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UrxBi/j/0MewN3J9XQLWguN2GzhRnxkI4Wd42wYbJRs=; b=OKOVZisOgxDJH8I7WPw9PVjBjdxVCwtyk5nbdACsjR6FddiQkwhFenusj9RtqeHUCC777OgAwxSnVvgdTtbeD9vTZBEOp/BB2H0tBgs157QGMTrg6nRF77ncq0dGU07l; Received: from box313.bluehost.com ([69.89.31.113]:46948 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Txemy-0003aV-8d; Tue, 22 Jan 2013 07:25:24 -0700 Message-ID: <50FEA15E.6040801@labn.net> Date: Tue, 22 Jan 2013 09:25:34 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julien Meuric References: <50F97FAC.3010903@orange.com> <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> <50FE56F5.8040806@orange.com> In-Reply-To: <50FE56F5.8040806@orange.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "Lidan \(Dan\)" , "ccamp@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-ccamp-lmp-behavior-negotiation-09?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:25:48 -0000 Julien/Dan, Some comments below (as coauthor). On 1/22/2013 4:08 AM, Julien Meuric wrote: > Hi Dan. > > You're welcome. > > I've added "very" on purpose, to emphasize what document the sentence > was referring to (i.e. the RFC mentioned at the beginning of that very > same sentence, not at the end of the previous one). It was just a > suggestion, it isn't mandatory to keep it if you feel it's more > confusing than clarifying. You may also check with a native English > speaker (e.g. the RFC Editor), who I'm not. > IMO the use of "very" is 100% stylistic. I don't think it causes any harm or provides any substantive benefit. It also doesn't matter to me if it's included or not... > Regards, > > Julien > > > Le 22/01/2013 08:21, Lidan (Dan) a écrit : >> Julien, >> >> Thanks for the review, we will update the draft according to your comments. >> >> One comment needs your clarification: >> - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] >> For adding "very", is it a typo? >> >> For the reference [LMP-TEST], we will check with the authors of draft-cecczhang-ccamp-gmpls-g709v3-lmp, to see what's their intention. Rather than reference an individual draft, my suggestion is to just drop the whole sentence. It doesn't really add much in any case. The other comments all look good to me. Much thanks! Lou >> >> Thank you again! >> >> Dan >> >> -----邮件原件----- >> å‘件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Julien Meuric >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 >> Reviewer: Julien Meuric >> Review Date: 18 January 2013 >> IETF LC End Date: 21 January 2013 >> Intended Status: Standards Track >> >> *Summary:* >> This document is basically ready for publication, but has nits that >> should be considered prior to it. >> >> *Comments:* >> This document is clearly written and easy to understand. The defined >> mechanism is simple and well specified. >> >> *Nits:* >> Abstract >> -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more >> accurate to me. It would also align on the phrase used in the >> introduction. The resulting "Generalized Multiprotocol Label Switching >> (GMPLS)-controlled networks" may be checked with the RFC Editor. >> >> Introduction >> - s/LMP node/LMP-capable node/ >> - s/functions defined in that document/functions specified in that very >> document/ [repetition of "defined"] >> - s/the message types from/the types from/ [repetition of "message"] >> >> Section 2.2 >> - s/MAY include, HelloConfig/MAY include HelloConfig/ >> >> Section 3.1 >> - s/number of MBZ bits field/number of bits in MBZ field/ >> >> Section 4 >> - s/[RFC4202] defined/[RFC4202]-defined/ >> >> Section 9.2 >> - I tend to think that [LMP TEST] should now reference >> draft-cecczhang-ccamp-gmpls-g709v3-lmp >> >> >> Enjoy the week-end, >> >> Julien >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > From Alexander.Vainshtein@ecitele.com Wed Jan 23 23:15:53 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8616C21F8607 for ; Wed, 23 Jan 2013 23:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5+s1sMKqTE6 for ; Wed, 23 Jan 2013 23:15:33 -0800 (PST) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 54FBB21F85AD for ; Wed, 23 Jan 2013 23:15:30 -0800 (PST) Received: from [85.158.143.99:24294] by server-2.bemta-4.messagelabs.com id CB/D2-03518-19FD0015; Thu, 24 Jan 2013 07:15:29 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1359011715!22253337!10 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17792 invoked from network); 24 Jan 2013 07:15:27 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jan 2013 07:15:27 -0000 X-AuditID: 93eaf2e7-b7f606d000007244-4b-5100d7b4e5c1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7C.26.29252.4B7D0015; Thu, 24 Jan 2013 08:41:56 +0200 (IST) Received: from ILPTWPVEXCA02.ecitele.com (172.31.244.232) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 24 Jan 2013 09:15:26 +0200 Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 09:15:25 +0200 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt Thread-Index: Ac36Ao1HqvFKDMuXT06bsXdiJyKPmw== Date: Thu, 24 Jan 2013 07:15:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/mixed; boundary="_004_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA7VUX0xbVRzm9F7a25a73XUwzurimituOtemzVzAjBLNHpwzEchIjPqwXdpj e7W9bXrLMiBZqolkq2wZzhG4aRibFRb+iANFzDbBupkJGlqRDI2buK1pAKcLks3NBDy3t0US XnzxPH2/73y/f19yDkUYxrRGiheCKCBwHlatI0/Ozi+YP72WU2kdntCXpCKtZEl7T1LzrGpP NPpAtWdh4k91herVECjlBMEX5ILI5ESiw85WBPiDnKOWNfFOO2tjTX4P50BeJATtLOf3I8HJ lulMq04plvGCCQkOn5MXXHb2hX3l5pKSnc+YbWzZlsdsO3bpqty8aEJmL8d7TF4kipwLmTBz 4BPCvXjzXq7/h/fyDl2d7yJC4PsJXRhoKcg8DRevfKRR8AYYv9GnDgMdZWCGAbyc+IxUgiEA /z51nlCCKwA2L7Tkyilqxg77u6+rZZzP7ITHl+LpUgQjAdjw9S4Zr2fK4Nud7RpFsxueaL0D woDC2AKXRjwyTTKPw7GOuxqZppkKmPxgi0wDPND90R6VUrEQ/nT7tEoZNB/+mhhTK7gAztxa zFXwZpi4O53R8/DOL42kjGlmHfym9XYaGxgzHL0aztTZCL88N0WeABukFS2kFenSinSF90Hp u161grfD9gvzGfwU7DgzR2TxtyO3VKv5TXDg1FEgYRcJ5h0Af46Pp0VZF6W0Q8Xwq5FmtSKK AHimoRFIGRtD5y7mShkbP5/qJRVsgePxNo2U9rEITva3AmXqcjjZd1yT3Sx5bDDdADIMjF4c J6QV5mU3a54+Saze+L9v2Q4e6QIFvMcfrPa6rDYLcvBB5EEWh8/bD5T3khoCD08XxQBDATaP fmJ7TqUhlzso1npjYCOlYgvoxHVMran2OWvdnOjeH6jxIDEGinCPmx93x4GRFHwCYvNpXwzr aCdXW4cCvqysAWAPmgij3uHDz1QI7t9htf6PAVtId4ZeLjcwLvy230TIjwLZSTZRFAvplht4 yHUB5EKHXuc9wX+vVZQ2BiCVhxcJyxpa9HNekXcp96PATLU0NaaAIb2tsZB+QxYxsshdIyzX yf5Bs6AQ27mefk5W5eEfarnSLG6iwk2GpaUK3AT/QctXxhDQ1mx9bVB7KSeafHLb+OW9dWfX vBvpet4/9FDfd/+vqrbfEqa9g731r8x1frj2cGpzsXRM7fwx8GiP8Xxl0b23DlyIvOg9AvXu 36MDTL0eHPlja+SaZeZo077SuuQXA+9POxzFbTP1c2s72qYmnSk0THoXa6zx/Gh14BLRMvjS 7u4qlhTdnG0bERC5fwCzillxXgUAAA== Cc: "rtg-dir@ietf.org" , "'drafts-ietf-opsawg-oam-overview.all@tools.ietf.org'" Subject: [RTG-DIR] RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 07:15:53 -0000 --_004_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_ Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_" --_000_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The= Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review. The purpose of the revie= w is to provide assistance to the Routing ADs. For more information about th= e Routing Directorate, please see http://www.ietf.org/iesg/directorate/routi= ng.html Although these comments are primarily for the use of the Routing ADs, it wou= ld be helpful if you could consider them along with any other IETF Last Call= comments that you receive, and strive to resolve them through discussion or= by updating the draft. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 23-Jan-13 IETF LC End Date: Not known Intended status: Informational Summary: I have significant concerns about this document and recommend that the Routi= ng ADs discuss these issues further with the authors. To some extent these concerns reflect my personal and potentially biased pos= ition with regard to OAM. In addition, I'd like note that this is my second review of this draft. The= previous one has been done in August 2011 and dealt with the -05 version of= the draft (the review is attached). Following this review I've hold a serie= s of email exchanges and off-line meetings with some of the authors in an at= tempt to resolve the issues I've raised; but this process has not ever been= completed. My current review hence is mainly focused on resolution (or lack thereof) of= the concerns I've raised in the previous review round. This can be also con= sidered as a bias (of a kind). Hence I ask - again - the Routing ADs to take= my comments with a grain of salt. Comments: The needs of the assumed target audience are not fully addressed in the draf= t: Just as in the previous reviewing cycle, I assume that the intended target a= udience of the draft consists of various "beginner" groups. The current version does not contain any indications that this assumption is= wrong (actually I did not find anything special about target audience in th= e draft). Taking into account ongoing OAM-related activities at the IETF (e.= g., draft-mmm-bfd-on-lags), a good overview document would be indeed most us= eful for these groups. Based on this assumption I've then suggested that in order to provide approp= riate guidance to the target audience, the draft should: 1. Include a section on historical background of OAM - not addressed i= n the reviewed version of the draft. a. The single sentence "OAM was originally used in the world of teleph= ony, and has been adopted in packet based networks" that has served as a som= ewhat short background section has disappeared in this version of the draft b. IMHO and FWIW absence of such a section makes it difficult for, say,= a reader with the background in OAM in SONET/SDH and/or OTN networks to und= erstand why OAM in packet networks is so different. 2. Present a clear view of OAM functionality and its relationship to v= arious "planes" of networking - at best, partially addressed in Section 1.2.= However, the new text seems potentially misleading to me, e.g.: a. The statement "often the on-demand tools may be activated by the ma= nagement" seems to suggest that on-demand OAM tools can be also activated in= some other way. If the intention has been activation of such tools via the= control plane, clarification would be very much in place b. Connectivity Verification (CV) is mentioned as one of the "OAM build= ing blocks" (in Section 1.1), and the draft explains that CV is used to veri= fy that it is used "to verify that the OAM messages are received through the= expected path". However, the draft does not explain that the expected path= is defined either by the management or by the control plane, so that the en= tire CV function does not make much sense without this interaction. 3. Explain the importance of fate-sharing of OAM and user traffic flow= s in packet networks - at best, partially addressed by the current version o= f the draft: a. The term "fate-sharing" does not appear in the draft at all b. The draft mentions that in MPLS-TP "OAM packets and the user traffic= are required to be congruent" (Section 3.4.1). However, this is not extende= d to OAM tools for other IETF-owned technologies (IP, IP/MPLS). A side note: I am not sure that "congruent flows" and "fate-sharing flows" m= ean exactly the same thing. E.g., in IP/MPLS networks LSPs created by LDP ar= e supposed to be congruent with IP flows, but they are not fate-sharing. 4. Explicitly map the notions, terms and methods that have been adopte= d from technologies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned t= echnologies - not addressed. E.g.: a. The term "interface" that is, from my point of view one of the basi= c notions in the IETF networking, appears in the draft just 3 times: i. Two of the search= hits are in the title of RFC 5837 (which is listed in the draft as one of t= he OAM tools without any explanation and then again as a normative reference= ) ii. The remaining hit i= s in Section 2.2.3 in the context of differences in MEP definitions between= ITU-T Y.1731 and IEEE 802.1ag and deals with bridge interfaces, i.e., out o= f scope A side note: At the same time the draft mentioned the importance of placemen= t of an MP (ingress, egress or forwarding function) in Section 2.2.3. I will= present my concerns regarding this text later. b. The draft mentions ICMP ping and Traceroute as an "OAM tools", but i= t does not even try to explain: i. What constitutes t= he ME in which these tools operate ii. What are its MEPs a= nd MIPs etc. (see also some comments below) c. The draft effectively ignores recent OAM-related activities as RFC= 5837 (see above) and draft-ietf-mpls-tp-mep-mip-map. IMHO and FWIW, these d= ocuments are triggered by real-life operational concerns on one hand and imp= licitly (as in RFC 5837) or even explicitly deal with relationships between= interfaces and nodes on one hand and MPs on the other hand. The caveat abou= t dealing just with published RFCs may or may not be valid per se, but it de= finitely does not justify lack of any explanations/details regarding RFC 538= 7. 5. Expose, rather than avoid, known points of contention in a neutral= way - I do not see this as a serious issue now. The bottom line is that the current version of the draft did not meet my exp= ectations in this regard. This -again - may be because my expectations have= been exaggerated or even completely unrealistic, or because the authors had= in mind a different target audience and a different purpose. (I've said in= my first review that explicitly specifying these (the purpose and the targe= t audience) in the Introduction section would be helpful - but this has not= been done either.) Readability of the draft: >From my point of view the draft still is not easily readable. I'd like to pi= nt specifically to the following: not in the least because it contains quite a few inaccurate and/or controver= sial statements. E.g.: 1. Some terms and notions are introduced in the draft as if they were= quite important, only to be forgotten later. E.g.: a. Section 1.1 mentions "Throughput measurement" as one of the 3 main= functions of the performance monitoring which, in its turn, is defined as o= ne of the OAM building blocks. However, throughput measurement is not mentio= ned anywhere else in the draft. b. "Communication link" mentioned in Section 2.2.2 is another such exam= ple c. The first statement in Section 1.1 states that "An OAM protocol is= run in the context of a Maintenance Domain, consisting of two or more nod= es that run the OAM protocol, referred to as Maintenance Points (MP)", but,= again, Maintenance Domain is not mentioned anywhere else in the draft, leav= ing the reader to wonder how it is related to MEs, MEGs and the rest of the= acronym soup. 2. Some referenced IETF documents are misrepresented. E.g.,: a. MPLS LSP Ping is mentioned in Section 1.3 as an "OAM mechanism for= point to point MPLS LSPs". In fact, LSP ping works just fine with LSPs crea= ted by LDP, and these are MP2P b. In Section 2.2.3 the draft claims that MPLS-TP "uses ... Up/Down MP= s" and refers to RFC 6371 as its source. However, the corresponding text in= RFC 6371 only mentions Up/Down MEPs. (In this regard it is fully consistent= with both IEEE 802.1ag and ITU-T Y.1731). 3. There are internal inconsistencies in the draft. E.g.: a. The naive interpretation of the already quoted statement from secti= on 1.1 (see 1c above) is that "MPs are nodes" b. At the same time Section 2.3.3 states that "A Maintenance Point (MP)= is a functional entity that is defined at a node in the network, and either= initiates or reacts to OAM messages". Major Issues: 1. OAM and its relationship to various network planes: In spite of the= authors' attempt to resolve this issue, the concepts of data plane, control= plane and management plane still are not properly explored in the draft: a. The term "data-plane" (with some modifications) is only found in Se= ction 4.3 when discussing LSP-Ping ("data plane" is also found in the title= of RFC 4379) b. An additional term "forwarding plane" appears in section 1.2, but no= where else. The draft does not explain whether it means the same as data pla= ne or not c. The terms "control-plane" ("control plane") are a bit more popular.= They can be found: i. In Sec= tion 1.2 (which states that "OAM tools are defined independent of control pl= ane" and that considerations of the control plane maintenance tools are out= of scope) ii. In Sect= ion 3.3 (MPLS OAM) that explains that LSP Ping verifies "data-plane vs. cont= rol-plane consistency for FEC". This statement is correct, but IMO inconsist= ent with the previous one (see also my comment about CV above) iii. In Secti= on 3.4 (MPLS-TP OAM) - mainly to explain that control plane is neither manda= tory nor precluded in MPLS-TP d. The term "management plane" (with or without dash) appears only in S= ection 1.2. In addition to the already mentioned ability to operate on-deman= d OAM tools, ability of these tools to raise alarms is mentioned i. This i= s definitely a step forward vs. the -05 version ii. While R= FC 6427 is now referenced in the draft (it was missing in the previous versi= on), the draft does not mention alarm suppression function. And while it men= tions AIS in MPLS-TP it only points to RFC 6327 for the explanation of the c= onsequent actions of AIS. iii. For the= sake of completeness, ability to clear alarms should also be mentioned IMO= - but this is a very minor issue. e. The term "test plane" appears in Section 4.5, but, as already mentio= ned above, specific test plane protocols are not discussed in the draft 2. OAM in connectionless vs. connection-oriented networks a. The first sentence in Section 1 states that "OAM is a general term= that refers to a toolset for detecting, isolating and reporting connection= failures and performance degradation". To me this suggests that OAM is appl= icable only to connection-oriented networks (if you do not have connections,= connection problems do not exist by definition). b. The term "connection" appears in some other places in the draft, e.g= ., the connectivity check "is used to verify the liveness of a connection" (= Section 1.1). c. At the same time, the draft discusses: i. ICMP P= ing (Section 3.1.1) operating in connectionless IP networks ii. LSP-Pin= g in MPLS networks (Section 3.3). Since LSP-Ping as defined in RFC 4379 is a= pplicable to LSPs set up by LDP, I'd say that it operates in connectionless= environment iii. Ethernet= OAM (1.5) operating in connectionless Ethernet networks etc. 3. The Mess of MEs, MPs, MEPs and MIPs. a. Please consider the following text fragments i. (In se= ction 2.2.2) OAM tools are designed to monitor and manage a Maintenance Enti= ty (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between t= wo points of a transport path to which maintenance and monitoring operations= apply. ii. (ibid.)= Various terms are used to refer to an ME. For example, BFD does not explici= tly use a term that is equivalent to ME, but rather uses the term "session",= referring to the relationship between two nodes using a BFD protocol. The M= PLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this con= text iii. (In Sect= ion 2.2.3) A Maintenance Point (MP) is a functional entity that is defined a= t a node in the network, and either initiates or reacts to OAM messages. A M= aintenance End Point (MEP) is one of the end points of an ME, and can initia= te OAM messages and respond to them. A Maintenance Intermediate Point (MIP)= is an intermediate point between two MEPs, that does not generally initiate= OAM frames (one exception to this is the use of AIS notifications), but is= able to respond to OAM frames that are destined to it. iv. (Ibid.)= MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP= - either at the ingress, egress, or forwarding function of the node (Down /= Up MPs). This placement is important for localization of a connection fail= ure. b. The last of these statements seems to hint that with just two mutua= lly exclusive types of MPs (UP/DOWN) it is possible to associated an MP with= one of 3 possible placements (ingress, egress or forwarding function). c. IMHO and FWIW combining these statements can result in some unexpec= ted (and undesirable) conclusions. E.g., i. Premis= es: * An MPLS LSP is an ME in the case of LSP Ping * An ME defines a point-to-point relationship between two points on= a transport path * These points are defined at nodes Conclusion: An MPLS LSP can cross only two nodes (because in IP/MPLS LSP Pin= g can be initiated from any node participating in an LSP). ii. Premise= s: * BFD as defined in RFC 5880 is an OAM tool (it is listed as such in Tab= le 1 in section 1.4) * OAM tools are designed to monitor MEs * In the case of a BFD a BFD session (there are no other sessions in RF= C 5880) is an ME Conclusion: BFD is designed to monitor its own sessions (and hence is comple= tely useless). A Side Note: The majority of problematic definitions in the draft are based= on RFC 6371. IMHO and FWIW this results in 3 types of problems: * The authors misinterpret RFC 6371. E.g., it only speaks about UP a= nd DOWN MEPs, not about UP and DOWN MPs , and it does not discuss ingress/eg= ress/forwarding engine placement * The authors have tried to extend the definitions from 6371 to othe= r IETF technologies (IP and IP/MPLS). E.g., in MPLS-TP sending LSP-Ping pack= ets from an intermediate node of a co-routed bi-directional LSP towards one= of its endpoints is possible, but the responses would not be received by th= e initiator... * Some of the original definitions in 6371 are problematic (among ot= her things, this applies to UP and DOWN MEPs). Minor Issues: 1. Limited coverage of performance measurement. a. The draft mentions packet loss, delay/delay variation and the (undi= sclosed) throughput measurement. b. At the same time it ignores such issues as duplication and reorderin= g (and does not mention RFC 4347 and RFC 5560 respectively) c. Connectivity measurement (RFC 2678) is referenced and mentioned in= the text. But it is not mapped to any of the main performance measurements= functions 2. Proposed classification of the IETF documents (into tools, profiles= , infrastructure and miscellaneous) could be useful but is not consistently= applied. E.g., a. I do not think that RFC 792 defines an OAM Tool b. I have serious doubts that RFC 4556 and RFC 5337 (defining the contr= ol plane for the IPPM mechanisms) are "OAM Tools" while all the referenced s= pecific measurement protocols are "Miscellaneous" etc. Unfortunately could not provide any useful information regarding nits, typos= etc. My review is incomplete in this regard, and I owe apologies to Routing= ADs, my colleagues in the Routing Directorate and the authors. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hello,

 

I have been selected as the Routing Di= rectorate reviewer for this draft. The Routing Directorate seeks to review a= ll routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide ass= istance to the Routing ADs. For more information about the Routing Directora= te, please see http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are primarily= for the use of the Routing ADs, it would be helpful if you could consider t= hem along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating t= he draft.

 

Document: draft-ietf-opsawg-oam-overvi= ew-08.txt

Reviewer: Alexander (“Sasha̶= 1;) Vainshtein   

Review date: 23-Jan-13

IETF LC End Date: Not known=

Intended status: Informational

 

Summary:

 

I have significant concerns about this= document and recommend that the Routing ADs discuss these issues further wi= th the authors.

 

To some extent these concerns reflect= my personal and potentially biased position with regard to OAM.

 

In addition, I’d like note that= this is my second review of this draft. The previous one has been done in A= ugust 2011 and dealt with the -05 version of the draft (the review is attached). Following this review I’ve hold a series of emai= l exchanges and off-line meetings with some of the authors in an attempt to= resolve the issues I’ve raised; but this process has not ever been co= mpleted.

 

My current review hence is mainly focu= sed on resolution (or lack thereof) of the concerns I’ve raised in the= previous review round. This can be also considered as a bias (of a kind). Hence I ask – again - the Routing ADs to take my comment= s with a grain of salt.

 

Comments:

 

The needs of the assumed target= audience are not fully addressed in the draft:

 

Just as in the previous reviewing cycl= e, I assume that the intended target audience of the draft consists of vario= us “beginner” groups. 

The current version does not contain a= ny indications that this assumption is wrong (actually I did not find anythi= ng special about target audience in the draft). Taking into account ongoing OAM-related activities at the IETF (e.g., draft-mmm-bf= d-on-lags), a good overview document would be indeed most useful for these g= roups.

 

Based on this assumption I’ve th= en suggested that in order to provide appropriate guidance to the target aud= ience, the draft should:

 

1.     =   Inclu= de a section on historical background of OAM – not addressed in the reviewed version of the draft.

a.     =   The sing= le sentence “OAM was originally used in the world o= f telephony, and has been adopted in packet based networks” tha= t has served as a somewhat short background section has disappeared in this= version of the draft

b.      IMHO and= FWIW absence of such a section makes it difficult for, say, a reader with t= he background in OAM in SONET/SDH and/or OTN networks to understand why OAM in packet networks is so different.=

2.     =   Prese= nt a clear view of OAM functionality and its relationship to various “= planes” of networking – at best, partially addressed in Section 1.2. However, the new text= seems potentially misleading to me, e.g.:

a.     =   The stat= ement “often the on-demand tools may be activated by the management” seems to suggest that on-demand OAM t= ools can be also activated in some other way. If the intention has been acti= vation of such tools via the control plane, clarification would be very much= in place

b.      Connecti= vity Verification (CV) is mentioned as one of the “OAM building blocks= ” (in Section 1.1), and the draft explains that CV is used to verify that it is used “to verify that the OAM messages are receiv= ed through the expected path”. However, the draft does not explain tha= t the expected path is defined either by the management or by the control pl= ane, so that the entire CV function does not make much sense without this interaction.

3.     =   Expla= in the importance of fate-sharing of OAM and user traffic flows in packet ne= tworks – at best, partially addressed by the current version of the draft: <= o:p>

a.     =   The term= “fate-sharing” does not appear in the draft at all

b.      The draf= t mentions that in MPLS-TP “OAM packets and the user traffic are required to be= congruent” (Section 3.4.1). However, this is not extended to OAM tool= s for other IETF-owned technologies (IP, IP/MPLS).

A side= note: I am not sure that “congruent flows̶= 1; and “fate-sharing flows” mean exactly the same thing. E.g., in IP/MPLS networks LSPs cr= eated by LDP are supposed to be congruent with IP flows, but they are not fa= te-sharing.

4.     =   Expli= citly map the notions, terms and methods that have been adopted from technol= ogies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned technologies – not addresse= d. E.g.:

a.     =   The term= “interface” that is, from my point of view one of the basic not= ions in the IETF networking, appears in the draft just 3 times:

     &n= bsp;            =             &nbs= p;            &n= bsp;      i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">Two of the search hits are in the title of RFC 5837 (which is lis= ted in the draft as one of the OAM tools without any explanation and then again as a normati= ve reference)

     &n= bsp;            =             &nbs= p;            &n= bsp;    ii.  = ;    = The remaining hit is in Section  2.2.3 in the context of di= fferences in MEP definitions between ITU-T Y.1731 and IEEE 802.1ag and deals with bridge interfaces, i.e= ., out of scope

&= nbsp;

A side= note: At the same time the draft mentioned the impor= tance of placement of an MP (ingress, egress or forwarding function) in Section 2= .2.3. I will present my concerns regarding this text later.

&nbs= p;

b.      The draf= t mentions ICMP ping and Traceroute as an “OAM tools”, but it do= es not even try to explain:

     &n= bsp;            =             &nbs= p;            &n= bsp;      i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">What constitutes the ME in which these tools operate

     &n= bsp;            =             &nbs= p;            &n= bsp;    ii.  = ;    = What are its MEPs and MIPs etc. (see also some comments below)

c.     =   The draf= t effectively ignores recent OAM-related activities as RFC 5837 (see above)= and draft-ietf-mpls-tp-mep-mip-map. IMHO and FWIW, these documents are triggered by real-life operational concerns on one hand and i= mplicitly  (as in RFC 5837) or even explicitly deal with relationships= between interfaces and nodes on one hand and MPs on the other hand. The cav= eat about dealing just with published RFCs may or may not be valid per se, but it definitely does not just= ify lack of any explanations/details regarding RFC 5387.

5.     =   Expos= e, rather than avoid, known points of contention in a neutral way= – I do not see this as a serious issue now.

 

The bottom line is that the current ve= rsion of the draft did not meet my expectations in this regard. This –= again - may be because my expectations have been exaggerated or even completely unrealistic, or because the authors had in mind a differ= ent target audience and a different purpose. (I’ve said in my first re= view that explicitly specifying these (the purpose and the target audience)= in the Introduction section would be helpful – but this has not been done either.)

 

Readability of the= draft:

 

From my point of view the draft still is not eas= ily readable. I’d like to pint specifically to the following:

not in the least because it contains quite a few inac= curate and/or controversial statements. E.g.:

1.     &n= bsp; Some terms and notions are= introduced in the draft as if they were quite important, only to be forgott= en later. E.g.:

a.       Section 1.1 mentions “= ;Throughput measurement” as one of the 3 main functions of the perform= ance monitoring which, in its turn, is defined as one of the OAM building bl= ocks. However, throughput measurement is not mentioned anywhere else in the draft.

b.      “Communication link&#= 8221; mentioned in Section 2.2.2 is another such example

c.       The first statement in Sect= ion 1.1 states that “An OAM protocol is run in the context of a Mainte= nance Domain,   consisting of two or more nodes that run the OAM p= rotocol, referred to as Maintenance Points (MP)”, but, again, Maintenance Domain is not mentioned anywhere else in the draft,= leaving the reader to wonder how it is related to MEs, MEGs and the rest of= the acronym soup.

2.     &n= bsp; Some referenced IETF docume= nts are misrepresented. E.g.,:

a.       MPLS LSP Ping is mentioned= in Section 1.3 as an “OAM mechanism for point to point MPLS LSPs̶= 1;. In fact, LSP ping works just fine with LSPs created by LDP, and these ar= e MP2P

b.       In Section 2.2.3 the= draft claims that MPLS-TP “uses ... Up/Down MPs” and refers to= RFC 6371 as its source. However, the corresponding text in RFC 6371 only me= ntions Up/Down MEPs. (In this regard it is fully consistent with both IEEE 802.1ag and ITU-T Y.1731).

3.     &n= bsp; There are internal inconsis= tencies in the draft. E.g.:

a.       The naive interpretation of= the already quoted statement from section 1.1 (see 1c above) is that “= ;MPs are nodes”

b.      At the same time Section 2.= 3.3 states that “A Maintenance Point (MP) is a functional entity that= is defined at a node in the network, and either initiates or reacts to OAM= messages”.

 

Major Issues:

 

 

1.     =   OAM a= nd its relationship to various network planes: I= n spite of the authors’ attempt to resolve this issue, the concepts of data p= lane, control plane and management plane still are not properly explored in= the draft: 

a.     =   The term= “data-plane” (with some modifications) is only found in Section= 4.3 when discussing LSP-Ping (“data plane” is also found in the title of RFC 4379)

b.      An addit= ional term “forwarding plane” appears in section 1.2, but nowher= e else. The draft does not explain whether it means the same as data plane or not

c.     =   The term= s “control-plane” (“control plane”) are a bit more p= opular. They can be found:

     &n= bsp;            =             &nbs= p;            &n= bsp;            =       i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">In Section 1.2 (which states that “OAM tools are defined in= dependent of control plane” and that considerations of the control plane maintenance tools= are out of scope)

     &n= bsp;            =             &nbs= p;            &n= bsp;            =     ii.  = ;    = In Section 3.3 (MPLS OAM) that explains that LSP Ping verifies &= #8220;data-plane vs. control-plane consistency for FEC”. This statement is correct, but IM= O inconsistent with the previous one (see also my comment about CV above)

     &n= bsp;            =             &nbs= p;            &n= bsp;            =   iii. &nbs= p;    In Section 3.4 (MPLS-TP OAM) - mainly to explain that control p= lane is neither mandatory nor precluded in  MPLS-TP

d.      The term= “management plane” (with or without dash) appears only in Secti= on 1.2. In addition to the already mentioned ability to operate on-demand OAM tools, ability of these tools to raise alarms is mentioned <= /span>

     &n= bsp;            =             &nbs= p;            &n= bsp;            =       i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">This is definitely a step forward vs. the -05 version<= /span>

     &n= bsp;            =             &nbs= p;            &n= bsp;            =     ii.  = ;    = While RFC 6427 is now referenced in the draft (it was missing in= the previous version), the draft does not mention alarm suppression function. And while= it mentions AIS in MPLS-TP it only points to RFC 6327 for the explanation o= f the consequent actions of AIS.

     &n= bsp;            =             &nbs= p;            &n= bsp;            =   iii. &nbs= p;    For the sake of completeness, ability to clear alarms should al= so be mentioned IMO – but this is a very minor issue.

e.      The term= “test plane” appears in Section 4.5, but, as already mentioned= above,  specific test plane protocols are not discussed in the draft

2.     =   OAM i= n connectionless vs. connection-oriented networks

a.     =   The firs= t sentence in Section 1 states that “OAM is a general term that refe= rs to a toolset for detecting, isolating and reporting connection failures and pe= rformance degradation”. To me this suggests that OA= M is applicable only to connection-oriented networks (if you do not have connections, connection problems do not exist by def= inition).

b.      The term= “connection” appears in some other places in the draft, e.g., t= he connectivity check “is used to verify the liveness of a connection&= #8221; (Section 1.1).

c.     =   At = the same time, the draft discusses:

     &n= bsp;            =             &nbs= p;            &n= bsp;            =       i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">ICMP Ping (Section 3.1.1) operating in connectionless IP networks=

     &n= bsp;            =             &nbs= p;            &n= bsp;            =     ii.  = ;    = LSP-Ping in MPLS networks (Section 3.3). Since LSP-Ping as defin= ed in RFC 4379 is applicable to LSPs set up by LDP, I’d say that it operates in conn= ectionless environment

     &n= bsp;            =             &nbs= p;            &n= bsp;            =   iii. &nbs= p;    Ethernet OAM (1.5) operating in connectionless Ethernet network= s etc.

3.     =   The M= ess of MEs, MPs, MEPs and MIPs.

a.     =   Please c= onsider the following text fragments

     &n= bsp;            =             &nbs= p;            &n= bsp;            =       i.  =     <= span style=3D"font-family:"Calibri","sans-serif"">(In se= ction 2.2.2) OAM tools are designed to monitor and manage a Maintenance Enti= ty (ME).  An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a t= ransport path to which maintenance and monitoring operations apply.

     &n= bsp;            =             &nbs= p;            &n= bsp;            =     ii.  = ;    = (ibid.) Various terms are used to refer to an ME. For example, B= FD does not explicitly use a term that is equivalent to ME, but rather uses the term "session= ", referring to the relationship between two nodes using a BFD protocol= . The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP&= quot; in this context

     &n= bsp;            =             &nbs= p;            &n= bsp;            =   iii. &nbs= p;    (In Section 2.2.3) A Maintenance Point (MP) is a functional entity that is defined at a node= in the network, and either initiates or reacts to OAM messages. A Maintenan= ce End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermedia= te Point (MIP) is an intermediate point between two MEPs, that does not gene= rally initiate OAM frames (one exception to this is the use of AIS notificat= ions), but is able to respond to OAM frames that are destined to it.=

     &n= bsp;            =             &nbs= p;            &n= bsp;            =    iv.  = ;    = (Ibid= .) MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the= MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs).&nb= sp; This placement is important for localization of a connection failure.

b.      The last= of these statements seems to hint that with just two  mutually exclusi= ve types of MPs (UP/DOWN) it is possible to associated an MP with one of 3 possible placements (ingress, egress or forwarding functio= n).

c.     =   IMHO and= FWIW combining these statements can result in some unexpected (and undesira= ble) conclusions. E.g.,

     &n= bsp;            =             &nbs= p;            &n= bsp;            =       i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif"">Premises:

·         An MPLS= LSP is an ME in the case of LSP Ping

·         An ME de= fines a point-to-point relationship between two points on a transport path

·         These po= ints are defined at nodes

Conclusio= n: An MPLS LSP can cross only two nodes (because in IP/MPLS LSP Ping can= be initiated from any node participating in an LSP).

     &n= bsp;            =             &nbs= p;            &n= bsp;            =     ii.  = ;    = Premises:

·     BFD as d= efined in RFC 5880 is an OAM tool (it is listed as such in Table 1 in sectio= n 1.4) 

·     OAM tool= s are designed to monitor MEs

·     In the c= ase of a BFD  a BFD session (there are no other sessions in RFC 5880) i= s an ME

Conclusi= on: BFD is designed to monitor its own sessions (and hence is completely usel= ess).

&nb= sp;

 

A Side Note: The majority of problematic definitions in the draft are based on RFC 637= 1. IMHO and FWIW this results in 3 types of problems:

·         The auth= ors misinterpret RFC 6371. E.g., it only speaks about UP and DOWN MEPs, not= about UP and DOWN MPs , and it does not discuss ingress/egress/forwarding engine placement

·         The auth= ors have tried to extend the definitions from 6371 to other IETF technologie= s (IP and IP/MPLS). E.g., in MPLS-TP sending LSP-Ping packets from an intermediate node of a co-routed bi-directional LSP towards= one of its endpoints is possible, but the responses would not be received b= y the initiator...

·         Some of= the original definitions in 6371 are problematic (among other things, this= applies to UP and DOWN MEPs).

 

Minor Issues:

1.     =   Limited= coverage of performance measurement.

a.     =   The draf= t mentions packet loss, delay/delay variation and the (undisclosed) throughp= ut measurement.

b.      At the s= ame time it ignores such issues as duplication and reordering (and does not= mention RFC 4347 and RFC 5560 respectively)

c.     =   Connecti= vity measurement (RFC 2678) is referenced and mentioned in the text. But it= is not mapped to any of the main performance measurements functions

2.     =   Proposed= classification of the IETF documents (into tools, profiles, infrastructure= and miscellaneous) could be useful but is not consistently applied. E.g.,

a.     =   I do not= think that RFC 792 defines an OAM Tool

b.      I have s= erious doubts that RFC 4556 and RFC 5337 (defining the control plane for the= IPPM mechanisms) are “OAM Tools” while all the referenced specific measurement protocols are “Miscellaneous” etc.

 

Unfortunately could not provide any us= eful information regarding nits, typos etc. My review is incomplete in this= regard, and I owe apologies to Routing ADs, my colleagues in the Routing Directorate and the authors.

 

Regards,

     Sasha

 

 

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_-- --_004_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 24 Jan 2013 07:15:15 GMT"; modification-date="Thu, 24 Jan 2013 07:15:15 GMT" From: Alexander Vainshtein To: "'rtg-ads@tools.ietf.org'" CC: "'rtg-dir@ietf.org'" , "'drafts-ietf-opsawg-oam-overview.all@tools.ietf.org'" Subject: RTG-DIR Review: draft-ietf-opsawg-oam-overview-05.txt Thread-Topic: RTG-DIR Review: draft-ietf-opsawg-oam-overview-05.txt Thread-Index: AcxUedbkWiz51hHjSGiJW/+W82QZLA== Date: Sat, 6 Aug 2011 20:45:56 +0000 Message-ID: <02D7222D58419F409B1BE84E6095C260C03C4F6726@ILPTMAIL02.ecitele.com> Content-Language: he-IL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_02D7222D58419F409B1BE84E6095C260C03C4F6726ILPTMAIL02eci_" MIME-Version: 1.0 --_000_02D7222D58419F409B1BE84E6095C260C03C4F6726ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-opsawg-oam-overview-05.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 06-Aug-11 IETF LC End Date: 20-Jul-11 (?) Intended status: Informational Summary: I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. To some extent these concerns reflect my personal and potentially biased po= sition with regard to OAM. So I would like the Routing ADs to take them wi= th a grain of salt. In the process of review I've maintained private discussions with one of th= e draft authors (Nurit), and we've advanced in resolving some of the issues= . Unfortunately, due to conflicting schedules, this process has not been co= mpleted. Comments: My concerns with the draft start from the question about its target audienc= e. I have assumes (possibly, incorrectly), that the purpose of this draft i= s to provide guidance to OAM in IP, IP/MPLS and MPLS-TP networks to various= "beginners" groups (including people who have experience with OAM in SONET= /SDH, ATM and OTN networks), while "IETF gurus" would hardly need it anywa= y (IETF Area Directors, WG chairs and reviewers for various Directorates a= re excludedJ). Such guidance would be really useful because OAM-related iss= ues are at the core of multiple discussions raging on some IETF mailing lis= ts for the last several years. IMHO and FWIW, in order to provide guidance to what I expected to be the t= arget audience, the draft should: * Include a "Historical Background" session. A single sentence in S= ection 1 ("OAM was originally used in the world of telephony, and has been = adopted in packet based networks") is hardly sufficient IMHO * Present a clear view of OAM functionality and its relationship to v= arious "planes" of networking (data plane, control plane, management plane)= . In particular, the importance of fate-sharing of OAM and user traffic flo= ws in packet networks should be explained * Explicitly map the notions, terms and methods that have been adopt= ed from technologies owned by ITU-T and/or IEEE to IETF-owned technologie= s. When such a mapping is not possible, it should be explicitly stated * Expose, rather than avoid, known points of contention regarding va= rious OAM-related issues, preferably without explicitly taking sides. The draft did not meet my expectations in this regard. This may be because = my expectations have been exaggerated or even completely unrealistic, or = because the authors had in mind a different target audience and a different= purpose. At the very least, explicitly specifying these (the purpose and t= he target audience) in the Introduction section would be helpful. Instead the draft looks to me like a long (but incomplete) annotated list o= f references to IETF and non-IETF protocols and mechanisms that deal with c= ertain aspects of OAM in IP, IP/MPLS, MPLS-TP and Ethernet networks. The g= uiding principle behind selection of the referenced protocols and mechanism= s is not defined in the draft and from my point of view, is questionable, e= .g.: * Why is the defunct ITU-T Y.1711 considered in detail, while ITU-T I= .610 (which has been implemented by virtually all the vendors of ATM equipm= ent) is not even mentioned? * Why is IEEE 802.3ah included, while E-LMI (defined by MEF) is not? = And what are their analogs (if any) in IETF-owned technologies? * Why MPLS-TP client failure indications document(draft-ietf-mpls-tp= -csf-01.txt) is included but MPLS-TP fault management OAM one (draft-iet= f-mpls-tp-fault-05) is omitted? >From my point of view the draft is not easily readable - not in the least = because some terms and concepts that have been "borrowed" from the referen= ced documents have different meaning in these documents. E.g.,. in Section= 4.1 the draft states that ICMP ping provides "connectivity verification fo= r Internet Protocol". However, in Section 3.2.4 the draft says that "connec= tivity verification function allows an MP to check whether it is connected = to a peer MP or not". Since MPs are not mentioned with regard to ICMP, it i= s not clear whether "connectivity verification" means the same thing in the= se two cases. The explanations that accompany some of these references sometimes focus on= unimportant details while in other cases are simply missing. To give a so= me examples: * In Sections 4.5.2 and 4.5.3 the authors remind the reader that OW= AMP uses TCP port 861 and TWAMP - port 862. At the same time, IPPM test pla= ne protocols are only mentioned by referencing the appropriate RFCs * In Section 3.2.3 the draft defines the term "Maintenance Entity" = (ME). (Inaccuracies of this definition will be discussed below). At the sam= e time an equally important (IMHO) term "Maintenance Entity Group" (MEG), a= .k.a. "Maintenance Association (MA), is only defined by reference * In Section 4.5.2 the draft mentions security aspects of IPPM prot= ocols. However, these aspects are not even mentioned in Section 4.2. discus= sing BFD. I would suggest a careful clean-up of explanatory texts in the draft with s= pecial attention on homogeneity of detail. Major Issues: OAM and its relationship to network planes The following examples illustrate the problem IMO: 1. The concepts of data plane, control plane and management plane are = not explored in the draft: a. The term "data-plane" (with some modifications) is only found in Se= ction 4.3 when discussing LSP-Ping ("data plane" is also found in the title= of RFC 4379) b. The terms "control-plane" ( "control plane") are a bit more popular= . They can be found: i. In Se= ction 4.3 (LSP-Ping again) ii. In Sec= tion 4.5 (IPPM protocols) where "control plane" and "test plane" protocols = are mentioned iii. In the = sections dealing with MPLS-TP - but mainly to explain that control plane is= neither mandatory nor precluded in MPLS-TP c. The term "management plane" (with or without dash) simply does not= appear in the draft d. The term "test plane" appears in Section 4.5, but, as already menti= oned above, specific test plane protocols are not discussed in the draft 2. I have failed to understand relationship between OAM functionality and = network management as presented in the draft. To illustrate this point, ple= ase consider the following text fragments (conflicting statements are indic= ated by italics, and my comments are closed in double angle brackets <<...>= >): a. (Section 1) Other aspects associated with the OAM acronym, such as= management, are outside the scope of this document <> b. (Section 4.6.4) The FDI function is used by an LSR to report a de= fect to affected client layers, allowing them to suppress alarms about thi= s defect << Are not alarms part of management? >> c. 3. (Section 4.7.2) When the ETH-CC function detects a defect,= it reports one of the following defect conditions: i. Loss = of continuity (LOC): Occurs when at least when no CCM messages have been re= ceived from a peer MEP during a period of 3.5 times the configured transmis= sion period ii. ... (s= nipped)... iii. Unexpec= ted period: Occurs when the transmission period field in the CCM does not m= atch the expected transmission period value << Since transmission period f= ield in ETH-CC is defined by management, this defect reports a management p= roblem>> d. (Section 4.7.6) The Alarm Indication Signal indicates that a MEG = should suppress alarms about a defect condition at a lower MEG level, i.e.,= since a defect has occurred in a lower hierarchy in the network, it should= not be reported by the current node <> e. (Section 4.7.9) The Y.1731 standard defines the frame format for Au= tomatic Protection Switching frames. The protection switching operations = are defined in other ITU-T standards. <> 3. OAM in connectionless vs. connection-oriented networks: a. (2a) above suggests that OAM is applicable only to connection-orien= ted networks (if you do not have connections, connection problems do not ex= ist by definition) b. At the same time, the draft discusses ICMP Ping (Section 4.1) oper= ating in connectionless IP networks, and Ethernet OAM (Sections 4.7 and 4.= 8) operating in connectionless Ethernet networks. My suggestion (FWIW) to the authors would be to define the scope of OAM exp= licitly and clearly - and then remove the sections dealing with protocols a= nd mechanisms that happen to be out of this scope. In particular, explainin= g the relationship of each specific defect to a specific networking planes = would be most helpful. The Mess of MEs, MPs, MEPs and MIPs Caveat: It may well be that the problem is not with the draft I am reviewin= g but with the concept itself (or at least with the attempts to extend it t= o IP. IP/MPLS and MPLS-TP networks). I may be also biased when it comes to= this concept. However, if the problem is with the concept, I would expect = a useful overview to expose it to the reader and not to hide it. Going back to the draft, consider the following statements: 1. (Section 3.2.2) A Maintenance Entity (ME) is a point-to-point rel= ationship between two Maintenance Points (MP). The connectivity between the= se Maintenance Points is managed and monitored by the OAM protocol. A pair= of MPs engaged in an ME are connected by a Communication Link 2. (Section 3.2.3) A Maintenance Point (MP) is a functional entity tha= t is defined at a node in the network, and either initiates or reacts to OA= M messages. A Maintenance End Point (MEP) is one of the end points of an ME= , and can initiate OAM messages and respond to them. A Maintenance Interme= diate Point (MIP) is an intermediate point between two MEPs, that does not = initiate OAM frames, but is able to respond to OAM frames that are destine= d to it, and to forward others. 3. (Section 3.2.3) The 802.1ag defines a finer distinction between Up= MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM= protocol... 4. (Section 4.1) ICMP provides a connectivity verification function= for the Internet Protocol... ICMP is also used in Traceroute for path disc= overy. I suspect that, based on these fragments (all within two pages in the draf= t), an OAM beginner would not be able to answer the following questions: 1. Can a communication link exist without any MPs on it (the chicken a= nd egg problemJ) 2. Suppose that I have defined a P2P bidirectional communication link = with two MEPs forming an ME. What would happen to this ME if I add a MIP = between the two MEPs? 3. What is the relationship (if any) between MEPs and interfaces? Or i= s it just something specific to Ethernet bridges? 4. Does a MIP really forward OAM frames that are not destined to it? 5. Operation of ICMP Ping does not require creation of MPs. How does i= t provide a connectivity verification function for IP? As a minimum, I would suggest to remove conflicting definitions, to fix typ= os (e.g., the definition of ME would be less problematic if it referred to = a pair of MEPs and not to a pair of MPs) and inaccurate statements (in IP, = IP/MPLS and MPLS-TP MIPs do NOT forward OAM packets that are not destined t= o them - but they do that in Ethernet OAM). Minor Issues: Caveat: Each of the issues listed below, if you look at it separately, coul= d be considered as minor. But there seem to be too many of them for my tast= e. Connectivity Check vs. Continuity Check The draft mainly uses the term "Continuity Check". However, from time to ti= me I have seen the term "Connectivity Check" as well, e.g.: 1. (Section 4.12) A key element in some of the OAM standards that are = analyzed in this document is the continuity check. It is thus interesting t= o present a more detailed comparison of the connectivity check mechanisms d= efined in OAM standards. 2. (Section 4.3) LSP Ping extends the basic ICMP Ping operation (of d= ata-plane connectivity and continuity check)... The second fragment seems to suggest that connectivity check and continuity= check are two different functions. I would suggest to clean up the text using the term "continuity check" cons= istently. Caveat: I have found a similar inconsistency in IEEE 802.1ag (but not in IT= U-T Y.1731). Continuity Check vs. Connectivity Verification In Section 3.2.4. the draft refers to RFC 5860 as the ultimate source of i= nformation about the difference between Continuity Check and Connectivity V= erification. Looking up RFC 5860 (Section 2.2.3), I've learned that connect= ivity verification is a function that allows an End Point to find out wheth= er it is connected to a specific End Point(s) by means of an expected PW, L= SP or Section. At the same time, the draft says (in the same Section 3.2.4)= that "A connectivity verification function allows an MP to check whether i= t is connected to a peer MP or not". The omitted words from RFC 5860 "by = means of..." make such a definition meaningless IMO; and it is not clear to= me if End Points (of Section, LSP or PW) which, presumably, are MEPs, can = be extended to be MEPs or MIPs (the draft uses the term MPs). It is also not clear to me whether the draft considers LSP Ping (see Sectio= n 4.3.) functionality "to verify data-plane vs. control-plane consistency f= or a Forwarding Equivalence Class (FEC)" as related to Connectivity Verif= ication. This is especially strange since the draft also states (in the sam= e section) that "LSP Ping extends the basic ICMP Ping operation" while Se= ction 4.1 states that "ICMP provides a connectivity verification function f= or the Internet Protocol". Yet another problematic point is the statement (in Section 4.2.3) that "BFD= Echo provides a connectivity verification function", especially since draf= t-ietf-mpls-tp-cc-cv-rdi-05 in Section 3.5 expands format of the BFD contro= l packets in order to provide CV function, while BFD Echo is not even menti= oned in this document. Last but not least, the draft does not explain whether there is any correla= tion between the defects detected by the continuity check and those detecte= d by connectivity verification (Section 4.10.3.1 looks a logical place for= this). Inaccurate Representation of IEEE 802.1ag In Section 3.2.3 of the draft I have found the following text: "The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP= is a bridge interface, that is monitored by an OAM protocol either in the = direction facing the network, or in the direction facing the bridge. A D= own MP is an MP that receives OAM packets from, and transmits them to th= e direction of the network. An Up MP receives OAM packets from, and transmi= ts them to the direction of the bridging entity". In fact IEEE 802.1ag states (see Section 22.1.3 of that document ) that: "A= ll Up MEPs belonging to MAs that are attached to specific VIDs are placed b= etween the Frame filtering entity (8.6.3) and the Port filtering entities (= 8.6.1, 8.6.2, and 8.6.4). Separately for each VLAN, there can be from zero = to eight Up MEPs, ordered by increasing MD Level, from Frame filtering towa= rds Port filtering". To me that means that in 802.1ag MEPs are NOT bridge interfaces (since ther= e can be are multiple MEPs per VLAN and multiple VLANs per bridge interface= ). Defects, Faults and Failures In Section 3.2.5 the draft discusses the terms Defect, Fault and Failure. H= owever, these terms seem to apply to the "communication link" which presuma= bly is a data plane entity. At the same time, "Unexpected Period" and "Unexpected MEP" are mentioned as= defects detected by ETH-CC in Section 4.7.2 even if, to the best of my und= erstanding, these conditions are side effects of mis-configuration i.e., a = management plane problem. VCCV: An OAM Mechanism or a Control Channel? In Section 4.4. the draft states that VCCV "provides end-to-end fault detec= tion and diagnostics for PWs". This seems to point that VCCV is an OAM mech= anism/protocol. However, later in the same section is states that "The VCCV switching funct= ion provides a control channel associated with each PW... and allows sendin= g OAM packets in-band with PW data". And on the next line it explains that= "VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping= , and BFD" (which are all mentioned as OAM mechanisms providing continuity = check and/or connectivity verification in the draft). So it remains complet= ely unclear whether VCCV is an OAM mechanism or just a channel for separati= ng user data from OAM flows. MEs, MEGs and MEG levels The draft explicitly defines a Maintenance Entity (ME) in Section 3.2.2, bu= r defers to MPLS-TP OAM Framework for the definition of the Maintenance Ent= ity Group (MEG). The text defining ME in the draft differs from that in the= MPLS-T_ OAM Framework document (see http://datatracker.ietf.org/doc/draft= -ietf-mpls-tp-oam-framework/?include_text=3D1, Section 2.2). At the same ti= me, it resembles the definition of ME in Section 3.1 of this document. MEG level is mentioned a couple of times in the draft, but the only explana= tion given (in Section 4.7.2) is "The MEG level is a 3-bit number that defi= nes the level of hierarchy of the MEG"; and this seems to be the only text = in the draft that deals with MEG hierarchy. Differences between Approaches to Packet/Frame Loss Measurement I have not found any mention of the fundamental difference between two appr= oaches to measuring packet loss - that of the IPPM WG (based on counting sy= nthetic packets) and that of Y.1731 (based on counting the user packets), e= ven if both are mentioned in the draft. Nits: Unidirectional/Bidirectional OAM vs. One-way/Two-way OAM Both pairs of terms are used in the draft (One-way/Two-way - in Section 4.5= .1, Unidirectional - in section 4.12, /Bidirectional - in Section 4.2.2). = Neither the terms nor their equivalence are explained in the draft. A Typo: In section 4.10.3.1: "Continuity Check and Connectivity Verification (CC-V) are OAM operations g= enerally used in tandem, and compliment each other." - probably should be "= complement"? An Pleonasm: In Section 4.8.1: "There are a few differences between the two standards in terms of terminol= ogy" - I would suggest "There are a few differences in terminology between = the two standards". Regards, Sasha --_000_02D7222D58419F409B1BE84E6095C260C03C4F6726ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been selected as the Routing = Directorate reviewer for this draft. The Routing Directorate seeks to revie= w all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide as= sistance to the Routing ADs. For more information about the Routing Directo= rate, please see http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are primaril= y for the use of the Routing ADs, it would be helpful if you could consider= them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating = the draft.

 

Document: draft-ietf-opsawg-oam-over= view-05.txt

Reviewer: Alexander (“Sasha= 221;) Vainshtein   

Review date: 06-Aug-11

IETF LC End Date: 20-Jul-11 (?)

Intended status: Informational

 

Summary:<= /span>

 

I have significant concerns about th= is document and recommend that the Routing ADs discuss these issues further= with the authors.

 

To some extent these concerns reflec= t my personal and potentially biased position with regard to OAM.  So = I would like the Routing ADs to take them with a grain of salt.<= /span>

 

In the process of review I’ve = maintained private discussions with one of the draft authors (Nurit), and w= e’ve advanced in resolving some of the issues. Unfortunately, due to conflicting schedules, this process has not been completed.<= o:p>

 

Comments:=

 

My concerns with the draft start fro= m the question about its target audience. I have assumes (possibly, incorre= ctly), that the purpose of this draft is to provide guidance to OAM in IP, IP/MPLS and MPLS-TP networks to various “beginnersR= 21; groups (including people who have experience with OAM in SONET/SDH, ATM= and OTN networks), while “IETF gurus” would hardly need  = it anyway  (IETF Area Directors, WG chairs and reviewers for various Directorates are excludedJ). Such guidance would be really = useful because OAM-related issues are at the core of multiple discussions raging on some IETF mailing lists for the last several years. =

 

IMHO and FWIW,  in order to pro= vide guidance to what I expected to be the target audience, the draft shoul= d:

  • Include  a “Historical Backgrou= nd”  session. A single sentence in Section 1 (“OAM was ori= ginally used in the world of telephony, and has been adopted in packet base= d networks”) is hardly sufficient IMHO
  • Present a clear view of OAM functionality = and its relationship to various “planes” of networking (data pl= ane, control plane, management plane). In particular, the importance of fat= e-sharing of OAM and user traffic flows in packet networks should be explained
  • Explicitly map the notions,  terms an= d methods that have been adopted  from technologies owned by ITU-T and= /or IEEE to  IETF-owned technologies.  When such a mapping is not= possible, it should be explicitly stated
  • Expose, rather than avoid,  known poi= nts of contention regarding various OAM-related issues, preferably without = explicitly taking sides.

The draft did not meet my expectatio= ns in this regard. This may be because my  expectations have been &nbs= p;exaggerated or even completely unrealistic, or because the authors had in mind a different target audience and a different purpose. At the ve= ry least, explicitly specifying these (the purpose and the target audience)= in the Introduction section would be helpful.

 

Instead the draft looks to me like a= long (but incomplete) annotated list of references to IETF and non-IETF pr= otocols and mechanisms that deal with certain aspects of OAM in IP, IP/MPLS, MPLS-TP and Ethernet networks.  The guiding princ= iple behind selection of the referenced protocols and mechanisms is not def= ined in the draft and from my point of view, is questionable, e.g.:

 

·       Why is the defunct ITU-T Y.1711 considered in detail, while I= TU-T I.610 (which has been implemented by virtually all the vendors of ATM equipment) is not even men= tioned?

·       Why is IEEE 802.3ah included, while E-LMI (defined by MEF) is= not? And what are their analogs (if any) in IETF-owned technologies?

·       Why MPLS-TP client failure indications  document(draft-i= etf-mpls-tp-csf-01.txt) is   included but MPLS-TP fault management OAM one  (draft-ietf-mpls-tp-fault-05) i= s omitted?

&= nbsp;

From my point of view the draft  is not easily readable - no= t in the least because some terms and concepts that have been “borrow= ed” from  the referenced documents have different meaning in these documents.  E.g.,. in Section 4.1 the draft states t= hat ICMP ping provides “connectivity verification for Internet Protoc= ol”. However, in Section 3.2.4 the draft says that “connectivit= y verification function allows an MP to check whether it is connected to a peer MP or not”. Since MPs are not mentioned with = regard to ICMP, it is not clear whether “connectivity verification= 221; means the same thing in these two cases.

 

The explanations that accompany some= of these references sometimes focus on unimportant details  while in = other cases are simply missing. To give a some examples:<= /p>

 

·         In Sec= tions 4.5.2 and 4.5.3 the authors remind the reader that OWAMP uses TCP por= t 861 and TWAMP – port 862. At the same time, IPPM test plane protocols are only mentioned by referencing the appropriate RFCs

·         In Sec= tion 3.2.3 the draft defines the term “Maintenance Entity” (ME)= . (Inaccuracies of this definition will be discussed below). At the same time an equally important (IMHO) term “Maintenance Entity Group= ” (MEG), a.k.a. “Maintenance Association (MA), is only defined = by reference

·         In Sec= tion 4.5.2 the draft mentions security aspects of IPPM protocols. However, = these aspects are not even mentioned in Section 4.2. discussing BFD.

 

I would suggest a careful clean-up o= f explanatory texts in the draft with special attention on homogeneity of d= etail.

 

Major Issues:

 

OAM and its relationship  to= network planes

 

The following examples illustrate th= e problem IMO:

 

1.    &nb= sp; The co= ncepts of data plane, control plane and management plane are not explored i= n the draft: 

a.    &nb= sp; The te= rm “data-plane” (with some modifications) is only found in Sect= ion 4.3 when discussing LSP-Ping (“data plane” is also found in= the title of RFC 4379)

b.    &nb= sp; The te= rms “control-plane” ( “control plane”) are a bit mo= re popular. They can be found:

     = ;            &n= bsp;            = ;            &n= bsp;            = ;       i.  = ;    In Section 4.3 (LSP-Ping again)

     = ;            &n= bsp;            = ;            &n= bsp;            = ;     ii. &nbs= p;    In Section 4.5 (IPPM protocols) where “control plane&#= 8221; and “test plane” protocols are mentioned

     = ;            &n= bsp;            = ;            &n= bsp;            = ;   iii. &nb= sp;    In the sections dealing with MPLS-TP – but mainly to = explain that control plane is neither mandatory nor precluded in  MPLS-TP

c.    &nb= sp;  The te= rm “management plane” (with or without dash) simply does not ap= pear in the draft

d.    &nb= sp; The te= rm “test plane” appears in Section 4.5, but, as already mention= ed above,  specific test plane protocols are not discussed in the draf= t

2.  I have failed= to understand relationship between OAM functionality and network managemen= t as presented in the draft. To illustrate this point, please consider the following text fragments (conflicting statements are indicate= d by italics, and my comments are closed in double angle brackets <= ;<…>>):

a.    &nb= sp;  = (Section 1) Other aspects associated with the OAM acronym, such as management, are o= utside the scope of this  document  <<Management is out= of scope>>

b.    &nb= sp; (Secti= on 4.6.4)   The FDI function is used by an LSR to report a defect= to affected client layers, allowing them to suppress alarms  about this defect << Are not alarms part= of management? >>

c.    &nb= sp;  3.&nbs= p;     (Section 4.7.2) When the ETH-CC function detects= a defect, it reports one of the following defect conditions:

     = ;            &n= bsp;            = ;            &n= bsp;            = ;       i.  = ;    Loss of continuity (LOC): Occurs when at least when no CCM me= ssages have been received from a peer MEP during a period of 3.5 times the configured transmission p= eriod 

     = ;            &n= bsp;            = ;            &n= bsp;            = ;     ii. &nbs= p;    … (snipped)…

     = ;            &n= bsp;            = ;            &n= bsp;            = ;   iii. &nb= sp;    Unexpected period: Occurs when the transmission period field in the CCM does not match the expected transmi= ssion period value  << Since transmission period field in ET= H-CC is defined by management, this defect reports a management problem>= >

d.    &nb= sp; (Secti= on 4.7.6)   The Alarm Indication Signal indicates that a MEG should suppress alarms about a defect condition at a lower MEG l= evel, i.e., since a defect has occurred in a lower hierarchy in the network= , it should   not be reported by the current node  <<A= larms’ suppression again…>>

e.    (Secti= on 4.7.9)   The Y.1731 standard defines the frame format for Automatic Protection   Switching frames. The protection switching operations are defined in  other ITU-T st= andards. <<Is APS part of OAM?>>

3.   OAM in = connectionless vs. connection-oriented networks:

a.    &nb= sp; (2a) a= bove suggests that OAM is applicable only to connection-oriented networks (= if you do not have connections, connection problems do not exist by definition)

b.    &nb= sp; At&nbs= p; the same time, the draft discusses ICMP Ping (Section 4.1) operating in = connectionless IP networks, and Ethernet OAM (Sections  4.7 and 4.8) operating in connectionless Ethernet networks.

 

My suggestion (FWIW) to the authors = would be to define the scope of OAM explicitly and clearly - and then remov= e the sections dealing with protocols and mechanisms that happen to be out of this scope. In particular, explaining the relationship= of each specific defect to a specific networking planes would be most help= ful.

 

The Mess  of  MEs, MPs,= MEPs and MIPs

 

Caveat: I= t may well be that the problem is not with the draft I am reviewing but wit= h the concept itself (or at least with the attempts to extend it to IP. IP/MPLS = and MPLS-TP networks).  I may be also biased when it comes to this con= cept. However, if the problem is with the concept, I would expect a useful = overview to expose it to the reader and not to hide it.

 

Going back to the draft, consider th= e following statements:

 

1.    &nb= sp; (Secti= on 3.2.2)   A Maintenance Entity (ME) is a point-to-point relatio= nship between two Maintenance Points (MP). The connectivity between these Maintenance Points is managed and monitored by the OAM protocol.&nbs= p; A pair of MPs engaged in an ME are connected by a Communication Link

2.    &nb= sp; (Secti= on 3.2.3) A Maintenance Point (MP) is a functional entity that is defined a= t a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of= an ME, and  can initiate OAM messages and respond to them. A Maintena= nce Intermediate Point (MIP) is an intermediate point between two MEPs, tha= t does not initiate OAM frames, but is able to respond to OAM  frames that are destined to it, and to forwar= d others.

3.    &nb= sp; (Secti= on 3.2.3)  The 802.1ag defines a finer distinction between Up MPs and = Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol…

4.    &nb= sp; &nbs= p;(Section 4.1)   ICMP provides a connectivit= y verification function for the Internet Protocol… ICMP is also used in Traceroute for path = discovery.

 

I suspect that, based on  these= fragments (all within two pages in the draft), an OAM beginner would not b= e able to answer the following questions:

1.    &nb= sp; Can a = communication link exist without any MPs on it (the chicken and egg problem= J)

2.    &nb= sp; Suppos= e that I have defined a P2P bidirectional communication link with two MEPs =  forming an ME.  What would happen to this ME if I add a MIP between the two MEPs?

3.    &nb= sp; What i= s the relationship (if any) between MEPs and interfaces? Or is it just some= thing specific to Ethernet bridges?

4.    &nb= sp; Does a= MIP really forward OAM frames that are not destined to it? 

5.    &nb= sp; Operat= ion of ICMP Ping does not require creation of MPs. How does it provide a co= nnectivity verification function for IP?

 

As a minimum, I would suggest to rem= ove conflicting definitions, to fix typos (e.g., the definition of ME would= be less problematic if it referred to a pair of MEPs and not to a pair of MPs) and inaccurate statements (in IP, IP/MPLS and MPLS-T= P MIPs do NOT forward OAM packets that are not destined to them – but= they do that in Ethernet OAM).

 

Minor Issues:

 

Caveat: E= ach of the issues listed below, if you look at it separately, could be cons= idered as minor. But there seem to be too many of them for my taste.<= /o:p>

 

Connectivity Check vs. Continuity= Check

 

The draft mainly uses the term ̶= 0;Continuity Check”. However, from time to time I have seen the term = “Connectivity Check” as well, e.g.:

= 1.      (Section 4.12) A key element in some of the OAM standar= ds that are analyzed in this document is the continuity check. It is thus interesting to present a more detailed = comparison of the connectivity check mechanisms defined in OAM standards. =

= 2.      (Section 4.3)  LSP Ping extends the basic ICMP Pin= g operation (of data-plane connectivity and continuity check)…

 

The second fragment seems to suggest= that connectivity check and continuity check are two different functions.<= o:p>

 

I would suggest to clean up the text= using the term “continuity check” consistently.

 

Caveat: I= have found a similar inconsistency in IEEE 802.1ag (but not in ITU-T Y.173= 1).

 

Continuity Check vs. Connectivity= Verification

 

In Section 3.2.4. the draft refers t= o  RFC 5860 as the ultimate source of information about the difference= between Continuity Check and Connectivity Verification. Looking up RFC 5860 (Section 2.2.3), I’ve learned that connectivity verifica= tion is a function that allows an End Point to find out whether it is conne= cted to a specific End Point(s) by means of an expected PW, LSP or Section. At the same time, the dr= aft says (in the same Section 3.2.4) that “A connectivity verificatio= n function allows an MP to check whether it is connected to a peer MP or no= t”.  The omitted  words from RFC 5860 “by means of…” make such a definition meaningless IMO; a= nd it is not clear to me if End Points (of Section, LSP or PW) which, presu= mably, are MEPs, can be extended to be MEPs or MIPs (the draft uses the ter= m MPs).

 

It is also not clear to me whether t= he draft considers LSP Ping (see Section 4.3.) functionality “to veri= fy data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC)”  as  related to Connectivity Verification. Th= is is especially strange since the draft also states (in the same section) =  that “LSP Ping extends the basic ICMP Ping operation”&nbs= p; while Section 4.1 states that “ICMP provides a connectivity verifi= cation function for the Internet   Protocol”.  

 

Yet another problematic point is the= statement (in Section 4.2.3) that “BFD Echo provides a connectivity = verification function”, especially since draft-ietf-mpls-tp-cc-cv-rdi= -05 in Section 3.5 expands format of the BFD control packets in order to provi= de CV function, while BFD Echo is not even mentioned in this document.=

 

Last but not least, the draft does n= ot explain whether there is any correlation between the defects detected by= the continuity check and those detected by connectivity verification (Section 4.10.3.1 looks  a logical place for this).=

 

Inaccurate Representation of IEEE= 802.1ag

 

In Section 3.2.3 of the draft I have= found the following text:

 

“The 802.1ag defines a fine= r distinction between Up MPs and Down MPs. An MP is a bridge interface, tha= t is monitored by an OAM protocol either in the direction facing the network, or in the direction    facing the bridge. A Do= wn MP is an MP that receives OAM packets from,    and transm= its them to the direction of the network. An Up MP receives OAM packets fro= m, and transmits them to the direction of the bridging entity”.

 

In fact IEEE 802.1ag states (see Sec= tion 22.1.3 of that document ) that: “All Up MEPs belonging to MAs= that are attached to specific VIDs are placed between the Frame filtering entity (8.6.3) and the Port filtering entities (8.6.1, 8.6.2, an= d 8.6.4). Separately for each VLAN, there can be from zero to eight Up MEPs= , ordered by increasing MD Level, from Frame filtering towards Port filteri= ng”.

 

To me that means that in 802.1ag MEP= s are NOT bridge interfaces (since there can be are multiple MEPs per VLAN = and multiple VLANs per bridge interface).

 

Defects, Faults and Failures

 

In Section 3.2.5 the draft discusses= the terms Defect, Fault and Failure. However, these terms seem to apply to= the “communication link” which presumably is a data plane entity.

 

At the same time, “Unexpected = Period” and “Unexpected MEP” are mentioned as defects det= ected by ETH-CC in Section 4.7.2 even if, to the best of my understanding, = these conditions are side effects of mis-configuration i.e., a management plane = problem.

 

VCCV: An OAM Mechanism or a Contr= ol Channel?

 

In Section 4.4. the draft states tha= t VCCV “provides end-to-end fault detection and diagnostics for PWs&#= 8221;. This seems to point that VCCV is an OAM mechanism/protocol.

 

However, later in the same section i= s states that “The VCCV switching function provides a control channel= associated with each PW… and allows sending OAM packets in-band with PW data”.  And on the next line it explains that “VC= CV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, an= d BFD” (which are all mentioned as OAM mechanisms providing continuit= y check and/or connectivity verification in the draft). So it remains completely unclear whether VCCV is an OAM mechanism or just = a channel for separating user data from OAM flows.

 

MEs, MEGs and MEG levels

 

The draft explicitly defines a Maint= enance Entity (ME) in Section 3.2.2, bur defers to MPLS-TP OAM Framework fo= r the definition of the Maintenance Entity Group (MEG). The text defining ME in the draft differs from that in the MPLS-T_ OAM Fra= mework document  (see http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-framework/?include_t= ext=3D1, Section 2.2). At the same time, it resembles the definition of= ME in Section 3.1 of this document.

 

MEG level is mentioned a couple of t= imes in the draft, but the only explanation given (in Section 4.7.2) is = 220;The MEG level is a 3-bit number that defines the level of hierarchy of the MEG”; and this seems to be the only text in the dra= ft that deals with MEG hierarchy.

 

Differences between Approaches to= Packet/Frame Loss Measurement

 

I have not found any mention of the = fundamental difference between two approaches to measuring packet loss R= 11; that of the IPPM WG (based on counting synthetic packets) and that of Y.1731 (based on counting the user packets), even if both are = mentioned in the draft.

 

Nits:

 

Unidirectional/Bidirectional OAM = vs. One-way/Two-way OAM

 

Both pairs of terms are used in the = draft (One-way/Two-way - in Section 4.5.1, Unidirectional – in sectio= n 4.12, /Bidirectional – in Section 4.2.2).  Neither  the t= erms nor their equivalence are explained in the draft.

 

A Typo:

 

In section 4.10.3.1:

 

“Continuity Check and Connecti= vity Verification (CC-V) are OAM operations generally used in tandem, and compliment each other.” – probably should be “comp= lement”?

 

An Pleonasm:

 

In Section 4.8.1:<= /p>

 

“There are a few differences b= etween the two standards in terms of terminology” – I would suggest “Th= ere are a few differences in terminology between the two standards”.<= /span>

 

Regards,

     Sasha

 

--_000_02D7222D58419F409B1BE84E6095C260C03C4F6726ILPTMAIL02eci_-- --_004_F9336571731ADE42A5397FC831CEAA020E438232ILPTWPVEXMB01ec_-- From adrian@olddog.co.uk Thu Jan 24 03:33:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3750321F84D1 for ; Thu, 24 Jan 2013 03:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21RPPk1Ee6Lp for ; Thu, 24 Jan 2013 03:33:17 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 474DB21F897A for ; Thu, 24 Jan 2013 03:33:16 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0OBXEmK032341; Thu, 24 Jan 2013 11:33:14 GMT Received: from 950129200 (089144192091.atnat0001.highway.a1.net [89.144.192.91]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0OBXAAC032328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jan 2013 11:33:12 GMT From: "Adrian Farrel" To: "'Alexander Vainshtein'" , References: In-Reply-To: Date: Thu, 24 Jan 2013 11:33:10 -0000 Message-ID: <007c01cdfa26$98275c30$c8761490$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CDFA26.98358D00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQEkLpLBH2iecF/qhFXFGgFgkGxZbUKB+A Content-Language: en-gb Cc: rtg-dir@ietf.org, draft-ietf-opsawg-oam-overview.all@tools.ietf.org Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:33:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CDFA26.98358D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resending to correct address. Thanks Sasha for the review. Authors: we asked Sasha to look at this document again (in addition to Carlos' review) because he had provided a review of a previous version of the document. Thanks, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 24 January 2013 07:15 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; 'drafts-ietf-opsawg-oam-overview.all@tools.ietf.org' Subject: RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 23-Jan-13 IETF LC End Date: Not known Intended status: Informational Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. To some extent these concerns reflect my personal and potentially biased position with regard to OAM. In addition, I'd like note that this is my second review of this draft. The previous one has been done in August 2011 and dealt with the -05 version of the draft (the review is attached). Following this review I've hold a series of email exchanges and off-line meetings with some of the authors in an attempt to resolve the issues I've raised; but this process has not ever been completed. My current review hence is mainly focused on resolution (or lack thereof) of the concerns I've raised in the previous review round. This can be also considered as a bias (of a kind). Hence I ask - again - the Routing ADs to take my comments with a grain of salt. Comments: The needs of the assumed target audience are not fully addressed in the draft: Just as in the previous reviewing cycle, I assume that the intended target audience of the draft consists of various "beginner" groups. The current version does not contain any indications that this assumption is wrong (actually I did not find anything special about target audience in the draft). Taking into account ongoing OAM-related activities at the IETF (e.g., draft-mmm-bfd-on-lags), a good overview document would be indeed most useful for these groups. Based on this assumption I've then suggested that in order to provide appropriate guidance to the target audience, the draft should: 1. Include a section on historical background of OAM - not addressed in the reviewed version of the draft. a. The single sentence "OAM was originally used in the world of telephony, and has been adopted in packet based networks" that has served as a somewhat short background section has disappeared in this version of the draft b. IMHO and FWIW absence of such a section makes it difficult for, say, a reader with the background in OAM in SONET/SDH and/or OTN networks to understand why OAM in packet networks is so different. 2. Present a clear view of OAM functionality and its relationship to various "planes" of networking - at best, partially addressed in Section 1.2. However, the new text seems potentially misleading to me, e.g.: a. The statement "often the on-demand tools may be activated by the management" seems to suggest that on-demand OAM tools can be also activated in some other way. If the intention has been activation of such tools via the control plane, clarification would be very much in place b. Connectivity Verification (CV) is mentioned as one of the "OAM building blocks" (in Section 1.1), and the draft explains that CV is used to verify that it is used "to verify that the OAM messages are received through the expected path". However, the draft does not explain that the expected path is defined either by the management or by the control plane, so that the entire CV function does not make much sense without this interaction. 3. Explain the importance of fate-sharing of OAM and user traffic flows in packet networks - at best, partially addressed by the current version of the draft: a. The term "fate-sharing" does not appear in the draft at all b. The draft mentions that in MPLS-TP "OAM packets and the user traffic are required to be congruent" (Section 3.4.1). However, this is not extended to OAM tools for other IETF-owned technologies (IP, IP/MPLS). A side note: I am not sure that "congruent flows" and "fate-sharing flows" mean exactly the same thing. E.g., in IP/MPLS networks LSPs created by LDP are supposed to be congruent with IP flows, but they are not fate-sharing. 4. Explicitly map the notions, terms and methods that have been adopted from technologies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned technologies - not addressed. E.g.: a. The term "interface" that is, from my point of view one of the basic notions in the IETF networking, appears in the draft just 3 times: i. Two of the search hits are in the title of RFC 5837 (which is listed in the draft as one of the OAM tools without any explanation and then again as a normative reference) ii. The remaining hit is in Section 2.2.3 in the context of differences in MEP definitions between ITU-T Y.1731 and IEEE 802.1ag and deals with bridge interfaces, i.e., out of scope A side note: At the same time the draft mentioned the importance of placement of an MP (ingress, egress or forwarding function) in Section 2.2.3. I will present my concerns regarding this text later. b. The draft mentions ICMP ping and Traceroute as an "OAM tools", but it does not even try to explain: i. What constitutes the ME in which these tools operate ii. What are its MEPs and MIPs etc. (see also some comments below) c. The draft effectively ignores recent OAM-related activities as RFC 5837 (see above) and draft-ietf-mpls-tp-mep-mip-map. IMHO and FWIW, these documents are triggered by real-life operational concerns on one hand and implicitly (as in RFC 5837) or even explicitly deal with relationships between interfaces and nodes on one hand and MPs on the other hand. The caveat about dealing just with published RFCs may or may not be valid per se, but it definitely does not justify lack of any explanations/details regarding RFC 5387. 5. Expose, rather than avoid, known points of contention in a neutral way - I do not see this as a serious issue now. The bottom line is that the current version of the draft did not meet my expectations in this regard. This -again - may be because my expectations have been exaggerated or even completely unrealistic, or because the authors had in mind a different target audience and a different purpose. (I've said in my first review that explicitly specifying these (the purpose and the target audience) in the Introduction section would be helpful - but this has not been done either.) Readability of the draft: >From my point of view the draft still is not easily readable. I'd like to pint specifically to the following: not in the least because it contains quite a few inaccurate and/or controversial statements. E.g.: 1. Some terms and notions are introduced in the draft as if they were quite important, only to be forgotten later. E.g.: a. Section 1.1 mentions "Throughput measurement" as one of the 3 main functions of the performance monitoring which, in its turn, is defined as one of the OAM building blocks. However, throughput measurement is not mentioned anywhere else in the draft. b. "Communication link" mentioned in Section 2.2.2 is another such example c. The first statement in Section 1.1 states that "An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP)", but, again, Maintenance Domain is not mentioned anywhere else in the draft, leaving the reader to wonder how it is related to MEs, MEGs and the rest of the acronym soup. 2. Some referenced IETF documents are misrepresented. E.g.,: a. MPLS LSP Ping is mentioned in Section 1.3 as an "OAM mechanism for point to point MPLS LSPs". In fact, LSP ping works just fine with LSPs created by LDP, and these are MP2P b. In Section 2.2.3 the draft claims that MPLS-TP "uses ... Up/Down MPs" and refers to RFC 6371 as its source. However, the corresponding text in RFC 6371 only mentions Up/Down MEPs. (In this regard it is fully consistent with both IEEE 802.1ag and ITU-T Y.1731). 3. There are internal inconsistencies in the draft. E.g.: a. The naive interpretation of the already quoted statement from section 1.1 (see 1c above) is that "MPs are nodes" b. At the same time Section 2.3.3 states that "A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages". Major Issues: 1. OAM and its relationship to various network planes: In spite of the authors' attempt to resolve this issue, the concepts of data plane, control plane and management plane still are not properly explored in the draft: a. The term "data-plane" (with some modifications) is only found in Section 4.3 when discussing LSP-Ping ("data plane" is also found in the title of RFC 4379) b. An additional term "forwarding plane" appears in section 1.2, but nowhere else. The draft does not explain whether it means the same as data plane or not c. The terms "control-plane" ("control plane") are a bit more popular. They can be found: i. In Section 1.2 (which states that "OAM tools are defined independent of control plane" and that considerations of the control plane maintenance tools are out of scope) ii. In Section 3.3 (MPLS OAM) that explains that LSP Ping verifies "data-plane vs. control-plane consistency for FEC". This statement is correct, but IMO inconsistent with the previous one (see also my comment about CV above) iii. In Section 3.4 (MPLS-TP OAM) - mainly to explain that control plane is neither mandatory nor precluded in MPLS-TP d. The term "management plane" (with or without dash) appears only in Section 1.2. In addition to the already mentioned ability to operate on-demand OAM tools, ability of these tools to raise alarms is mentioned i. This is definitely a step forward vs. the -05 version ii. While RFC 6427 is now referenced in the draft (it was missing in the previous version), the draft does not mention alarm suppression function. And while it mentions AIS in MPLS-TP it only points to RFC 6327 for the explanation of the consequent actions of AIS. iii. For the sake of completeness, ability to clear alarms should also be mentioned IMO - but this is a very minor issue. e. The term "test plane" appears in Section 4.5, but, as already mentioned above, specific test plane protocols are not discussed in the draft 2. OAM in connectionless vs. connection-oriented networks a. The first sentence in Section 1 states that "OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation". To me this suggests that OAM is applicable only to connection-oriented networks (if you do not have connections, connection problems do not exist by definition). b. The term "connection" appears in some other places in the draft, e.g., the connectivity check "is used to verify the liveness of a connection" (Section 1.1). c. At the same time, the draft discusses: i. ICMP Ping (Section 3.1.1) operating in connectionless IP networks ii. LSP-Ping in MPLS networks (Section 3.3). Since LSP-Ping as defined in RFC 4379 is applicable to LSPs set up by LDP, I'd say that it operates in connectionless environment iii. Ethernet OAM (1.5) operating in connectionless Ethernet networks etc. 3. The Mess of MEs, MPs, MEPs and MIPs. a. Please consider the following text fragments i. (In section 2.2.2) OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. ii. (ibid.) Various terms are used to refer to an ME. For example, BFD does not explicitly use a term that is equivalent to ME, but rather uses the term "session", referring to the relationship between two nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this context iii. (In Section 2.2.3) A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. iv. (Ibid.) MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs). This placement is important for localization of a connection failure. b. The last of these statements seems to hint that with just two mutually exclusive types of MPs (UP/DOWN) it is possible to associated an MP with one of 3 possible placements (ingress, egress or forwarding function). c. IMHO and FWIW combining these statements can result in some unexpected (and undesirable) conclusions. E.g., i. Premises: . An MPLS LSP is an ME in the case of LSP Ping . An ME defines a point-to-point relationship between two points on a transport path . These points are defined at nodes Conclusion: An MPLS LSP can cross only two nodes (because in IP/MPLS LSP Ping can be initiated from any node participating in an LSP). ii. Premises: . BFD as defined in RFC 5880 is an OAM tool (it is listed as such in Table 1 in section 1.4) . OAM tools are designed to monitor MEs . In the case of a BFD a BFD session (there are no other sessions in RFC 5880) is an ME Conclusion: BFD is designed to monitor its own sessions (and hence is completely useless). A Side Note: The majority of problematic definitions in the draft are based on RFC 6371. IMHO and FWIW this results in 3 types of problems: . The authors misinterpret RFC 6371. E.g., it only speaks about UP and DOWN MEPs, not about UP and DOWN MPs , and it does not discuss ingress/egress/forwarding engine placement . The authors have tried to extend the definitions from 6371 to other IETF technologies (IP and IP/MPLS). E.g., in MPLS-TP sending LSP-Ping packets from an intermediate node of a co-routed bi-directional LSP towards one of its endpoints is possible, but the responses would not be received by the initiator... . Some of the original definitions in 6371 are problematic (among other things, this applies to UP and DOWN MEPs). Minor Issues: 1. Limited coverage of performance measurement. a. The draft mentions packet loss, delay/delay variation and the (undisclosed) throughput measurement. b. At the same time it ignores such issues as duplication and reordering (and does not mention RFC 4347 and RFC 5560 respectively) c. Connectivity measurement (RFC 2678) is referenced and mentioned in the text. But it is not mapped to any of the main performance measurements functions 2. Proposed classification of the IETF documents (into tools, profiles, infrastructure and miscellaneous) could be useful but is not consistently applied. E.g., a. I do not think that RFC 792 defines an OAM Tool b. I have serious doubts that RFC 4556 and RFC 5337 (defining the control plane for the IPPM mechanisms) are "OAM Tools" while all the referenced specific measurement protocols are "Miscellaneous" etc. Unfortunately could not provide any useful information regarding nits, typos etc. My review is incomplete in this regard, and I owe apologies to Routing ADs, my colleagues in the Routing Directorate and the authors. Regards, Sasha This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ------=_NextPart_000_0083_01CDFA26.98358D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending to correct = address.

 

Thanks Sasha for the = review.

 

Authors: we asked = Sasha to look at this document again (in addition to Carlos' review) = because he had provided a review of a previous version of the = document.

 

Thanks,

Adrian

 

From: Alexander = Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: 24 = January 2013 07:15
To: rtg-ads@tools.ietf.org
Cc: = rtg-dir@ietf.org; = 'drafts-ietf-opsawg-oam-overview.all@tools.ietf.org'
Subject: = RTG-DIR Review: = draft-ietf-opsawg-oam-overview-08.txt

 

Hello,

 

I have been selected as the Routing Directorate reviewer = for this draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please = see http://www.ietf.org/iesg/directorate/routing.html =

 

Although these comments are primarily for the use of the = Routing ADs, it would be helpful if you could consider them along with = any other IETF Last Call comments that you receive, and strive to = resolve them through discussion or by updating the draft. =

 

Document: = draft-ietf-opsawg-oam-overview-08.txt

Reviewer: Alexander (“Sasha”) = Vainshtein   

Review date: 23-Jan-13

IETF LC End Date: Not known

Intended status: Informational

 

Summary:

 

I have significant concerns about this document and = recommend that the Routing ADs discuss these issues further with the = authors.

 

To some extent these concerns reflect my personal and = potentially biased position with regard to OAM.

 

In addition, I’d like note that this is my second = review of this draft. The previous one has been done in August 2011 and = dealt with the -05 version of the draft (the review is attached). = Following this review I’ve hold a series of email exchanges and = off-line meetings with some of the authors in an attempt to resolve the = issues I’ve raised; but this process has not ever been = completed.

 

My current review hence is mainly focused on resolution (or = lack thereof) of the concerns I’ve raised in the previous review = round. This can be also considered as a bias (of a kind). Hence I ask = – again - the Routing ADs to take my comments with a grain of = salt.

 

Comments:

 

The needs of the assumed target = audience are not fully addressed in the = draft:

 

Just as in the previous reviewing cycle, I assume that the = intended target audience of the draft consists of various = “beginner” groups. 

The current version does not contain any indications that = this assumption is wrong (actually I did not find anything special about = target audience in the draft). Taking into account ongoing OAM-related = activities at the IETF (e.g., draft-mmm-bfd-on-lags), a good overview = document would be indeed most useful for these = groups.

 

Based on this assumption I’ve then suggested that in = order to provide appropriate guidance to the target audience, the draft = should:

 

1.       = Include a section on historical background of OAM – not addressed in the reviewed = version of the draft.

a.       = The single sentence “OAM was originally used in the = world of telephony, and has been adopted in packet based networks” = that has served as a somewhat short background section has disappeared = in this version of the draft

b.      = IMHO and FWIW absence of such a section makes it difficult = for, say, a reader with the background in OAM in SONET/SDH and/or OTN = networks to understand why OAM in packet networks is so = different.

2.       = Present a clear view of OAM functionality and its = relationship to various “planes” of = networking – at best, partially addressed in Section 1.2. = However, the new text seems potentially misleading to me, = e.g.:

a.       = The statement “ofte= n the on-demand tools may be activated by the management” seems to suggest = that on-demand OAM tools can be also activated in some other way. If the = intention has been activation of such tools via the control plane, = clarification would be very much in place

b.      = Connectivity Verification (CV) is mentioned as one of the = “OAM building blocks” (in Section 1.1), and the draft = explains that CV is used to verify that it is used “to verify that = the OAM messages are received through the expected path”. However, = the draft does not explain that the expected path is defined either by = the management or by the control plane, so that the entire CV function = does not make much sense without this = interaction.

3.       = Explain the importance of fate-sharing of OAM and user = traffic flows in packet networks – at best, partially addressed by the current = version of the draft:

a.       = The term “fate-sharing” does not appear in the = draft at all

b.      = The draft mentions that in MPLS-TP “OAM = packets and the user traffic are required to be congruent” = (Section 3.4.1). However, this is not extended to OAM tools for other = IETF-owned technologies (IP, IP/MPLS).

A side note: I am not sure that “congruent flows” and = “fate-sharing flows” mean exactly the same thing. E.g., in = IP/MPLS networks LSPs created by LDP are supposed to be congruent with = IP flows, but they are not fate-sharing.

4.       = Explicitly map the notions, terms and methods that have = been adopted from technologies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned technologies = – not addressed. E.g.:

a.       = The term “interface” that is, from my point of = view one of the basic notions in the IETF networking, appears in the = draft just 3 times:

           = ;            =             &= nbsp;           &n= bsp;      i.      = Two of the search hits are in the title of RFC 5837 (which = is listed in the draft as one of the OAM tools without any explanation = and then again as a normative reference)

           = ;            =             &= nbsp;           &n= bsp;     ii.      = The remaining hit is in Section  2.2.3 in the context = of differences in MEP definitions between ITU-T Y.1731 and IEEE 802.1ag = and deals with bridge interfaces, i.e., out of = scope

 

A side note: At the same time the draft mentioned the importance of = placement of an MP (ingress, egress or forwarding function) in Section = 2.2.3. I will present my concerns regarding this text = later.

 

b.      = The draft mentions ICMP ping and Traceroute as an = “OAM tools”, but it does not even try to = explain:

           = ;            =             &= nbsp;           &n= bsp;      i.      = What constitutes the ME in which these tools = operate

           = ;            =             &= nbsp;           &n= bsp;     ii.      = What are its MEPs and MIPs etc. (see also some comments = below)

c.       = The draft effectively ignores recent OAM-related activities = as RFC 5837 (see above) and draft-ietf-mpls-tp-mep-mip-map. IMHO and = FWIW, these documents are triggered by real-life operational concerns on = one hand and implicitly  (as in RFC 5837) or even explicitly deal = with relationships between interfaces and nodes on one hand and MPs on = the other hand. The caveat about dealing just with published RFCs may or = may not be valid per se, but it definitely does not justify lack = of any explanations/details regarding RFC 5387.

5.       = Expose, rather than avoid, known points of contention in a = neutral way – I do not see this as a serious issue = now.

 

The bottom line is that the current version of the draft = did not meet my expectations in this regard. This –again - may be = because my expectations have been exaggerated or even completely = unrealistic, or because the authors had in mind a different target = audience and a different purpose. (I’ve said in my first review = that explicitly specifying these (the purpose and the target audience) = in the Introduction section would be helpful – but this has not = been done either.)

 

Readability of the = draft:

 

From my point of view the draft = still is not easily readable. I’d like to pint specifically = to the following:

not in the least because = it contains quite a few inaccurate and/or controversial = statements. E.g.:

1.       = Some terms and notions are introduced = in the draft as if they were quite important, only to be forgotten = later. E.g.:

a.       = Section 1.1 mentions “Throughput = measurement” as one of the 3 main functions of the performance = monitoring which, in its turn, is defined as one of the OAM building = blocks. However, throughput measurement is not mentioned anywhere else = in the draft.

b.      = “Communication link” = mentioned in Section 2.2.2 is another such = example

c.       = The first statement in Section 1.1 = states that “An OAM protocol is run in the context of a = Maintenance Domain,   consisting of two or more nodes that run = the OAM protocol, referred to as Maintenance Points (MP)”, but, = again, Maintenance Domain is not mentioned anywhere else in the draft, = leaving the reader to wonder how it is related to MEs, MEGs and the rest = of the acronym soup.

2.       = Some referenced IETF documents are = misrepresented. E.g.,:

a.       = MPLS LSP Ping is mentioned in Section = 1.3 as an “OAM mechanism for point to point MPLS LSPs”. In = fact, LSP ping works just fine with LSPs created by LDP, and these are = MP2P

b.      =  In Section 2.2.3 the draft = claims that MPLS-TP “uses ... Up/Down MPs” and refers to RFC = 6371 as its source. However, the corresponding text in RFC 6371 only = mentions Up/Down MEPs. (In this regard it is fully consistent with both = IEEE 802.1ag and ITU-T Y.1731).

3.       = There are internal inconsistencies in = the draft. E.g.:

a.       = The naive interpretation of the = already quoted statement from section 1.1 (see 1c above) is that = “MPs are nodes”

b.      = At the same time Section 2.3.3 states = that “A Maintenance Point (MP) is a functional entity that is = defined at a node in the network, and either initiates or reacts to OAM = messages”.

 

Major Issues:

 

 

1.       = OAM and its relationship to various network = planes: In spite of the authors’ attempt to resolve this = issue, the concepts of data plane, control plane and management plane = still are not properly explored in the draft:  =

a.       = The term “data-plane” (with some modifications) = is only found in Section 4.3 when discussing LSP-Ping (“data = plane” is also found in the title of RFC = 4379)

b.      = An additional term “forwarding plane” appears = in section 1.2, but nowhere else. The draft does not explain whether it = means the same as data plane or not

c.       = The terms “control-plane” (“control = plane”) are a bit more popular. They can be = found:

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      i.      = In Section 1.2 (which states that “OAM tools are = defined independent of control plane” and that considerations of = the control plane maintenance tools are out of = scope)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     ii.      = In Section 3.3 (MPLS OAM) that explains that LSP Ping = verifies “data-plane vs. control-plane consistency for FEC”. = This statement is correct, but IMO inconsistent with the previous one = (see also my comment about CV above)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   iii.      = In Section 3.4 (MPLS-TP OAM) - mainly to explain that = control plane is neither mandatory nor precluded in =  MPLS-TP

d.      = The term “management plane” (with or without = dash) appears only in Section 1.2. In addition to the already mentioned = ability to operate on-demand OAM tools, ability of these tools to raise = alarms is mentioned

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      i.      = This is definitely a step forward vs. the -05 = version

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     ii.      = While RFC 6427 is now referenced in the draft (it was = missing in the previous version), the draft does not mention alarm = suppression function. And while it mentions AIS in MPLS-TP it only = points to RFC 6327 for the explanation of the consequent actions of AIS. =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   iii.      = For the sake of completeness, ability to clear alarms = should also be mentioned IMO – but this is a very minor = issue.

e.      = The term “test plane” appears in Section 4.5, = but, as already mentioned above,  specific test plane protocols are = not discussed in the draft

2.       = OAM in connectionless vs. connection-oriented = networks

a.       = The first sentence in Section 1 states that = “OAM = is a general term that refers to a toolset for detecting, isolating and = reporting connection failures and performance degradation”. To me this suggests that OAM is applicable only to = connection-oriented networks (if you do not have connections, = connection problems do not exist by = definition).

b.      = The term “connection” appears in some other = places in the draft, e.g., the connectivity check “is used to = verify the liveness of a connection” (Section = 1.1).

c.       = At the same time, the draft = discusses:

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      i.      = ICMP Ping (Section 3.1.1) operating in connectionless IP = networks

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     ii.      = LSP-Ping in MPLS networks (Section 3.3). Since LSP-Ping as = defined in RFC 4379 is applicable to LSPs set up by LDP, I’d say = that it operates in connectionless environment

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   iii.      = Ethernet OAM (1.5) operating in connectionless Ethernet = networks etc.

3.       = The Mess of MEs, MPs, MEPs and MIPs.

a.       = Please consider the following text = fragments

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      i.      = (In = section 2.2.2) OAM tools are designed to monitor and manage a = Maintenance Entity (ME).  An ME, as defined in [TP-OAM-FW], defines = a relationship between two points of a transport path to which = maintenance and monitoring operations apply.

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     ii.      = (ibid.) Various terms are used to refer to an ME. For = example, BFD does not explicitly use a term that is equivalent to ME, = but rather uses the term "session", referring to the = relationship between two nodes using a BFD protocol. The MPLS LSP Ping = ([LSP-Ping]) terminology simply uses the term "LSP" in this = context

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   iii.      = (In Section 2.2.3) A = Maintenance Point (MP) is a functional entity that is defined at a node = in the network, and either initiates or reacts to OAM messages. A = Maintenance End Point (MEP) is one of the end points of an ME, and can = initiate OAM messages and respond to them. A Maintenance Intermediate = Point (MIP) is an intermediate point between two MEPs, that does not = generally initiate OAM frames (one exception to this is the use of AIS = notifications), but is able to respond to OAM frames that are destined to it.

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   iv.      = (Ibi= d.) MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of = the MP - either at the ingress, egress, or forwarding function of the = node (Down / Up MPs).  This placement is important for localization = of a connection failure.

b.      = The last of these statements seems to hint that with just = two  mutually exclusive types of MPs (UP/DOWN) it is possible to = associated an MP with one of 3 possible placements (ingress, egress or = forwarding function).

c.       = IMHO and FWIW combining these statements can result in some = unexpected (and undesirable) conclusions. E.g.,

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      i.      = Premises:

·         = An MPLS LSP is an ME in the case of LSP = Ping

·         = An ME defines a point-to-point relationship between two = points on a transport path

·         = These points are defined at nodes

Conclusion: An MPLS LSP can cross only two nodes = (because in IP/MPLS LSP Ping can be initiated from any node = participating in an LSP).

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     ii.      = Premises:

·         = BFD as defined in RFC 5880 is an OAM tool (it is listed as = such in Table 1 in section 1.4) 

·         = OAM tools are designed to monitor = MEs

·         = In the case of a BFD  a BFD session (there are no = other sessions in RFC 5880) is an ME

Conclusion: BFD is designed to monitor its own sessions = (and hence is completely useless).

 

 

A Side Note: The majority of problematic definitions in the draft are = based on RFC 6371. IMHO and FWIW this results in 3 types of = problems:

·         = The authors misinterpret RFC 6371. E.g., it only speaks = about UP and DOWN MEPs, not about UP and DOWN MPs , and it does not = discuss ingress/egress/forwarding engine = placement

·         = The authors have tried to extend the definitions from 6371 = to other IETF technologies (IP and IP/MPLS). E.g., in MPLS-TP sending = LSP-Ping packets from an intermediate node of a co-routed bi-directional = LSP towards one of its endpoints is possible, but the responses would = not be received by the initiator...

·         = Some of the original definitions in 6371 are problematic = (among other things, this applies to UP and DOWN = MEPs).

 

Minor Issues:

1.       = Limited coverage of performance measurement. =

a.       = The draft mentions packet loss, delay/delay variation and = the (undisclosed) throughput measurement.

b.      = At the same time it ignores such issues as duplication and = reordering (and does not mention RFC 4347 and RFC 5560 = respectively)

c.       = Connectivity measurement (RFC 2678) is referenced and = mentioned in the text. But it is not mapped to any of the main = performance measurements functions

2.       = Proposed classification of the IETF documents (into tools, = profiles, infrastructure and miscellaneous) could be useful but is not = consistently applied. E.g.,

a.       = I do not think that RFC 792 defines an OAM = Tool

b.      = I have serious doubts that RFC 4556 and RFC 5337 (defining = the control plane for the IPPM mechanisms) are “OAM Tools” = while all the referenced specific measurement protocols are = “Miscellaneous” etc.

 

Unfortunately could not provide any useful information = regarding nits, typos etc. My review is incomplete in this regard, and I = owe apologies to Routing ADs, my colleagues in the Routing Directorate = and the authors.

 

Regards,

     Sasha

 

 

 

This e-mail message is = intended for the recipient only and contains information which is = CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------=_NextPart_000_0083_01CDFA26.98358D00-- From rcallon@juniper.net Mon Jan 28 11:50:06 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7F21F8786; Mon, 28 Jan 2013 11:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.166 X-Spam-Level: X-Spam-Status: No, score=-101.166 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 272DZcTkvojD; Mon, 28 Jan 2013 11:50:02 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8199E21F8609; Mon, 28 Jan 2013 11:50:00 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUQbWaAm+IjCwOmsd33bgGCxP1oyrySpc@postini.com; Mon, 28 Jan 2013 11:50:00 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 28 Jan 2013 11:49:46 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 28 Jan 2013 11:49:46 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 28 Jan 2013 11:58:42 -0800 Received: from mail177-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 Jan 2013 19:49:45 +0000 Received: from mail177-va3 (localhost [127.0.0.1]) by mail177-va3-R.bigfish.com (Postfix) with ESMTP id ED6812C02A5; Mon, 28 Jan 2013 19:49:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zzd6eahc85fh1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail177-va3 (localhost.localdomain [127.0.0.1]) by mail177-va3 (MessageSwitch) id 1359402554583527_23746; Mon, 28 Jan 2013 19:49:14 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.243]) by mail177-va3.bigfish.com (Postfix) with ESMTP id 7DE1C2A038B; Mon, 28 Jan 2013 19:49:14 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 Jan 2013 19:49:11 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.95]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0263.000; Mon, 28 Jan 2013 19:49:11 +0000 From: Ross Callon To: "rtg-ads@tools.ietf.org" , "stbryant@cisco.com" , "sprevidi@cisco.com" , "imc.shand@googlemail.com" Thread-Topic: RtgDir review: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Thread-Index: Ac39kIjuJs7ZF2k9QSqE3UIX51Y07g== Date: Mon, 28 Jan 2013 19:49:10 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309A77BCC@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOOGLEMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Ross Callon , "rtg-dir@ietf.org" , "rtgwg@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:50:06 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Reviewer: Ross Callon Review Date: January 28, 2013 IETF LC End Date: January 31, 2013 Intended Status: informational Summary: This document is basically ready for publication, but has nits th= at should be considered prior to publication. Comments: Generally this document is very well written and is very readable. I have o= nly very minor comments that I think that you should consider prior to publ= ication. Major Issues: No major issues found. Minor Issues: The first paragraph of 3.2 is a bit imprecise. It says that there are advan= tages of using not-via in combination with LFA, but then two of the three a= dvantages cited don't actually apply to the combination, but only to using = LFA without not-via (which of course has the disadvantage of not offering c= omplete coverage, as is discussed in the next paragraph). Up until section 4.1, the document pretty much reads as if we are talking a= bout node protection. 4.1 then just sort of forgets (or generalizes) this a= nd jumps into options for both node protection and link protection. I think= that it is appropriate for section 3 to read the way that it currently doe= s, since it is an overview and does a good job of introducing the technique= without confusing the reader with complexities (which are appropriately co= vered later in the document). To me this implies that somewhere in section = 4, prior to the current section 4.1, you might want a brief discussion of n= ode protection versus link protection. You might consider adding something = like: In general it may be difficult for a router to quickly distinguish betwee= n link failure and node failure. For example in figure 1 node S might see the link to node P suddenly totally fail. In general it is impossible to immediately determine whether node P has failed or if the link from S to = P has failed (in some cases link layer indications might give information regarding what is going on, and the updates to link state packets from node P or from all neighbors of node P will eventually clarify what has failed once received and processed). For this reason it is generally safer to assume that node P has failed and where possible reroute traffic to the next node downstream from P. However, there may be cases where this is impossible. For example some destinations might be only reachable via node P, and in some topologies the failure of node P may partition the network. For this reason we need to consider both node and link failures. Returning to section 4.1, I think that it would be a bit clearer if the las= t sentence of the first paragraph were its own paragraph. This would cause = 4.1 to start with a general discussion, then have a paragraph about link pr= otection, then have a paragraph about node protection. The last sentence of section 4.1 is imprecise. It currently states: "In the= case of link protection this simply means that the advertisement from P to= S is suppressed, with the result that S and all other nodes compute a rout= e to Ps which doesn't traverse S, as required". However, this does not actu= ally compute a route that is guaranteed to not traverse node S, it computes= a route that does not traverse the link from S to P. The sentence should r= ead: "In the case of link protection this simply means that the advertiseme= nt from P to S is suppressed, with the result that S and all other nodes co= mpute a route to Ps which doesn't traverse the link from S to P, as require= d". Section 5.1, second paragraph: "ANY failure" should be "ANY single failure"= . Section 6.1: At first glance it seemed somewhat drastic to have a MUST assu= me that all other links of the SRLG have failed. After reading the entire s= ection and thinking about this for a while, I have come to the conclusion t= hat you are correct. However, I am wondering whether just a bit more explan= ation might be useful. I am therefore wondering about additional explanatio= n so that the first paragraph of section 6.1 might read: A Shared Risk Link Group (SRLG) is a set of links whose failure can be caused by a single action such as a conduit cut or line card failure. When repairing the failure of a link that is a member of an SRLG, it is not immediately known whether the entire group has failed or only that link. In order to avoid multiple problems as explained below, it MUST be assumed that all the other links that are also members of the SRLG have also failed. Consequently, any repair path MUST be computed to avoid not just the adjacent link, but also all the links which are members of the same SRLG. Nit: At first glance section 3.1 seems a bit terse. I am undecided whether it wo= uld be worthwhile to add a bit more explanation. The current text is clear = enough to one well versed in the various routing technologies and what I ha= ve been able to think of as possible additional text seems almost too obvio= us. As an example the first paragraph could be added to, to read: A router can use an equal cost multi-path (ECMP) repair in place of a not-via repair. For example, if a router has multiple equal cost next ho= ps to a particular destination, and the link to one fails, it just forwards= all traffic to the other equal cost next hop(s) without using not-via. Similarly the second paragraph could be added to, to read: A router computing a not-via repair path MAY subject the repair to ECMP. For example in figure 1 there may be multiple equal cost paths from S to Bp, each of which avoids node P. Since not-via encapsulates a packet to Bp, equal cost multipath will work in the normal way for computing and using paths from S to Bp. Again these updates almost seem too trivial, so I have included this sugges= tion under "nits" and will leave it to the discretion of the authors whethe= r they want to make any changes. --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have been selected as the Routing Directorate reviewer for this draf= t. The Routing Directorate seeks to review all routing or routing-related d= rafts as they pass through IETF last call and IESG review, and sometimes on= special request. The purpose of the review is to provide assistance to the Routing ADs. For more informatio= n about the Routing Directorate, please see http://www.ie= tf.org/iesg/directorate/routing.html
 
Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF La= st Call comments that you receive, and strive to resolve them through discu= ssion or by updating the draft.
 
Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10
Reviewer: Ross Callon
Review Date: January 28, 2013
IETF LC End Date: January 31, 2013
Intended Status: informational 
 
Summary:  This document is basically ready for publication, but h= as nits that should be considered prior to publication.
 
Comments:
 
Generally this document is very well written and is very readable. I h= ave only very minor comments that I think that you should consider prior to= publication.
 
Major Issues:  No major issues found.
 
Minor Issues:
 
The first paragraph of 3.2 is a bit imprecise. It says that there are = advantages of using not-via in combination with LFA, but then two of the th= ree advantages cited don’t actually apply to the combination, but onl= y to using LFA without not-via (which of course has the disadvantage of not offering complete coverage, as is dis= cussed in the next paragraph).
 
Up until section 4.1, the document pretty much reads as if we are talk= ing about node protection. 4.1 then just sort of forgets (or generalizes) t= his and jumps into options for both node protection and link protection. I = think that it is appropriate for section 3 to read the way that it currently does, since it is an overview a= nd does a good job of introducing the technique without confusing the reade= r with complexities (which are appropriately covered later in the document)= . To me this implies that somewhere in section 4, prior to the current section 4.1, you might want a brief disc= ussion of node protection versus link protection. You might consider adding= something like:
 
  In general it may be difficult for a router to quickly distingu= ish between
  link failure and node failure. For example in figure 1 node S m= ight see
  the link to node P suddenly totally fail. In general it is impo= ssible to
  immediately determine whether node P has failed or if the link = from S to P
  has failed (in some cases link layer indications might give inf= ormation
  regarding what is going on, and the updates to link state packe= ts from
  node P or from all neighbors of node P will eventually clarify = what has
  failed once received and processed). For this reason it is gene= rally
  safer to assume that node P has failed and where possible rerou= te
  traffic to the next node downstream from P. However, there may = be cases
  where this is impossible. For example some destinations might b= e only
  reachable via node P, and in some topologies the failure of nod= e P may
  partition the network. For this reason we need to consider both= node and
  link failures.
 
Returning to section 4.1, I think that it would be a bit clearer if th= e last sentence of the first paragraph were its own paragraph. This would c= ause 4.1 to start with a general discussion, then have a paragraph about li= nk protection, then have a paragraph about node protection.
 
The last sentence of section 4.1 is imprecise. It currently states: &#= 8220;In the case of link protection this simply means that the advertisemen= t from P to S is suppressed, with the result that S and all other nodes com= pute a route to Ps which doesn't traverse S, as required”. However, this does not actually compute a route that= is guaranteed to not traverse node S, it computes a route that does not tr= averse the link from S to P. The sentence should read: “In the case o= f link protection this simply means that the advertisement from P to S is suppressed, with the result that S and all oth= er nodes compute a route to Ps which doesn't traverse the link from S to P,= as required”.
 
Section 5.1, second paragraph: “ANY failure” should be = 220;ANY single failure”.
 
Section 6.1: At first glance it seemed somewhat drastic to have a MUST= assume that all other links of the SRLG have failed. After reading the ent= ire section and thinking about this for a while, I have come to the conclus= ion that you are correct. However, I am wondering whether just a bit more explanation might be useful. I am th= erefore wondering about additional explanation so that the first paragraph = of section 6.1 might read:
 
   A Shared Risk Link Group (SRLG) is a set of links whose f= ailure can
   be caused by a single action such as a conduit cut or lin= e card
   failure.  When repairing the failure of a link that = is a member of an
   SRLG, it is not immediately known whether the entire grou= p has failed
   or only that link. In order to avoid multiple problems as= explained
   below, it MUST be assumed that all the other links that a= re also
   members of the SRLG have also failed.  Consequently,= any repair path
   MUST be computed to avoid not just the adjacent link, but= also all
   the links which are members of the same SRLG.
 
Nit:
 
At first glance section 3.1 seems a bit terse. I am undecided whether = it would be worthwhile to add a bit more explanation. The current text is c= lear enough to one well versed in the various routing technologies and what= I have been able to think of as possible additional text seems almost too obvious. As an example the first = paragraph could be added to, to read:
 
   A router can use an equal cost multi-path (ECMP) repair i= n place of a
   not-via repair. For example, if a router has multiple equ= al cost next hops
   to a particular destination, and the link to one fails, i= t just forwards all
   traffic to the other equal cost next hop(s) without using= not-via.
 
Similarly the second paragraph could be added to, to read:
 
   A router computing a not-via repair path MAY subject the = repair to
   ECMP. For example in figure 1 there may be multiple equal= cost paths
   from S to Bp, each of which avoids node P. Since not-via = encapsulates
   a packet to Bp, equal cost multipath will work in the nor= mal way for
   computing and using paths from S to Bp.
 
Again these updates almost seem too trivial, so I have included this s= uggestion under “nits” and will leave it to the discretion of t= he authors whether they want to make any changes.
 
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_-- From acee.lindem@ericsson.com Wed Jan 30 10:34:04 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3821F886C; Wed, 30 Jan 2013 10:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbTBgUhSxYIV; Wed, 30 Jan 2013 10:34:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8B21F888E; Wed, 30 Jan 2013 10:34:02 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-77-51096792fac4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BB.5A.31450.29769015; Wed, 30 Jan 2013 19:33:55 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 13:33:54 -0500 From: Acee Lindem To: Stewart Bryant , "Stefano Previdi (sprevidi)" , "Mike Shand (mshand)" , "Pierre Francois" , Clarence FilsFils , Olivier Bonaventure Thread-Topic: Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Index: AQHN/xhbkBCAkpY70028Ms+8Xewwcg== Date: Wed, 30 Jan 2013 18:33:54 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonSndyOmegQWsTt8XO2T1sFs+/XmC2 uNHwg8Xizbs/bBYL1jxlt7jw5jezxfrdj5gszj2dw+jA4THl90ZWjyVLfjJ5fF97jdnj1bHv LAEsUVw2Kak5mWWpRfp2CVwZt1ZMYy/YU1bx++pMxgbGowldjBwcEgImEn96RboYOYFMMYkL 99azdTFycQgJHGGU+DlrKTOEs5xR4sO/h8wgVWwCOhLPH/0DS4gIzGSS+DZ5KgtIglnAR+Jd 4092EFtYIEpi0YVjbCC2iEC8xLflW5kgbD2JX38vgA1iEVCV+LFgDyOIzSvgLdG/5i1YnBHo jO+n1jBBzBSXuPVkPhPEeQISS/acZ4awRSVePv7HCmErSyx5sh/qhnyJC78hDuUVEJQ4OfMJ ywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx5D9VpL3P75mQVZzQJGjlWMHKXF qWW56UYGmxiB8XhMgk13B+Oel5aHGKU5WJTEeYNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYAxcuOHjq4zN+44s8L3988iyxRIxTmqL9DdfTJ3u42yX8//4rtAnnhZBPq9OxRrNOBLA 0sa0OSj/+mUl3f9asX0svKV/3I7U9P/gWr/SuVry36V056dPkytObOWNUfz6YaFBS+v6SbZd hsY8azxduCvtb5W5+MbP8SzaULHc7PiK5yyPZp+XZ1diKc5INNRiLipOBADSh+6VlQIAAA== Cc: "rtg-dir@ietf.org" , "rtgwg@ietf.org" Subject: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 18:34:04 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, et al, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 Reviewer: Acee Lindem Review Date: January 30, 2013 IETF LC End Date: January 31, 2013 Intended Status: informational Summary: This document is basically ready for publication, but has clarifi= cation that should be considered prior to publication. Comments: The document accomplishes what it sets out to achieve in document= ing the ordered FIB mechanism for avoidance of transient loops. While Appen= dix B is useful, I think the document would be better without Appendix A. O= f course, this is just my opinion. Major Issues: None Minor Issues: 1. The document could benefit for a precise defi= nition of a "non-urgent topology change". From what I gathered, this is any= change that can be deferred during the ordered FIB delay. 2. Similarly, the document could benefit from a = precise definition of the "rSPF". I checked RFC 5715 and it is not defined = there either. I believe our discussions indicate that this is simply an SPF= where the shortest path back to us is used as the cost. For example, for t= he first pass, the SPF would use our neighbor's link cost rather than our o= wn. 3. It would be good to state early on that the c= urrent oFIB mechanism is limited to a single link or node failure and that = multiple unrelated failures result in reversion to normal FIB convergence. 4. Make sure the hold down timer is defined prec= isely and early in the document. Currently, this doesn't happen until secti= on 8.2. 5. Upon the initial reading, one may think there= is some correspondence between the Router (R) in sections 4 and the Router= (R) in section 5. Can this be clearer? Perhaps, (R) is not needed in secti= on 4 since in all other sections, it refers to the computing router. 6. In section 5, I have trouble envisioning a ca= se where a router would not be in an pre or post failure SPT. I guess if it= had no loopbacks and only unnumbered interfaces or only interfaces to broa= dcast links offering a longer path??? 7. In section 6.2, it would be instructive to sa= y that a Link Down condition is represented by an infinite metric (or other= wise cover this condition). 8. In section 8.5, I believe this a different ho= ld down timer than the one used to group LSPs related to the same failure. Nits: 1. Abstract - replace "However mechanism" with "Howeve= r the mechanism". I chose singular since it is singular in the preceding te= xt. 2. Introduction - replace "base (FIB)" with "bases (FI= Bs)" in the first sentence. 3. Page 5, replace "change order no" with "change orde= r, no". 4. Page 9, suggest adding "IGP " to "reverse connectiv= ity check". 5. Page 10, suggest using parenthesis rather than rely= ing on arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) 6. There is a mixture of "neighbor" and "neighbour" in= the document. Of course, I prefer the US English to UK English since this = is what all the OSPF RFCs use. 7. Section 8.1, the actions are formatting inconsisten= tly. In one case, as a paragraph and the other as a list. 8. Page 19, replace "algorithms i.e." with "algorithms= , i.e.". 9. Page 19 and Page 22, use of (PNSM) and (PN) is inco= nsistent. 10. Page 23, Run-on sentence beginning "Manual configurat= ion...". 11. There some instances where the opening clause for a s= entence is preceded with a comma and some where it is not. I prefer the for= mer. For example, section 4.2 appears to be written in a different style wi= th missing punctuation. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <923B7C27A8F7824F95E62CA87FF8D8E7@ericsson.com> Content-Transfer-Encoding: quoted-printable
Authors, et al,
 
I have been selected= as the Routing Directorate reviewer for this draft. The Routing Directorat= e seeks to review all routing or routing-related drafts as they pass throug= h IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing Direc= torate, please see http://www.ietf.org/iesg/directorate/routing.html
 
Although these comme= nts are primarily for the use of the Routing ADs, it would be helpful if yo= u could consider them along with any other IETF Last Call comments that you= receive, and strive to resolve them through discussion or by updating the draft.
 
Document: draft-ietf= -rtgwg-ipfrr-ordered-fib-08
Reviewer: Acee Linde= m
Review Date: January= 30, 2013
IETF LC End Date: Ja= nuary 31, 2013
Intended Status: inf= ormational 
 
Summary:  This = document is basically ready for publication, but has clarification that sho= uld be considered prior to publication.
 
Comments: The docume= nt accomplishes what it sets out to achieve in documenting the ordered FIB = mechanism for avoidance of transient loops. While Appendix B is useful, I t= hink the document would be better without Appendix A. Of course, this is just my opinion. 

Major Issues: None&n= bsp;

Minor Issues:  =                     = ;   
     =                     &nbs= p;1. The document could benefit for a precise definition of a "non-urg= ent topology change". From what I gathered, this is any change that ca= n be deferred during the ordered FIB delay. 
     =                     &nbs= p;2. Similarly, the document could benefit from a precise definition of the= "rSPF". I checked RFC 5715 and it is not defined there either. I= believe our discussions indicate that this is simply an SPF where the shortest path back to us is used as the co= st. For example, for the first pass, the SPF would use our neighbor's link = cost rather than our own. 
     =                     &nbs= p;3. It would be good to state early on that the current oFIB mechanism is = limited to a single link or node failure and that multiple unrelated failur= es result in reversion to normal FIB convergence. 
     =                     &nbs= p;4. Make sure the hold down timer is defined precisely and early in the do= cument. Currently, this doesn't happen until section 8.2. 
     =                     &nbs= p;5. Upon the initial reading, one may think there is some correspondence b= etween the Router (R) in sections 4 and the Router (R) in section 5. Can th= is be clearer? Perhaps, (R) is not needed in section 4 since in all other sections, it refers to the comp= uting router. 
     =                     &nbs= p;6. In section 5, I have trouble envisioning a case where a router would n= ot be in an pre or post failure SPT. I guess if it had no loopbacks and onl= y unnumbered interfaces or only interfaces to broadcast links offering a longer path??? 
     =                     &nbs= p;7. In section 6.2, it would be instructive to say that a Link Down condit= ion is represented by an infinite metric (or otherwise cover this condition= ). 
     =                     &nbs= p;8. In section 8.5, I believe this a different hold down timer than the on= e used to group LSPs related to the same failure. 

Nits: 

     =                1. Abstract - repla= ce "However mechanism" with "However the mechanism". I = chose singular since it is singular in the preceding text. 
     =                2. Introduction - r= eplace "base (FIB)" with "bases (FIBs)" in the first se= ntence. 
     =                3. Page 5, replace = "change order no" with "change order, no". 
     =                4. Page 9, suggest = adding "IGP " to "reverse connectivity check". 
     =                5. Page 10, suggest= using parenthesis rather than relying on arithmetic precedence for equatio= ns, e.g., T0 + H + (rank * MAX_FIB) 
     =                6. There is a mixtu= re of "neighbor" and "neighbour" in the document. Of co= urse, I prefer the US English to UK English since this is what all the OSPF= RFCs use. 
     =                7. Section 8.1, the= actions are formatting inconsistently. In one case, as a paragraph and the= other as a list.  
     =                8. Page 19, replace= "algorithms i.e." with "algorithms, i.e.". 
     =                9. Page 19 and Page= 22, use of (PNSM) and (PN) is inconsistent. 
     =             10. Page 23, Run-on sentence beg= inning "Manual configuration...". 
     =             11. There some instances where t= he opening clause for a sentence is preceded with a comma and some where it= is not. I prefer the former. For example, section 4.2 appears to be writte= n in a different style with missing punctuation. 


Thanks,
Acee 



 
 

--_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_-- From adrian@olddog.co.uk Thu Jan 31 07:15:05 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6121F84E8 for ; Thu, 31 Jan 2013 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHtW6WpOJMZ for ; Thu, 31 Jan 2013 07:15:05 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E51FB21F84BF for ; Thu, 31 Jan 2013 07:15:04 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0VFEvTL029669; Thu, 31 Jan 2013 15:14:57 GMT Received: from 950129200 (83-215-186-5.stjo.dyn.salzburg-online.at [83.215.186.5]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0VFEtRU029615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jan 2013 15:14:56 GMT From: "Adrian Farrel" To: Date: Thu, 31 Jan 2013 15:14:55 -0000 Message-ID: <007601cdffc5$ba8263c0$2f872b40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3/xYkm/t5LtcL7QZWJQt89ccnHvA== Content-Language: en-gb Cc: 'Abhay Roy' Subject: [RTG-DIR] Abhay Roy retiring from the Routing Directorate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:15:05 -0000 Owing to pressure of real-world activities, Abhay has chosen to not renew his membership of the Directorate. Stewart and I would like to express our thanks for Abhay's contributions. Adrian From acee.lindem@ericsson.com Thu Jan 31 07:27:33 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48A721F8233 for ; Thu, 31 Jan 2013 07:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHxBzuIqYVcS for ; Thu, 31 Jan 2013 07:27:33 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 345E021F8230 for ; Thu, 31 Jan 2013 07:27:33 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-8d-510a8d64a109 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 76.60.31450.46D8A015; Thu, 31 Jan 2013 16:27:32 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 10:27:32 -0500 From: Acee Lindem To: "" Thread-Topic: [RTG-DIR] Abhay Roy retiring from the Routing Directorate Thread-Index: Ac3/xYkm/t5LtcL7QZWJQt89ccnHvAAK9vWA Date: Thu, 31 Jan 2013 15:27:31 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B6B59@eusaamb101.ericsson.se> References: <007601cdffc5$ba8263c0$2f872b40$@olddog.co.uk> In-Reply-To: <007601cdffc5$ba8263c0$2f872b40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <46A4811B48F437449AB7F82858AC4C82@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPrG5KL1egwbQXShY/em4wWxw+OIvN YsGap+wOzB5Tfm9k9Viy5CeTx4rNKxkDmKO4bFJSczLLUov07RK4MpatmcBUcJW54s/+kgbG V0xdjBwcEgImEtMfhHcxcgKZYhIX7q1n62Lk4hASOMIo0Td3MROEs5xR4kv3ZCaQKjYBHYnn j/4xgzSLCBhKHHgWAGIyC7hJTHwuCFIhDGS+WDwNrFpEwF3i4ryFLBC2kcTtJzfAbBYBVYkL f2+zgti8At4SJ978ZwOxhQSsJFatXABmcwpYS2y/2cMMYjMC3fb91BqwmcwC4hK3nsxngrhZ QGLJnvPMELaoxMvH/1ghbGWJ73MesUDU60gs2P2JDcK2lrh7fBEjhK0tsWzha2aIGwQlTs58 wjKBUXwWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxlsYgTG2DEJNt0djHteWh5ilOZg URLnDXK9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcS7TnCe372r+Xle6hKnkUmnb5Pl5 28vZRCzupBS0tjP1uM27prN85x2D91whEi7NCRflM5g/Z8Wv/pk0/UZV0tbGYuEnDHcFi778 806ZnH3ywWwek+/zJGccd+usjI2721vySX+t4/Li/78uBXVOq7m0Tz/b4IzlbsmCW+XvpI1S zAXVtt8KUWIpzkg01GIuKk4EAA0CK3l/AgAA Cc: "" , Abhay Roy Subject: Re: [RTG-DIR] Abhay Roy retiring from the Routing Directorate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:27:33 -0000 On Jan 31, 2013, at 10:14 AM, Adrian Farrel wrote: > Owing to pressure of real-world activities, I'd hope some of the drafts we review are "real-world". However, there are = definitely those that are not ;^).=20 > Abhay has chosen to not renew his > membership of the Directorate.=20 >=20 > Stewart and I would like to express our thanks for Abhay's contributions. Yes - especially thanks for reviewing RPL.=20 Acee=20 >=20 > Adrian >=20 From adrian@olddog.co.uk Thu Jan 31 11:07:28 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22FD21F845D for ; Thu, 31 Jan 2013 11:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rtJ3O32PDIN for ; Thu, 31 Jan 2013 11:07:27 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1608621F8441 for ; Thu, 31 Jan 2013 11:07:26 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0VJ7MvT025431; Thu, 31 Jan 2013 19:07:22 GMT Received: from 950129200 (089144192207.atnat0001.highway.a1.net [89.144.192.207]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0VJ7JSq025417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jan 2013 19:07:21 GMT From: "Adrian Farrel" To: Date: Thu, 31 Jan 2013 19:07:18 -0000 Message-ID: <003101cdffe6$320016c0$96004440$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3/5irpl4757lE/SjGcqJB9bxKgzg== Content-Language: en-gb Cc: enkechen@cisco.com Subject: [RTG-DIR] Enke Chen retiring from the Routing Directorate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:07:28 -0000 Owing to pressure of real-world activities, Enke has also chosen to not renew his membership of the Directorate. Stewart and I would like to express our thanks for Enke's contributions. Adrian From stbryant@cisco.com Thu Jan 31 11:47:53 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7336421F8860; Thu, 31 Jan 2013 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.512 X-Spam-Level: X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWp4s9Im20Dl; Thu, 31 Jan 2013 11:47:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0021F885C; Thu, 31 Jan 2013 11:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7611; q=dns/txt; s=iport; t=1359661671; x=1360871271; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZWmqj7GpHk6EL7Xbc3QH/0dTv6xUktE+eagiGhTqpWk=; b=Y+PBt4mgPkBsJEVh5hQ5cKGWRR3/hcilvLhE8W3T5MwjkNnLW2ZmULx8 W6wKTo+wFyyzez02M6s2EPD0mytquD01GKuHIanHPfzmI3M4DmZxhkW3q Jbzz9CI7FX+6D1jw+HUXZmrgmEgBoFwqLaA7dStEZJDGZi0G5a/RFjxqd Y=; X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="80156022" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2013 19:47:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0VJloFV032226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 19:47:50 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r0VJlnhg023558; Thu, 31 Jan 2013 19:47:49 GMT Message-ID: <510ACA65.9010307@cisco.com> Date: Thu, 31 Jan 2013 19:47:49 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , Clarence FilsFils , Pierre Francois , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , "rtgwg@ietf.org" , "Mike Shand \(mshand\)" Subject: Re: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:47:53 -0000 On 30/01/2013 18:33, Acee Lindem wrote: > Authors, et al, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 > Reviewer: Acee Lindem > Review Date: January 30, 2013 > IETF LC End Date: January 31, 2013 > Intended Status: informational > Summary: This document is basically ready for publication, but has > clarification that should be considered prior to publication. > Comments: The document accomplishes what it sets out to achieve in > documenting the ordered FIB mechanism for avoidance of transient > loops. While Appendix B is useful, I think the document would be > better without Appendix A. Of course, this is just my opinion. AAH took a lot of thought, so we would rather not loose it, if it works better I could reverse the order of the appendixes. > > Major Issues: None > > Minor Issues: > 1. The document could benefit for a precise definition of > a "non-urgent topology change". From what I gathered, this is any > change that can be deferred during the ordered FIB delay. The abstract now says "This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes." 3.1.1 says "First consider the non-urgent failure of a link (i.e. where an operator or a network management system (NMS) shuts down a link thereby removing it from the currently active topology) or the increase of a link metric by the operator or NMS ." The point is of course that although a link is shut down rather than failing, a remote node cannot distinguish the two cases. > 2. Similarly, the document could benefit from a precise > definition of the "rSPF". I checked RFC 5715 and it is not defined > there either. I believe our discussions indicate that this is simply > an SPF where the shortest path back to us is used as the cost. For > example, for the first pass, the SPF would use our neighbor's link > cost rather than our own. We use rSPT in here. As you know we are looking for a formal definition. I have put in Section 5 This computation required the introduction of the concept of a reverse Shortest Path Tree (rSPT). The rSPT uses the cost towards the root rather than from it and yields the best paths towards the root from other nodes in the network [I-D.draft-bryant-ipfrr-tunnels]. If there is a better ref we can swap in Auth48. > 3. It would be good to state early on that the current > oFIB mechanism is limited to a single link or node failure and that > multiple unrelated failures result in reversion to normal FIB > convergence. Done (in section 2). > 4. Make sure the hold down timer is defined precisely and > early in the document. Currently, this doesn't happen until section 8.2. On first use it says: If all events received within some hold-down period (the time that a router waits to acquire a set of LSPs which should be processed together) h > 5. Upon the initial reading, one may think there is some > correspondence between the Router (R) in sections 4 and the Router (R) > in section 5. Can this be clearer? Perhaps, (R) is not needed in > section 4 since in all other sections, it refers to the computing router. R is now removed. As has been described, a single event such as the failure or restoration of a single link, single router or a linecard may be notified to the rest of the network as a set of individual link change events. It is necessary to deduce from this collection of link state notifications the type of event that has occurred in the network and hence the required ordering. When a link change event is received which impacts the receiving router's FIB, the routers at the near and far end of the link are noted. If all events received within some hold-down period (the time that a router waits to acquire a set of LSPs which should be processed together) have a single router in common, then it is assumed that the change reflects an event (line-card or router change) concerning that router. In the case of a link change event, the router at the far end of the link is deemed to be the common router. All ordering computations are based on treating the common router as the root for both link and node events. > 6. In section 5, I have trouble envisioning a case where > a router would not be in an pre or post failure SPT. I guess if it had > no loopbacks and only unnumbered interfaces or only interfaces to > broadcast links offering a longer path??? This is the case where you have an unused link (due to costs), i.e. a link not on any shortest path. > 7. In section 6.2, it would be instructive to say that a > Link Down condition is represented by an infinite metric (or otherwise > cover this condition). I have added "Inclusion or removal of link" to the information list. > 8. In section 8.5, I believe this a different hold down > timer than the one used to group LSPs related to the same failure. Yes. I have changes this to AAH_Hold_down_timer expires Pierre and Mike please check this. > > Nits: > > 1. Abstract - replace "However mechanism" with "However the > mechanism". I chose singular since it is singular in the preceding text. done > 2. Introduction - replace "base (FIB)" with "bases (FIBs)" in > the first sentence. Done > 3. Page 5, replace "change order no" with "change order, no". Done > 4. Page 9, suggest adding "IGP " to "reverse connectivity check". Done > 5. Page 10, suggest using parenthesis rather than relying on > arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) Done > 6. There is a mixture of "neighbor" and "neighbour" in the > document. Of course, I prefer the US English to UK English since this > is what all the OSPF RFCs use. I will deal - but given we are Europeans... :) > 7. Section 8.1, the actions are formatting inconsistently. In > one case, as a paragraph and the other as a list. Done 8. Page 19, replace "algorithms i.e." with "algorithms, i.e.". Done > 9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent. Done > 10. Page 23, Run-on sentence beginning "Manual configuration...". Done > 11. There some instances where the opening clause for a sentence > is preceded with a comma and some where it is not. I prefer the > former. For example, section 4.2 appears to be written in a different > style with missing punctuation. > > I think I got them, but RFC Editor will get this Thanks for the review Stewart > Thanks, > Acee > > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html