Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

From: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 2 Jan 2013 11:28:27 -0500

Hi Lizhong,
Thanks for your review and comments and sorry for a late reply. Please, see inline.

Thanks,
Nabil

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 14, 2012 8:34 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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>

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>

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

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?

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>

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.

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>

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>

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.

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>

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.

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>

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>

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>

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>

Regards
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 3 Jan 2013 14:28:34 +0800

Hi Nabil,
See inline for the reply. Thank you, and happy new year.

Regards
Lizhong

[email-masked] wrote 2013/01/03 00:28:27:

> From: Lizhong Jin <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <draft-
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> 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. 
> 
> 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:
> <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.
> 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.

> <NB> Please, see above answer. The same applies here.
[Lizhong] OK.
> [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.
> [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface 
> parameters sub-TLV", right? Suggest to align with terminology in 
RFC5085.
> TLV when using FEC 129 and the interface parameter sub-TLV when 
[Lizhong] good, thanks.

> [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.
> [Lizhong] RFC2119 words should be used in this section, e.g, "must" 
[Lizhong] thanks.
> [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.
> <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.
> <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.

> [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.
> <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.
[Lizhong] that's good, thanks.

> [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.
> PE1 MUST clear the FDI to PE2, if applicable.
[Lizhong] that's good, thanks.

> [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
[Lizhong] thank you.

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Fri, 4 Jan 2013 13:12:26 -0500

Hi,
Thanks. Happy new year to you as well.

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

Thanks,
Nabil

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 3, 2013 1:28 AM
To: "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

Hi Nabil,

Regards
Lizhong

[email-masked]<mailto:[email-masked]> wrote 2013/01/03 00:28:27:

> Cc: "[email-masked]<mailto:[email-masked]>" <draft-
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>
[Lizhong] OK.
> detected on the PW. Please, look at the paragraph before last in that section.

[Lizhong] OK.
> 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.
> parameters sub-TLV", right? Suggest to align with terminology in RFC5085.
>
[Lizhong] good, thanks.

> that is OK with you, I will do that and send as part of the updated document.
[Lizhong] thanks.
[Lizhong] good, thanks.
[Lizhong] that's good.

> exit of PW receive defect should be described, not enter of PW receive defect.

> of PW transmit defect be signaled to remote PE? I do not see such text here.

> 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?
[Lizhong] thank you.

---

From: Lizhong Jin<[email-masked]>
Date: Sat, 5 Jan 2013 09:35:34 +0800

> 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

> To: "Bitar, Nabil N" <[email-masked]>
> [email-masked]>, "[email-masked]" 
<
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> [Lizhong] yes. I am not proposing to add PW label withdrawal, but 
> want to know why it is not considered here.
> > 
> > 
RFC5085.
here.
> supported on the PE, which one should be applied? Is there any 
> priority among the three?
> > 
> > 
> > Nits: