Subject: Re: [ANCP] Partition ID

From: <[email-masked]>
Date: Fri, 2 Jan 2009 17:56:03 +0100

Using partitioning is not a real use case but an operational extension in operation ANCP with multiple AN and BRAS devices. In practice a single edge network does not consist of a single BRAS. Furthermore a single BRAS location may have multiple BRAS devices. I like to point out the operational background and the partitioning ID negotiation.

Operational background:
>From an nework developing point of view a BRAS may be fully loaded by continuous increasing number of configured DSL ports. From traffic engineering point of view the BRAS can not handle additional new ports. In order not to reconfigure the whole network the AN opens a new partition and the next BRAS device (same location!) terminates this new partition coming from the same AN taking the new traffic.

Partition ID negotiation:
3rd of November 2008 on the mailing list the use of partiton ID was discussed too. The reason was the missmatch of an partiton ID if a BRAS receives a message with a partition ID the BRAS have not known before. In order not to tear down the connection the BRAS should learn this partiton ID.
This option was agreed to be described in the protocol draft. 

So I think the reason for using of the partiton ID field is described independent on a particular use case because this feature is a fundamental operational configuration which is used by already defined use cases and has no need to be a use case itself. Also backward compatibility is an issue here to be studied carefully because of the the impact on using partition ID filed for new functionality.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Wojciech Dec (wdec)
Gesendet: Mittwoch, 31. Dezember 2008 10:31
An: Shridhar Rao (shrirao); [email-masked]
Betreff: Re: [ANCP] Partition ID

You raise a very good point. The partition "concept" is/was derived from
GSMP where presumably a single controller could be managing multiple
partitions on a single client. In the current set of ANCP use-cases this
does not seem to be required and the partition-id field may be yet
another field that could be marked as "obsolete" or simply ignored by
the NAS. Could anyone in the WG indicate whether they see a case where a
single NAS would be handling multiple partitioned ANCP sessions from a
single AN, and what would that case be?

Thanks,
Woj.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shridhar Rao (shrirao)
> Sent: 19 December 2008 11:48
> To: [email-masked]
> Subject: [ANCP] Partition ID
> 
> Hello,
> We like to understand the real use for Partition ID in case 
> of NAS. If AN wants to use Partition ID for dividing itself 
> into multiple logical partitions with each controlling 
> certain access ports on it, it can be done by some local 
> configuration on AN. Is there a real need for NAS to be aware of it? 
> 
> If Partition ID field has no use in NAS, it can be reused 
> instead as first byte of a 4 byte Transaction Id field (Tr ID 
> is now a 3 byte quantity starting at a odd byte location), 
> and NAS need not worry about partition ID at all eliminating 
> the need for exchange of adjacency messages for convergence 
> of Partition ID.
> 
> Thanks,
> Shridhara rao
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
> 
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Tina Tsou <[email-masked]>
Date: Sat, 03 Jan 2009 11:20:34 +0800

It makes sense from the point of view of operational configuratio.  
When does NAS get this partition ID from AN?

Tina

发自我的 iPod

在 2009-1-3，0:56，[email-masked] 写到：

> Using partitioning is not a real use case but an operational  
> extension in operation ANCP with multiple AN and BRAS devices. In  
> practice a single edge network does not consist of a single BRAS.  
> Furthermore a single BRAS location may have multiple BRAS devices. I  
> like to point out the operational background and the partitioning ID  
> negotiation.
>
> Operational background:
> From an nework developing point of view a BRAS may be fully loaded  
> by continuous increasing number of configured DSL ports. From  
> traffic engineering point of view the BRAS can not handle additional  
> new ports. In order not to reconfigure the whole network the AN  
> opens a new partition and the next BRAS device (same location!)  
> terminates this new partition coming from the same AN taking the new  
> traffic.
>
> 3rd of November 2008 on the mailing list the use of partiton ID was  
> discussed too. The reason was the missmatch of an partiton ID if a  
> BRAS receives a message with a partition ID the BRAS have not known  
> before. In order not to tear down the connection the BRAS should  
> learn this partiton ID.
> So I think the reason for using of the partiton ID field is  
> described independent on a particular use case because this feature  
> is a fundamental operational configuration which is used by already  
> defined use cases and has no need to be a use case itself. Also  
> backward compatibility is an issue here to be studied carefully  
> because of the the impact on using partition ID filed for new  
> functionality.
>
> Regards
> Thomas
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Sat, 3 Jan 2009 09:33:56 +0100

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 02 January 2009 17:56
> To: [email-masked]; Wojciech Dec (wdec)
> Cc: Shridhar Rao (shrirao)
> Subject: AW: [ANCP] Partition ID
> 
> extension in operation ANCP with multiple AN and BRAS 
> devices. In practice a single edge network does not consist 
> of a single BRAS. Furthermore a single BRAS location may have 
> multiple BRAS devices. I like to point out the operational 
> background and the partitioning ID negotiation.
> 
> Operational background:
> From an nework developing point of view a BRAS may be fully 
> loaded by continuous increasing number of configured DSL 
> ports. From traffic engineering point of view the BRAS can 
> not handle additional new ports. In order not to reconfigure 
> the whole network the AN opens a new partition and the next 
> BRAS device (same location!) terminates this new partition 
> coming from the same AN taking the new traffic.

You seem to be describing the case of *one* AN having two or more partitions each associated with a *different* BRAS/NAS ANCP controller through an ANCP adjacency. Is there any use for *one* such an AN with the same type of multi partition and multi-ANCP adjacency relationship with *a single* logical BRAS/NAS ANCP controller? What would that case be?

> 3rd of November 2008 on the mailing list the use of partiton 
> ID was discussed too. The reason was the missmatch of an 
> partiton ID if a BRAS receives a message with a partition ID 
> the BRAS have not known before. In order not to tear down the 
> connection the BRAS should learn this partiton ID.

As Shridhar indicated, the partition id appears to be of no consequence to the ANCP controller except if it is expected to handle multiple ANCP adjacencies from one AN. 

Regards,
Woj.

> described independent on a particular use case because this 
> feature is a fundamental operational configuration which is 
> used by already defined use cases and has no need to be a use 
> case itself. Also backward compatibility is an issue here to 
> be studied carefully because of the the impact on using 
> partition ID filed for new functionality.
> 
> Regards
> Thomas
> 
> You raise a very good point. The partition "concept" is/was 
> derived from GSMP where presumably a single controller could 
> be managing multiple partitions on a single client. In the 
> current set of ANCP use-cases this does not seem to be 
> required and the partition-id field may be yet another field 
> that could be marked as "obsolete" or simply ignored by the 
> NAS. Could anyone in the WG indicate whether they see a case 
> where a single NAS would be handling multiple partitioned 
> ANCP sessions from a single AN, and what would that case be?
> 
> Thanks,
> Woj.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Shridhar Rao (shrirao)
> of NAS. If 
> > AN wants to use Partition ID for dividing itself into 
> multiple logical 
> > partitions with each controlling certain access ports on 
> it, it can be 
> > done by some local configuration on AN. Is there a real 
> need for NAS 
> > to be aware of it?
> > 
> instead as 
> > first byte of a 4 byte Transaction Id field (Tr ID is now a 3 byte 
> > quantity starting at a odd byte location), and NAS need not worry 
> > about partition ID at all eliminating the need for exchange of 
> > adjacency messages for convergence of Partition ID.
> > 
> > Thanks,
> > Shridhara rao

---

From: Sanjay Wadhwa <[email-masked]>
Date: Sun, 4 Jan 2009 01:04:04 -0500

