Hi Qin,
thank you for kind consideration of my comments. Glad we’re agree on most so we
can clip them and concentrate on few remaining.
Please find my notes in-line and tagged GIM>> below.
Regards,
Greg
From: Qin Wu [mailto:[email protected]]
Sent: Monday, June 30, 2014 12:39 AM
To: [email protected]; [email protected]
Cc: Gregory Mirsky
Subject: RE: Strong Technology Dependency
[…]
Greg>Echo(Ping) does not provide CV as IP is connectionless and has no
definition of Misconnection defect.
[Qin]:Not sure about this. RFC7276 said LSP Ping is used for end-to-end
Connectivity Verification between two LERs.
Therefore I think IP Ping can also provide CV, what am I missing?
GIM>> I think of CV as proactive OAM mechanism that detects particular defect
and has clear definition of defect entry and defect exit criteria. LSP Ping
verifies consistency between control and data plane. That, IMO, is close to CV
but without definition of defect state is not the CV.
[...]
Greg>Not, BFD and BFD Echo do not provide CV for the same reason as for ICMP –
do definition of Misconnection defect. Besides, BFD Echo doesn’t work for
multi-hop case but only for single hop.
[Qin]: Not sure about this. RFC7276 said SP Ping is used for end-to-end
Connectivity Verification between two LERs.
Since BFD Echo is similar to LSP Ping, I think BFD Echo also can provide CV.
GIM>> Unlike LSP Ping BFD does not verify consistency of data plane vs. control
plane. BFD could and may be used as CV if it would be accompanied with
definition of Misconnection Defect, its Entry and Exit conditions and how the
defect gets signaled, i.e. through Diag field. So far applicability of the code
for Mis-connectivity defect, defined in RFC 6428, not been discussed in IP or
IP/MPLS networks but only in MPLS-TP domains.
[…]
Greg>MPLS-TP provides CC through use of BFD
Greg>MPLS-TP provides CV through use of BFD and extension to provide Source ID.
[Qin]: Besides using BFD, is there any other way to provide CC or CV?
GIM>> I think of CV as optional mode that may be realized with the help of CC
mechanism. Thus, in addition to Loss of Continuity defect, there must be
definition of Mis-connection defect. It could be BFD, CCM/ETH-CC or else
(though not sure whether there’s anything “else”).
Regards,
Greg
发件人: OPSAWG [mailto:[email protected]] 代表 Qin Wu
发送时间: 2014年6月25日 16:06
收件人: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
抄送: [email protected]<mailto:[email protected]>
主题: [OPSAWG] Strong Technology Dependency
Hi, Mohamed:
Thanks for details review to problem statement draft
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-00
and update I sent to you.
Regarding strong technology dependency issue,
Section 4.2 gives an address scheme example to explain why the existing OAM
mechanism has strong
Technology as follows:
“
Addressing scheme is a good example for an issue
that has a high price for being non-generic. Ping of IPv4 and IPv6
looks different in the addressing scheme as well in the ICMP
indication field, but they have the same OAM functionalities.
”
You asked to clarify the exact point of this paragraph.
I think what this paragraph said is
For IP ping, IPv4 Ping protocol [RFC792] and IPv6 ping protocol [RFC4443] use
different IP technology but share the same OAM function.
But I agree with you address scheme is not a typical example for strong
technology dependency.
I think the typical example is ICMP, LSP Ping and MPLS-TP OAM are using
different network technology but share the same OAM
functionality, i.e., Path Discovery. Another example is ICMP,BFD,LSP Ping and
MPLS-TP OAM are using different network technology but share
the same functionality, i.e., continuity check.
The following figure shows common OAM functionalities shared by various
existing OAM protocols.
|--------+-----------+--------------+--------------+------------+
| |Continuity | Connectivity| Path | Performance|
| | Check | Verification| Discovery | Monitoring |
+--------+-----------+--------------+--------------+------------+
| | | | | |
| ICMP | | Echo(Ping) | Traceroute | |
| | | | | |
+--------+-----------+--------------+--------------+------------+
| | | | | |
| BFD | BFD | BFD Echo | | |
| | Control | | | |
+--------+-----------+--------------+--------------+------------+
| LSP | | | | - Delay |
| Ping | | Ping | Traceroute | - Packet |
| | | | | Loss |
+--------+-----------+--------------+--------------+------------+
| | | | | |
| IPPM | | | | |
| | | | | |
|--------+-----------+--------------+--------------+------------+
| MPLS-TP| | | | |
| OAM | CC | CV | Traceroute | -Delay |
| | | | | -Packet |
| | | | | Loss |
+--------+-----------+--------------+--------------+------------+
Hope this clarifies.
Regards!
-Qin
发件人: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
发送时间: 2014年6月24日 22:13
收件人: Qin Wu
主题: RE: Unified oam BOF proposal request in IETF 90
Hi Qin,
Please find attached a first set of comments.
Cheers,
Med
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
