Subject: [L2tpext] draft-ietf-l2tpext-circuit-status-extensions-02.txt

From: Ignacio Goyret <[email-masked]>
Date: Fri, 13 Mar 2009 10:16:51 -0700

Hi,
A few comments on the circuit-extensions draft:

1) Since this draft adds some new bits, including an
   "Standby" bit that affects the data plane, would it
   make sense to add a bit to request a remote loop?
   (ie, ask the remote LCCE to send all packets received
   over the L2TP tunnel back to the sender LCCE)

   Mmm, come to think of it, this may be the wrong AVP
   for that kind of function.

2) Besides updating RFC3931, this draft is also implicitly
   updating 4591, as well as 4349, 4454 and 4719.

   The new bits and the effect on the N-bit are applicable
   to all protocols, right?

   If so, RFC4591 should probably be moved to the normative
   section of the references, and the others should be added.

That's all I have.

I'd like to start a WGLC on this document but,
with IETF74 so close, we should wait until after
the meeting.

In the meantime, please, take the time to read this
document: it is an easy read.

Cheers,
-Ignacio

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 13 Mar 2009 21:51:39 -0400

Hi Ignacio,

Many thanks for the comments, please see inline.

>    for that kind of function.

This is a very interesting suggestion; I tend yo agree with your
conclusion though.

I think that such loopback capability likely requires more fields than a
single bit (e.g., type of loop, direction, all dataplane packets versus
only some packets, some locking mechanism, etc.). It would likely need
its own AVP and separate definition.

>    updating 4591, as well as 4349, 4454 and 4719.

This is a great point. I checked and I don't think there's other RFC
specifying Circuit Status AVP and N-bit usage, in addition to those
four. I'm not sure how implicit or explicit the update is (or needs to
be), see below;

>    The new bits and the effect on the N-bit are applicable

Yes.

>    section of the references, and the others should be added.

OK. RFC4591 is currently Informative because it was only included to
show that, while RFC3931 says that the N bit is for FRoL2TPv3, RFC4591
uses it exactly the saw way as the other protocols.

I agree, we'll add Normative references to RFC4349, RFC4454 and RFC4719,
and move RFC4591 as Normative. We'll add a paragraph with citations to
these 4 explaining why they are there.

Q: How do you suggest we handle the "Updates:" header of the document?
Right now it reads:
	Updates: 3931 (if approved)
Should the other 4 RFCs be added here?

> with IETF74 so close, we should wait until after

Maybe it's a feature that it's so close to IETF74, to maximize the
review and comment. You could start a WGLC extending it by 1 or 2
additional weeks? Or otherwise, we can publish a new revision with these
changes when submission re-opens and WGLC it at that time; what do you
prefer?

> document: it is an easy read.

Thanks !

-- Carlos.

> 
> Cheers,
> -Ignacio
> 
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext
>