If each partition on an AN is always controlled via a different NAS (or same NAS but different peer IP address), then we can get away without NAS having to reflect the partition-ID in the ANCP messages, as partition-ID is implicit on the AN from peer IP address. A L3 or L2 wholesale service provided on the NAS (say via L2TP based backhaul to retail ISP's router OR via virtual routing domains on the NAS per retail-ISP) might seem like a driver for this on the surface...but then I don't believe these require partitioning on AN in the first place, and therefore not relevant to the discussion.

However, one can imagine a scenario where AN partitioning is based on a criterion other than the NAS (i.e. ANCP controller) controlling it. ....e.g. one might want to partition AN based on the type of service being delivered to the local-loop (e.g. business DSL line with VoIP service might be partitioned from HSI only DSL line). Both partitions might be controlled via the same NAS, and the AN could have a single adjacency with the NAS for both partitions. The NAS can potentially put the DSL subscriber in a different VRF for isolation (based on type of service). 
If we don't want to rule out such a scenario, then it makes sense for NAS to reflect the partition-ID in the ANCP messages (and the NAS and AN need to have a consistent mapping of DSL line to partition-ID).

Regards
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: Saturday, January 03, 2009 3:34 AM
To: [email-masked]; [email-masked]
Subject: Re: [ANCP] Partition ID

Regards,
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Sun, 4 Jan 2009 13:27:13 +0100

> From: Sanjay Wadhwa [mailto:[email-masked]] 
> Sent: 04 January 2009 07:04
> To: Wojciech Dec (wdec); [email-masked]; [email-masked]
> Subject: RE: [ANCP] Partition ID
> 
> If each partition on an AN is always controlled via a 
> different NAS (or same NAS but different peer IP address), 
> then we can get away without NAS having to reflect the 
> partition-ID in the ANCP messages, as partition-ID is 
> implicit on the AN from peer IP address. A L3 or L2 wholesale 
> service provided on the NAS (say via L2TP based backhaul to 
> retail ISP's router OR via virtual routing domains on the NAS 
> per retail-ISP) might seem like a driver for this on the 
> surface...but then I don't believe these require partitioning 
> on AN in the first place, and therefore not relevant to the 
> discussion.
> 
> However, one can imagine a scenario where AN partitioning is 
> based on a criterion other than the NAS (i.e. ANCP 
> controller) controlling it. ....e.g. one might want to 
> partition AN based on the type of service being delivered to 
> the local-loop (e.g. business DSL line with VoIP service 
> might be partitioned from HSI only DSL line). Both partitions 
> might be controlled via the same NAS, and the AN could have a 
> single adjacency with the NAS for both partitions. The NAS 
> can potentially put the DSL subscriber in a different VRF for 
> isolation (based on type of service). 

This case, which I agree with, is by an large the "functional partitioning" concept that was discussed some time ago (http://tools.ietf.org/wg/ancp/minutes?item=minutes66.html). 
However support for it in the WG did not come through and the framework draft refers to physical port partitioning only in Section 4.7.1:
"One partition is grouped of several Access Ports.  Each Access
      Port on an Access Node must be assigned uniquely to one partition"

Going from the above to functional partitioning will likely require a fair bit of work. Thus the interest of clarifying the protocol spec and if needed removing items that have no clear purpose and are likely to cause protocol incompatibility I'd encourage anyone who sees a clear need for either logical partitioning or some other purpose that requires the partition-id to be significant to the NAS to submit their case/proposal for discussion. 
As things stand now, it seems that physical port partitioning can very well be a local AN function that does not require a partition id field in ANCP.

Regards,
Woj.

> If we don't want to rule out such a scenario, then it makes 
> sense for NAS to reflect the partition-ID in the ANCP 
> messages (and the NAS and AN need to have a consistent 
> mapping of DSL line to partition-ID).
> 
> Regards
> -Sanjay
> 
> Behalf Of Wojciech Dec (wdec)
> > Using partitioning is not a real use case but an 
> operational extension 
> > in operation ANCP with multiple AN and BRAS devices. In practice a 
> > single edge network does not consist of a single BRAS. 
> Furthermore a 
> > single BRAS location may have multiple BRAS devices. I like 
> to point 
> > out the operational background and the partitioning ID negotiation.
> > 
> > Operational background:
> loaded by 
> > continuous increasing number of configured DSL ports. From traffic 
> > engineering point of view the BRAS can not handle additional new 
> > ports. In order not to reconfigure the whole network the AN opens a 
> > new partition and the next BRAS device (same location!) terminates 
> > this new partition coming from the same AN taking the new traffic.
> 
> You seem to be describing the case of *one* AN having two or 
> more partitions each associated with a *different* BRAS/NAS 
> ANCP controller through an ANCP adjacency. Is there any use 
> for *one* such an AN with the same type of multi partition 
> and multi-ANCP adjacency relationship with *a single* logical 
> BRAS/NAS ANCP controller? What would that case be?
> 
> 
> 
> > 
> > before. In order not to tear down the connection the BRAS 
> should learn 
> > this partiton ID.
> As Shridhar indicated, the partition id appears to be of no 
> consequence to the ANCP controller except if it is expected 
> to handle multiple ANCP adjacencies from one AN. 
> 
> Regards,
> Woj.
> 
> > 
> described 
> > independent on a particular use case because this feature is a 
> > fundamental operational configuration which is used by 
> already defined 
> > use cases and has no need to be a use case itself. Also backward 
> > compatibility is an issue here to be studied carefully 
> because of the 
> > the impact on using partition ID filed for new functionality.
> > 
> > Regards
> > Thomas
> > 
> > Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag 
> > von Wojciech Dec (wdec)
> > You raise a very good point. The partition "concept" is/was derived 
> > from GSMP where presumably a single controller could be managing 
> > multiple partitions on a single client. In the current set of ANCP 
> > use-cases this does not seem to be required and the 
> partition-id field 
> > may be yet another field that could be marked as "obsolete" 
> or simply 
> > ignored by the NAS. Could anyone in the WG indicate whether 
> they see a 
> > case where a single NAS would be handling multiple partitioned ANCP 
> > sessions from a single AN, and what would that case be?
> > 
> > Thanks,
> > Woj.
> >