Re: [PWE3] Questions relating to draft-ietf-pwe3-iccp-15.

["Samer Salam (ssalam)" <[e-mail]>]

Hi Binny,

Forced switchover is a useful administrative knob. However, as with switchover due to failure, it could lead to traffic loss, depending on the implementation at hand.
The way to achieve a forced switchover with mLACP using ICCP is by using the mLACP Port Priority TLV with the opcode: Remote Request for Priority Change. Effectively, the PE triggers this TLV as a result of the forced switchover administrative knob (as opposed to for e.g. reversion from failure as discussed in section 9.2.2.4). This can achieve the desired behaviour. Hence, no need for an additional TLV to achieve the same.


Regards,
Samer

From: Binny Jeshan <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 28 May, 2014 1:34 AM
To: Samer Salam <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Questions relating to draft-ietf-pwe3-iccp-15.


Hi Samer,



Thanks for your reponses.



I have another question popped now - I may be wrong - BUT- I am finding it missing about how a redundancy switchover could be made forcibly, in absence of any failure events..in a MCLAG.



May be this is not a perfect use case for this type of redundancy solution, But do you think the way i do -  that it could be  good to do a manual forced switchover to the standby AC Links even when the active AC is still working fine ?



One use that i see is that in MLACP case, during configuration of the MC-LAG group, one could select PE1 to be active role and choose PE2 to be standby in that MCLAG. Force swithover could help to do a role-change without re-configuring the MC-LAG or causing traffic drops.



What is your thoughts over this?



I think the Draft does not talk about any TLV that could carry information on a forced switchover to the redundant LAG bundle. if we add one TLV to perform this switchover (after needed handshakes) between the PEs, then this could be achieved.



Thanks,

Binny.



________________________________
From: Samer Salam (ssalam) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 1, 2014 7:30 PM
To: Binny Jeshan
Cc: [e-mail]<mailto:[e-mail]>; Ali Sajassi (sajassi); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.

Hi Binny,


  1.  The mLACP System Config TLV, as its name suggests, carries system-wide parameters. These parameters are not associated with a specific bundle, rather with the PE as a whole. That's the reason why there's no need to decode them or associate them with a given ROID.
  2.  For the mLACP Port Config TLV, the reason why we don't carry an ROID/Aggregator ID is because the LACP selection FSM will dynamically associate the port with the Aggregator by running the "Mux state machine". Please refer to 802.1AX for the details. In a nutshell, the "Actor Key" field will determine if the port is a candidate to join a specific Aggregator (in our lingo, have the port be associated with a given Aggregator/ROID). The Port Priority is compared against other port priorities, and any restrictions on the maximum number of ports per aggregator are checked, and if all that passes, then the port is associated with the Aggregator (I.e. ROID). This is all FSM logic that needs to be done dynamically by LACP (which presumably is running in your or alongside your mLACP ICCP application). If you have not already done so, it will make things much clearer if you were to first go through the internals of how LACP works (802.1AX spec), and then revisit the mLACP sections of this draft.

Regards,
Samer

From: Binny Jeshan <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 1 May, 2014 3:15 AM
To: Samer Salam <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Questions relating to draft-ietf-pwe3-iccp-15.

Hi Samer,

Thanks a lot for your time. Just a little more to exchange for now, please read below.

Just like as you said before – that, there could be subsets of RG created between two PEs, thereby making the RG between two PEs > 1 && State Machine instances of ICCP created to manage those many groups,  when reading this draft the understanding that i got is something that the MLACP Application would also have state Machine instances created in proportion to the number of Aggregator instances that its holding.  Something like below..

[cid:image002.jpg@01CF653F.5E2DAB30]


But, after you have now clarified to me that
1)            “You are mixing up two things here: each application has a single instance in a given RG. That is, there is one mLCAP client application of ICCP. This application is managing both MC-LAG instances (in your example). The way by which one MC-LAG is distinguished from the other is by the ROID or Aggregator ID” -> my understanding of the mLACP Application part is clarified that there would be NO need of two state Machines or Instances to manage the two MC-LAGs
 => this brings me out of clarification from you - a learning that mLACP would need to have only one instance Mlag-1 to manage both Agg1 and Agg2. And so there will be just the one State Machine for mLACP application, and it will hold data for many Bundles that its managing. Decent enough :)

