Hi Mirja, Thanks for the question, please see inline.
Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On May 3, 2016, at 05:46, Mirja Kuehlewind <[email protected]> wrote: > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This part is unclear to me: > "It is, however, possible for an > SBFDInitiator to carefully set "your discriminator" and TTL fields to > perform a continuity test towards a target, but to a transit network > node and not to the target itself. [...] > This also requires S-BFD control packets not be dropped by the > responder node due to TTL expiry. Thus implementations on the > responder MUST allow received S-BFD control packets taking TTL expiry > exception path to reach corresponding reflector BFD session." > > You basically perform a traceroute with (S-)BFD, right? Almost. We are performing an S-BFD-aware traceroute with S-BFD. > Why do you need > the last sentence? Wouldn't it be okay, if the packet get dropped by the > responder, to simply re-send with a higher TTL? > No. Basically we need the router to process the pocket as S-BFD (i.e. Intercept it for processing on TTL expiry). Otherwise, we would get an ICMP back while what we are after is an S-BFD back. Thanks! Carlos. >
