Hi Weiguo
This is a good question.
If the intermediate device is not aware of the nvo3 OAM few thing will happen
1. When TTL expiry happens the device is supposed to generate ICMP message
TTL expiery, the originator can interpret
2. Assume #1 did not happen
a. In that case originator device , upon retransmission expiry would
increment the TTL and re-transmit.
b. In the display you would see a * - indicating device timedout or unknown
c. Output will look like something below
i. [ip address of TTL=1]
ii. * [non compatible
device]
iii. [ip address of TTL=2]
iv. And so on.
3. It is possible the path is broken at (ii). So the drawback is
originator has to try max-TTL to figure out path is indeed broken at (ii).
Which is a slightly a longer time and a price to pay for mixed network. BTW:
this is the exact same result today with IP traceroute and one of the devices
disable ICMP response due to security or other reasons.
I will update the draft with backwards compatibility section to include this
and other caveats in a mixed mode networks.
From: nvo3 [mailto:[email protected]] On Behalf Of Haoweiguo
Sent: Friday, June 13, 2014 2:07 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email protected]
Subject: [nvo3] One question about draft draft-tissa-nvo3-oam-fm-00
Hi Tissa,
In section 10.1 in your draft of draft-tissa-nvo3-oam-fm-00, theory of
operation is discribed, you say that originator device should specify the TTL
of the transport header as 1 for the first request. Because transit devices in
underlying network normally don't support the OAM function, if you specify TTL
as 1, the first transit device will drop it, remote MEP or MIP won't receive
the message if two or more hops exists between ingress and egress MEPs, so the
response timer will expire on originator device.
How can you ensure the OAM state machine on originator runs correctly in this
scenario?
Thanks
weiguo
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
