Subject: [mpls-tp] Request comments about draft-zhang-mpls-tp-pw-oam-config-02

From: [email-masked]
Date: Thu, 29 Jul 2010 19:43:42 +0800

Hi MPLS-TPers and PWE3ers

We have presented the MPLS-TP PW OAM configuration in the PWE3 meetings, 
the link as follows:

http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-02

MPLS-TP extended PW proactive OAM functions to meet the transport 
requirements, such as CC-CV-RDI/PM loss/PM delay/FMS
These OAM functions need OAM capability negotiation and configuration if 
control plane is used.

Any comments are welcome

B.R.

The authors

:)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 29 Jul 2010 09:08:07 -0400

I have a comment and some questions about this draft.

    First, can you explain why VCCV/BFD itself cannot be used to signal
capabilities in its current form?  It seems that the point of your draft is
only to do this.   
    
    Also, can you explain why RFC4447¹s details of how to signal PW status
are inadequate?  

    Finally, I have a general concern about ³configuration² via signaling
protocols, which seems to be the point of this draft. This is likely
something more for the Ops AD to chime in on, but as I mentioned before,
there is more to configuration of devices than simply signaling those
features. The reasons get into why SNMP or NetConf (or other database
configuration protocols) are quite complex: this is not a simple problem
without its corner cases. The other issue is that by allowing configuration
of these features (true configuration) needs to be done in an operationally
consistent manner; not ad hoc which seems to be occurring with this draft
and the others in CCAMP for GMPLS configuration.  For instance, what happens
in the case when say a far-end operator configures some capabilities as
specified in your draft and commits that change, whilst someone at the local
end configures the same thing?  There are situations such as this one that
are not outlined in your draft, which are considered fairly normal under
operational conditions.

    --Tom

On 7/29/10 7:43 AM, "[email-masked]" <[email-masked]> wrote:

> We have presented the MPLS-TP PW OAM configuration in the PWE3 meetings, the
> link as follows: 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Thu, 29 Jul 2010 22:59:27 +0800

Hi Tom

Thanks for your useful comments

see in line

"Thomas D. Nadeau" <[email-masked]> 
2010-07-29 21:08

收件人
<[email-masked]>, pwe3 <[email-masked]>, <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re: [PWE3] Request comments about draft-zhang-mpls-tp-pw-oam-config-02

    First, can you explain why VCCV/BFD itself cannot be used to signal 
capabilities in its current form?  It seems that the point of your draft 
is only to do this. 
Fei: not exactly, VCCV can realize the capability negotiation of BFD 
currently. But now MPLS-TP extend other OAM functions such as PM loss/deay 
and FMS. These OAM functions needs to be negotiated between the two 
endpoints also. 
Another thing is that VCCV BFD only has CC function,  not inlcuding CV 
function, and the corresponding extensions is described in CC-CV-RDI, the 
configuration and capability negotiation SHOULD be executed also.
 
    Also, can you explain why RFC4447’s details of how to signal PW 
status are inadequate? 
Fei: in contrast, the signaling of PW status in RFC4447 is adequate. As I 
described in the document and presentaion materials, the current MPLS OAM 
schemes SHOULD not be changed. What needs to be added are the OAM 
functions extended by MPLS-TP.

    Finally, I have a general concern about “configuration” via 
signaling protocols, which seems to be the point of this draft. This is 
likely something more for the Ops AD to chime in on, but as I mentioned 
before, there is more to configuration of devices than simply signaling 
those features. The reasons get into why SNMP or NetConf (or other 
database configuration protocols) are quite complex: this is not a simple 
problem without its corner cases. The other issue is that by allowing 
configuration of these features (true configuration) needs to be done in 
an operationally consistent manner; not ad hoc which seems to be occurring 
with this draft and the others in CCAMP for GMPLS configuration. 
Fei: as I understand,  the configuation of related OAM parameters is 
executed by NMS if control plane does not exist, but if control plane 
exits, it can be used to replace the NMS to do some parts of configuration 
work. 
 For instance, what happens in the case when say a far-end operator 
configures some capabilities as specified in your draft and commits that 
change, whilst someone at the local end configures the same thing? There 
are situations such as this one that are not outlined in your draft, which 
are considered fairly normal under operational conditions.
 Fei:What I outlined in the draft is that  the corresponing parameters 
configured in one end are signalled to the other end which configure the 
same parameters.  I think it is the most situation, maybe I am wrong. 
What other situations are not covered in this draft? Can you describe them 
more clearly, so that we can revised the document.

    --Tom

Any comments are welcome 

B.R. 

The authors 

:)