2)            “ and when an Application Data Message is Received, use the ROID / Aggregator ID”
=> below would be a table that I think would be if I do so. And here is see some gaps w.r.t.my understanding again :(

If my Translation table looks like:

RGID

Agg ID

ROID (32bit RGID + 32Bit Agg ID)

50

100

50 + 100

50

200

50 + 200

50

300

50 + 300

Then, if I form a packet de-multiplexing rule matrix, it looks like
Type of Packet

Format of the Incoming Packet into the PE

De-muxing to the right ICCP Channel

De-muxing to the right Bundle Manager

7.2.1. mLACP Connect TLV

ICC Header with Type 0x0700 + mLACP Connect TLV

RGID contained in ICC Header

Not Applicable
(since this packet is for the full mlacp Application)

7.2.2. mLACP Disconnect TLV

ICC Header with Type 0x0701 + mLACP Disconnect TLV

RGID contained in ICC Header

Not Applicable
(since this packet is for the full mlacp Application)

7.2.2.1. mLACP Disconnect Cause TLV

ICC Header with Type 0x0701 + mLACP Disconnect TLV
 + Disconnect Cause TLV (optional to the Disconnect TLV)

RGID contained in ICC Header

Not Applicable
(since this packet is for the full mlacp Application)

7.2.3. mLACP System Config TLV

ICC Header with Type 0x0703 + mLACP System Config TLV

RGID contained in ICC Header

No key to decode

7.2.4. mLACP Aggregator Config TLV

ICC Header with Type 0x0703 + mLACP Aggregator Config TLV

RGID contained in ICC Header

ROID or Aggregator ID (present in Aggregator Config TLV)

7.2.5. mLACP Port Config TLV

ICC Header with Type 0x0703 + mLACP Port Config TLV

RGID contained in ICC Header

No key to decode

7.2.6. mLACP Port Priority TLV

ICC Header with Type 0x0703 + mLACP Port Priority TLV

RGID contained in ICC Header

Aggregator ID (present in Port Priority TLV)

7.2.7. mLACP Port State TLV

ICC Header with Type 0x0703 + mLACP Port State TLV

RGID contained in ICC Header

Aggregator ID (present in Port State TLV)

7.2.8. mLACP Aggregator State TLV

ICC Header with Type 0x0703 + mLACP Aggregator State TLV

RGID contained in ICC Header

Aggregator ID (present in Aggregator State TLV)

7.2.9. mLACP Synchronization Request TLV

ICC Header with Type 0x0703 + mLACP Synchronization Request TLV

RGID contained in ICC Header

ONLY case when Aggregator Data is requested, Aggregator ID inside the Synchronization Request TLV can be used for translation. If it was System Sync or Port Config Sync, translating is again not straight forward. Because receiver does not know

7.2.10. mLACP Synchronization Data TLV

ICC Header with Type 0x0703 + Synchronization Data TLV

RGID contained in ICC Header

During processing of this TLV, issue in mapping is faced if Synchronization is requested for 0x02   Request Port Data & 0x00   Request System Data – because in those corresponding TLV’s theres no unique identifier.


Can you please assist with your understanding on the above highlighted gaps?

Thanks,
Binny.


From: Binny Jeshan [mailto:[e-mail]]
Sent: Thursday, May 01, 2014 9:48 AM
To: Binny Jeshan
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.

On 1 May 2014 00:39, Samer Salam (ssalam) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Binny,
There's a one-to-one mapping between the ROID and the Aggregator ID. There were two reasons why the Aggregator ID was passed in lieu of the ROID:

  *   The ROID is 8 bytes, whereas the Aggregator ID is 2 bytes. Hence, it is more efficient encoding on the wire.
  *   To the mLACP application, the Aggregator ID is a native identifier (used to identify the bundle per 802.1AX)
 You can have a translation table that simply maps one to the other.

Regards,
Samer

From: Binny Jeshan <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 30 April, 2014 1:58 PM

To: Samer Salam <[e-mail]<mailto:[e-mail]>>
Cc: "Luca Martini (lmartini)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Questions relating to draft-ietf-pwe3-iccp-15.

Hi Samer,

To the last question I had, I am still left unclear & with a feeling that it would be good to have a ROID that is always a part of the application data message so that at the receiving end demultiplexing becomes better especially when multiple bundles or applications use the ICCP channel. The packet information would look a bit more informative in that case, and also helps a bit more for implementation.

In mc-lag case, if I don't have a ROID carried in every application data packet, I'd be required to inspect aggregator or port configuration data for demultiplexing that packet to the right bundle, which is not so good. Had I encoded a,ROID something like 32bit RG ID + 32 bit aggregator ID / bundle unique id, and sent this on the very top of the application message, things get more nicer.

I'd kindly suggest to adding ROID in this way of usage, as because the current ROID advertisement in just one of the packets seems not showing ease. Please consider, and feedback.

Regards,
Binny.

Sent from Nokia Lumia.
________________________________
From: Samer Salam (ssalam)<mailto:[e-mail]>
Sent: ?30-?04-?2014 10:39 PM

To: Binny Jeshan<mailto:[e-mail]>
Cc: Luca Martini (lmartini)<mailto:[e-mail]>; Ali Sajassi (sajassi)<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.
Hi Binny,

Please find responses inline at [s1]
From: Binny Jeshan <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 20 April, 2014 2:31 AM
To: Samer Salam <[e-mail]<mailto:[e-mail]>>
Cc: "Luca Martini (lmartini)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Questions relating to draft-ietf-pwe3-iccp-15.

Hi Samer,

I have few questions now.

1) How many MAX redundant Groups can be possible between two Peers?
[Binny]: In my understanding one RG configured in a PE can cater many instances of Applications. for example, one can associate a mLACP Aggregation bundle t1 and t2  to be a part of Redundant group 1. Please clarify  and confirm.

