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

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

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.