Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?

From: [email-masked]
Date: Thu, 9 Nov 2006 23:26:50 +0000

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become a
working group ID.

Please indicate to the list whether or not you support this draft becoming
a working group ID.

Regards,

Matthew

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

---

From: "Haag, T" <[email-masked]>
Date: Fri, 10 Nov 2006 01:28:47 +0100

All,

I will support becoming ANCP protocol draft (draft-wadhwa-gsmp-l2control-configuration-02.txt) a working group ID.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Freitag, 10. November 2006 00:27
An: [email-masked]
Betreff: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the should become.

Regards,

Matthew

---

From: "Derek Harkness" <[email-masked]>
Date: Mon, 13 Nov 2006 14:44:41 -0000

> Please indicate to the list whether or not you support this draft
becoming a working group ID.

I support this draft becoming a working group ID

D.

+=============================+
Derek Harkness
Systems Engineer
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: [email-masked] [mailto:[email-masked]] 
Sent: 10 November 2006 00:27
To: [email-masked]
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew

---

From: [email-masked]
Date: Mon, 13 Nov 2006 16:10:48 +0100

I support this draft becoming a WG ID.

Regards,
Sven

---

From: [email-masked]
Date: Mon, 13 Nov 2006 17:42:18 +0100

Hi, I have some comments on
draft-wadhwa-gsmp-l2control-configuration-02.txt:

(1) Introduction says that the document extends GSMPv3.  This is not
really true because it is actually defining GSMPv3.1 and not just
extending GSMPv3.  This is an important difference since the header
format from v3 to v3.1 is changed.  I have not gone through all the
differences from RFC3292 to the original draft of Avri Doria that was
supposed to update RFC3292 because if that draft does not exist anymore,
the difference should be documented in this draft.  Will the draft of
Avri not be continued anymore?

(2) Section 3 and most part of section 4 are duplicate from the
framework document.  Once it was said to limit this draft to just the
protocol but when looking to the diffs of version 01 and version 02 of
this draft, these changes are not made.  According to me it would be
much better to remove most of it, in particular for use case 2 (line
config) and use case 4 (multicast), since the draft is not making any
protocol extensions for these use cases.  If it is kept, we will have to
check for the consistency, at the least this doc is using the old
terminology.

(3) Section 4.3.2. When PPP is up, the BRAS configs the DSLAM with for
instance a new DSL profile (in figure 4 it is even made explicit that it
is a new profile).  This will cause the line to resync and the PPP will
go down and come up again, but then the scenario repeats itself.  This
will cause a never ending loop, or at least 2 times the PPP to be set
up.  Is the config supposed to be maintained after a resync and after a
reboot? Since the config data is associated with the PPP session, the
config should be deleted when the PPP session disappears but with this
we are going to get nowhere.  The text and message flows should be
further completed with a second cycle of DSL loss, DSL signal, Port UP,
PPP/DHCP session, AAA, and also step 5 again (line config).  In this
case the DSLAM sees that the profiles matches and does not do anything
more.  This to show the complete scenario.

This also relates somehow to the comment from Kim Hyldgaard earlier: is
a down port the same as a non existing port?  The BRAS can configure the
port when it is created (but still down) such that the DSL line syncs
from the first time with the correct profile.  In which state is the
DSLAM supposed to remove the configured state by the BRAS?  Not in case
it goes from Up to Down or from Down to Up, because then the above
scenario is in an endless loop.  But then what about the IDLE and SILENT
states?

But since this is use case 2 (line config) for which the draft has no
protocol extensions, it looks better to me to remove at least this from
the draft, and it has to be cleared out in the drafts describing
particular extensions.  Might it be possible that some configs have to
be kept after a resync while others not?  There is also no method to go
to the default state again: suppose I remove my PPP session and then
authenticate with another ISP, then clearly the previous state has to be
removed and fall back to default.  Suppose that ISP1 wants to configure
profile 1 and ISP2 does not specify a profile, is the DSL line then
using profile 1 while authenticated with ISP2, or should the DSLAM then
use a default profile that it expects to be good and stable (e.g., large
maximum bandwidth, large noise margin, ...)?  If the PPP session
disappears, the BRAS should "clean up" the port back to default (the PPP
session is gone, so also the config from the Radius server), but then we
are again in the never ending loop in case of DSL profile configuration....

Another issue is how the BRAS knows the configured profile or any other
configured data.  Because according to section 5.4.3, unknown TLVs are
silently ignored.  So this triggers 2 questions:

- if one TLV can be executed, but a second TLV not for some reason, is
the first TLV executed, i.e. is this one transaction, or 2 transactions?
  The draft seems to suggest that it is 1 transaction.

- if one TLV can be executed, but the second TLV is unknown and ignored,
is then the first TLV executed?  Here the draft is not clear: what does
ignoring the unknown TLV means?

Would it not be better that TLVs are executed if possible, one by one,
and then the response is sent to the BRAS one by one, i.e., it is not 1
failure or success for the whole message, but rather a failure/success
per TLV.

(4) The bulk message is a new message and apparently also a single
transaction.  What does this mean?  All messages included must succeed
or no message at all is executed?  The text seems to suggest this in the
second paragraph and also last paragraph when describing the response to
the bulk message.  Would it not be better that the bulk message itself
has no response, but that the individual messages have a response, which
might be (but not necessarily) grouped again in a bulk message (possibly
with other new messages).

(5) section 5.4.2 contains a wrong reference to [4] which should be
section 5.4.2.1

(6) The error codes in section 5.4.4 are confusing.  Suppose the DSLAM
have multiple reasons for why the test fails, e.g., the test time out
(error 0x501) while the loop is in show time (error 0x503)? or since a
multiple loopbacks are sent, suppose some loopbacks fail because the
line is down (idle/silent), some loopback fails because the line is
training (error 0x506), and then there are some successful loopbacks.

What should be the value of the result field in this case? And what
should be the error code? I would expect that the result is only
successful if all loopbacks are successful, but you can also say for
instance that if when a predefined number is successful, the test is
successful.  But then there is still the problem with the error codes
(and it is a SHOULD requirement, so better to define it more precisely).
  Since the training state is a rather short state, it is likely that
there is no single state of the line during the whole loopback test.
Would it therefore not be better to remove at least the "training"
state?  It also does not give much information: the line is down, and
that is all what matters.

What does "DSL line integrity error" mean?  Can this be defined more
accurately?  This looks something that can change every second so just
like with the training state, it makes no sense to have such an error
code.  If you request for 5 loopbacks, and 3 are successfull and 2 fail,
you know the line has some problems (bit errors, ...) so this looks
redundant information that can create confusion.

Also definitions for idle and silent has to be added because it is not
clear from the draft what the difference is.

hope these comments help.  If all included in the next version, then I
will be happy to see it as a working group document!

regards,
Stefaan

---

From: "Peter Arberg" <[email-masked]>
Date: Mon, 13 Nov 2006 21:48:27 -0800

I support this as a WG draft. I take it we can keep expanding
the content as long as the WG agree to suggested additions
or deletions ?

cheers,
Peter

> Sent: 9. november 2006 15:27
> To: [email-masked]
> Subject: [ANCP] 
> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
>

---

From: "Kim Hyldgaard \(ST/LMD\)" <[email-masked]>
Date: Tue, 14 Nov 2006 09:20:43 +0100

Hi,

I support this draft becomming a WG ID.

- I have the same assumption as stated by Peter
below: That we can expand the content as long as
the WG agree to suggested additions or deletions.

Br
Kim

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]] 
Sent: 14. november 2006 06:48
To: [email-masked]; [email-masked]
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

I support this as a WG draft. I take it we can keep expanding the
content as long as the WG agree to suggested additions or deletions ?

cheers,
Peter

> During the ANCP meeting in San Diego we asked whether the ANCP 
> protocol draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) 
> should become a working group ID.
>

---

From: "Voigt, Norbert" <[email-masked]>
Date: Tue, 14 Nov 2006 14:08:44 +0100

Norbert 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Freitag, 10. November 2006 00:27
To: [email-masked]
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

Regards,

Matthew

---

From: Ferry Sutanto <[email-masked]>
Date: Wed, 15 Nov 2006 11:32:25 -0800 (PST)

Hi guys,

While we are in this subject.

For the case where BRAS will aggregate/control many (order of thousands) 
AN, ANCP protocol need a way for BRAS to be able to shape AN's keepalive 
value to better utilize BRAS's cpu and memory usage, this will prevent 
storm of AN's keepalive coming to BRAS at the same second. I was thinking 
at the beginning of SYN stage of adjacency protocol, BRAS can send SYN 
with new TLV to shape AN's keepalive.

Thanks,

Ferry

---

From: [email-masked]
Date: Thu, 16 Nov 2006 10:53:17 +0000

Kim, Peter,

Yes, changes can still be made to the draft. It is not cast in stone just
because it is a WG ID.

Best regards,

Matthew

             "Kim Hyldgaard                                                
             \(ST/LMD\)"                                                   
             <kim.hyldgaard@er                                          To 
             icsson.com>               Matthew BOCCI/GB/ALCATEL@ALCATEL,   
                                       <[email-masked]>                     
             14/11/2006 08:20                                           cc 
                                                                           
                                                                   Subject 
                                       RE: [ANCP]                          
                                       draft-wadhwa-gsmp-l2control-configu 
                                       ration-02.txt to WG ID?             

                                                                           

Hi,

Br
Kim

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]]
Sent: 14. november 2006 06:48
To: [email-masked]; [email-masked]
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

cheers,
Peter