[s1] Typically, between two PEs, a single Redundancy Group is sufficient. Indeed, it is possible to associate multiple bundle interfaces with the same group. Usually, multiple RGs are employed if you need to logically group 3 or more PEs into subsets. E.g. PE1, PE2, PE3. On PE1, you may have an RG with PE2 and another RG with PE3 to perform flexible grouping.


2) As i understand from this draft, applications send their TLV's to the peer through the ICCP channel. Which means mLACP Application Data Message would look like -> ICC Header (6.1.1)  with Type 0x703+ mLACP SystemConfig Tlv (type 0032 - section 7.2.3) . Is this understanding correct that the stack order looks like Ethernet + IP + LDP Header + ICCP header + Application TLVs.

[s1] Correct.

If my understanding in (1) was right, then How different Application Instances are distinuguished in the Packets received. (for example mLACP may have two MC-LAG instances that its managing) - but the ICC header will have only one RG ID but the following TLV could belong to one of the application instances running on top of the RG.  How to demultiplex that.

[s1] You are mixing up two things here: each application has a single instance in a given RG. That is, there is one mLCAP client application of ICCP. This application is managing both MC-LAG instances (in your example). The way by which one MC-LAG is distinguished from the other is by the ROID or Aggregator ID.

I  see a reference to ROID. Section 4.3 " That allows separate systems in an RG to use a common handle to reference the protected entity" .
This draft does not define how exactly the ROID bytes will be encoded, as far as i read. This leaves interop malfunction also, various options to code the ROID. one option could
ROID =
But im left unclear where i will fit this ROID in each type of packet sent by the application

[s1] The only requirement for interoperability between systems is that all PEs in the RG use the same ROID numeric value for the same protected entity. If an implementation wishes to encode semantics in the ROID, that's fine, and out of scope of the draft.

3) How do i exactly code the ROID? can you please standardize that > Comment please.

[s1] The semantics of the ROID is irrelevant for interoperability, that's why it was not standardized. All what is required is that it matches on the PEs. You can have it set by configuration, for example.

4) Why ROID is not mentioned to be a Part of EVERY TLV or atleast have a Application Header or something like that to carry it ?

[s1] It is treated as part of the configuration data, and hence it does not change dynamically during the lifespan of the application connection. If it does change, then this is handled as if the object is deleted and a new created. This allows you to safely reset the associated state machines.

Regards,
Samer

Thanks,
Binny.
Aricent.


On 31 March 2014 23:15, Samer Salam (ssalam) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Binny,

From: Binny Jeshan <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 20 March, 2014 3:12 AM
To: "Luca Martini (lmartini)" <[e-mail]<mailto:[e-mail]>>, Samer Salam <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Questions relating to draft-ietf-pwe3-iccp-15.

Hello,

I came across this when reading this draft. http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15

1)
Section 7.2.5<http://tools.ietf.org/html/draft-ietf-pwe3-iccp-15#section-7.2.5>.5>. mLACP Port Config TLV says,
- Flags

       Valid values are:

            -i. Synchronized (0x01)

                Indicates that the sender has concluded transmitting all
                member link port configurations for a given Aggregator.

Shouldn't this be stating it as "given Port" ?

>>> Aggregator is the term used by the IEEE 802.1AX standard to refer to the Ethernet "bundle", so it is correct as is.


2) I am not able to spot mail archives of this topic in the PWE3 group . Did I do a limited search or a wrong directory search? please direct me to the right mail archive where I can see discussion emails about this draft so that I can know more details from it for better understanding.


>>>> What type of information are you looking for? The draft is quite detailed and self-explanatory. If you have questions, please post them.

Regards,
Samer

I am new to this Topic of mLACP and its aggregation. I may have more queries later on.

Thanks,
Binny

Aricent, India.


[E-Banner]<http://www.mrv.com/products/optidriver>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.

[E-Banner]<http://www.mrv.com/products/optidriver>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.