Subject: [ANCP] Why does ANCP use GSMP?

From: Lloyd Wood <[email-masked]>
Date: Wed, 20 Jun 2007 20:30:41 +0100

How does ANCP work? What is the plumbing, and how are messages communicated?

I understand that ANCP depends on GSMPv3, though you have to dig pretty deep into the protocol specification to discover this fact. (I find it interesting that the framework document skips nicely over the whole GSMP dependency, and that the only reason given in the charter for using GSMP is that early implementations in this space use it.)

Current specification of ANCP seems to be all high-level stuff; how the plumbing actually works is glossed over with a handwave, and there's a long trail of document dependencies. Though ANCP depends on GSMP, it's stated in
http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt
(which, btw, is filled with "smart quotes" _ I see a lot of questionmarks, which is appropriate.) that only TCP is used for ANCP. A detailed example of a message exchange or two would be useful to see.

I don't see how ANCP can both be an extension to an existing protocol, and yet also try to restrict how that existing protocol is used. This is called 'having your cake and eating it'. Given that GSMP was ATM-only before version 3, and that ANCP is only using version 3 and only running IP, while ATM remains the core of GSMP -- why is ANCP using GSMP at all? It seems like an unnatural fit, rather than a logical extension of GSMP. (And overloading TCP's RST/ACK for ANCP's purposes when there's a capability mismatch - seriously? Communicating how there's a mismatch would be more useful. If that's the only way you can communicate this in GSMP, GSMP would be the wrong thing to use.)

The framework document discusses ATM a _lot_, which makes ANCP's TCP-only protocol restriction on GSMP more curious. Is GSMP the right choice to base ANCP on? Is TCP even the right choice for small messages, or is it overkill?

If ANCP is leveraging the GSMP framework, ANCP is leveraging everything that GSMP comes with, including over-ATM, over Ethernet, over-TCP. Is that baggage desirable?

(I'm playing devil's advocate here, as requested by Woj in his capacity as wg chair. We have a problem I described previously that we thought ANCP could be adapted to be a solution for - but adapting the entire complexity of GSMP to solve a point problem strikes me as increasingly wrong even for ANCP itself, given how ANCP is using GSMP. So the solution to our problem would be an extension of ANCP, which is an extension of GSMP, but only in some preferred ways?)

Why is GSMP use a good idea for ANCP?

thanks,

L.

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "Derek Harkness" <[email-masked]>
Date: Thu, 21 Jun 2007 18:28:11 +0100

Hi,
	Some background you are maybe missing is that there was a long
discussion in the DSL Forum which described the problem scenario / use
cases in WT-147 and then examined a number of protocols ( DSLF tries not
to invent new protocols if a suitable one is available ) and found GSMP
the most suitable basis for doing so - if you dont have access to the
DSLF WT-147 documents I'm sure we can get someone to unicast the
relevant docs to you. 

My purely personal take/paraphrase is that GSMP was developed for a L3
aware thing to control and be informed of the e.g. port status of a l2
switching entity. The NAS is a l3 aware thing which wants to control and
be informed of the e.g. port status of an access node, which is
primarily a l2 switching entity. ( My terminology is deliberately loose
here as I don't wish to get into a discussion on l3 awareness processing
in access nodes again). End personal take. 

The DSL Forum then handed the work to the IETF to standardise the
protocol, which is when the ANCP WG was founded. 

Regarding your concern that we discuss ATM a lot in the framework but
use only the IP/TCP transport of ANCP, I see these as 2 different
things.

ANCP is part of the control plane between NAS and AN, and all ANs and
NAS use IP as the basis of their control plane ( be it telnet, ssh, snmp
) - at least all I have ever come across. Therefore transporting ANCP
over IP between NAS and AN seems the only sensible option and therefore
the other options ( GSMP direct on ATM ) seem no longer relevant. 

The ATM referred to in the framework is on the local loop in the case of
certain DSL technologies (e.g. ADSL, ADSL2+ ) and is some cases as the
aggregation network between AN and NAS.

Given that there are over 100 Mio such DSL lines with ATM on the local
loop, then a NAS knowing about DSL ports an AN with ATM on the local
loop and knowing the BW of that local loop to adjust NAS shapers,
remotely controlling OAM on that local loop is a very very useful thing.

For this reason I see nothing disturbing in transporting ANCP over IP to
the AN but using ANCP to convey information about an ATM port of that
AN. To repeat myself, I don't see anybody saying that telnet/ssh/SNMP
for managing a ADSL AN should be transported over ATM without IP.

Maybe this answers why I'm not sure why you "don't see how ANCP can both
be an extension to an existing protocol, and yet also try to restrict
how that existing protocol is used."  

	Hopefully that helps,

		Derek.

+=============================+
Derek Harkness
Juniper Networks 
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: [email-masked]
+=============================+ 

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: 20 June 2007 21:31
To: [email-masked]
Cc: [email-masked]
Subject: [ANCP] Why does ANCP use GSMP?

How does ANCP work? What is the plumbing, and how are messages
communicated?

I understand that ANCP depends on GSMPv3, though you have to dig pretty
deep into the protocol specification to discover this fact. (I find it
interesting that the framework document skips nicely over the whole GSMP
dependency, and that the only reason given in the charter for using GSMP
is that early implementations in this space use it.)

Current specification of ANCP seems to be all high-level stuff; how the
plumbing actually works is glossed over with a handwave, and there's a
long trail of document dependencies. Though ANCP depends on GSMP, it's
stated in
http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt
(which, btw, is filled with "smart quotes" _ I see a lot of
questionmarks, which is appropriate.) that only TCP is used for ANCP. A
detailed example of a message exchange or two would be useful to see.

I don't see how ANCP can both be an extension to an existing protocol,
and yet also try to restrict how that existing protocol is used. This is
called 'having your cake and eating it'. Given that GSMP was ATM-only
before version 3, and that ANCP is only using version 3 and only running
IP, while ATM remains the core of GSMP -- why is ANCP using GSMP at all?
It seems like an unnatural fit, rather than a logical extension of GSMP.
(And overloading TCP's RST/ACK for ANCP's purposes when there's a
capability mismatch - seriously? Communicating how there's a mismatch
would be more useful. If that's the only way you can communicate this in
GSMP, GSMP would be the wrong thing to use.)

The framework document discusses ATM a _lot_, which makes ANCP's
TCP-only protocol restriction on GSMP more curious. Is GSMP the right
choice to base ANCP on? Is TCP even the right choice for small messages,
or is it overkill?

If ANCP is leveraging the GSMP framework, ANCP is leveraging everything
that GSMP comes with, including over-ATM, over Ethernet, over-TCP. Is
that baggage desirable?

(I'm playing devil's advocate here, as requested by Woj in his capacity
as wg chair. We have a problem I described previously that we thought
ANCP could be adapted to be a solution for - but adapting the entire
complexity of GSMP to solve a point problem strikes me as increasingly
wrong even for ANCP itself, given how ANCP is using GSMP. So the
solution to our problem would be an extension of ANCP, which is an
extension of GSMP, but only in some preferred ways?)

thanks,

L.