Re: [L2tpext] ppp draft issues - ff03 or no ff03

[Carlos Pignataro <[e-mail]>]

On 6/20/2007 4:48 PM, Ignacio Goyret said the following:
> Hi all,
> Another detail on the PPP draft for L2TPv3:
> 
> In section 4.3, the current draft requires each end to remove
> the ff03 (ACF) from the PPP packet before sending it through
> the tunnel; with the receiving end restoring (or inserting)
> the ff03 if needed downstream from it.
> 
> This text creates a problem for a LAC interfacing to a link
> that can use ACFC: unless the LAC snoops the LCP negotiation,
> it has no way to know whether ACFC is in effect and so it would
> not know for certain whether the ff03 should be inserted on
> packets going to the client.
> 
> Since snooping LCP is a dangerous business for a number of
> reasons, that should be off our list of options.
> 
> We have a few alternatives:
> 1) Neither end adds nor removes any bytes.
>    In other words, the packet on the tunnel is identical
>    to the packet on the wire to/from the client.
> 
>    The disadvantage here is that the LNS needs to know the
>    requirements of the link from the LAC (eg, if it is ATM,
>    the ACF field should be eliminated, etc).
>    I do not advocate this alternative.
> 
> 2) ACF MUST be eliminated before sending the packet on the
>    tunnel.
> 
>    In this case, the LAC needs to know whether the ACF must be
>    reinserted on output to the client. For this, we should
>    require implementation of RFC 3437 so the LAC can learn
>    the negotiated ACFC setting.
> 
>    Note that for robustness reasons, the receiver SHOULD be
>    able to handle incoming packets that have ff03 or not.
> 
>    This alternative seems more reasonable to me.

I agree with this alternative. This would require removing ACF (as
currently described in the document). The new text would need to say
that if the LNS supports ACFC, it MUST support Section 2.3 of rfc3437.
In addition, I think that the 4th paragraph of Section 4.3 of the PPP
draft needs to swap MUST <-> SHOULD, such that "SHOULD NOT" include ACF
on encapsulation, and "MUST" allow incoming packets with ACF on reception.

List, any other thoughts?

Thanks,

--Carlos (as editor).

> 
> 
> Note that RFC2661 did not mandate this ff03 elimination, so
> keeping this would be a departure from that RFC and a fairly
> obscure interop difference.
> 
> Opinions, please?
> 
> -Ignacio
> 
> PS: This draft expired recently but a new one is in the works.
> In the meantime, you can look here for the last version:
> http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-05
> 
> 
> 
> _______________________________________________
> L2tpext mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems


_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext