Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

From: Sarah Geisler <[email-masked]>
Date: Fri, 2 Sep 2016 09:06:43 -0700

Hi Everyone,

This is my draft proposal optical device discovery through the use of a new
multicast address, via either direct injection or an out of band process -
please feel free to review.

One of the things it considers in 'Future Considerations' is:

Ability for optical nodes to alert a router when it hits a
threshold PreFEC Bit Error Rate, or PostFEC bit errors, so
correlation of outages is simplified between the optical and
network domains.

I would appreciate any feedback on this.

Sarah

Sarah Geisler | Network Engineer | [email-masked] | +1 650 713 9641

On Mon, Aug 29, 2016 at 4:43 PM, Sarah Geisler <[email-masked]> wrote:

> Hi All,
>
> I incorporated a lot of feedback I got about making the use cases clearer
> and siting some differences with LMP. Here is the new draft.
>
> https://tools.ietf.org/html/draft-geisler-optical-device-discovery-02
>
> Thinking about this, I still think this is worth considering as a draft,
> due to the Data Center Interconnect options now available in DWDM systems,
> and due to the lean towards LLDP snooping on these particular platforms.
>
> Cheers,
>
> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713 9641
>
> On Tue, Aug 23, 2016 at 10:44 PM, Sarah Geisler <[email-masked]>
> wrote:
>
>> Hi All,
>>
>> Given all the feedback, I will work on this draft hopefully this week!
>> Thank you for your feedback so far and will work on some edits.
>>
>> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713 9641
>>
>> On Fri, Aug 19, 2016 at 11:38 AM, Gert Grammel <[email-masked]>
>> wrote:
>>
>>> Hi Gabriele,
>>>
>>> After stepping back and checking what is there in LMP and in LLDP
>>> Sarah’s argument resonates with me. The client side would continue to use
>>> LLDP but made receptive to an out-of-band confirmation message.
>>> There are 3 kinds of clients and 3 kinds of servers (optical nodes). If
>>> the goal is to achieve auto-discovery, the following combinations exist:
>>>
>>> Servers / Clients
>>>
>>>  C:Non-LLDP capable
>>>
>>>  C:LLDP + add-on
>>>
>>> C:LLDP capable
>>>
>>>  S:Non-LLDP capable
>>>
>>>  Use LMP
>>>
>>> Use LMP
>>>
>>> Use LMP
>>>
>>>  S:LLDP snooping
>>>
>>> Use LMP
>>>
>>> Device-discovery-00
>>>
>>> Device-discovery-00
>>>
>>>  S:LLDP capable
>>>
>>> Use LMP
>>>
>>> n/a
>>>
>>> LLDP
>>>
>>> LMP would need to run a LinkVerify procedure that has to be implemented
>>> on Client and Server side. LMP also provides much more features like link
>>> property correlation, parameter negotiation  and other useful stuff for
>>> optical nodes that can’t snoop. In contrast, LLDP is widely implemented in
>>> many client devices (switches, routers) and doesn’t need parameter
>>> negotiation or link property correlation.
>>>
>>> Admittedly LLDP is not so wide-spread on optical devices today, but
>>> implementations do exist. Looking at LMP, I came to the point that it
>>> wouldn’t be so easy to strip-off some LMP procedures (like LinkVerify) to
>>> achieve the same ease-of-use as for an LLDP based implementation. So the
>>> best way forward seems to add the use case in the framework and move on
>>> with the draft.
>>>
>>> Best
>>>
>>> Gert
>>>
>>>
>>>
>>>
>>>
>>> From: Sarah Geisler <[email-masked]>
>>> Date: Friday 19 August 2016 19:31
>>> To: Gabriele Galimberti <[email-masked]>
>>> Cc: Gert Grammel <[email-masked]>, CCAMP <[email-masked]>
>>>
>>> Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-d
>>> iscovery-00.txt
>>>
>>> Hi Gabriele,
>>>
>>>
>>> Hi All,
>>>> I think LLDP could be a good solution to physically check the Client to
>>>> Network connectivity and
>>>> Communicate the Client info to the Network.
>>>>
>>>
>>> It's a similar mechanism to LLDP, but not quite LLDP. Because the trend
>>> is going down the path of LLDP snooping, my approach was to split this out
>>> into a new protocol.
>>>
>>>
>>>> The other way around is not possible so the Client does not know who is
>>>> connected to.
>>>>
>>>
>>> Some vendors, have chosen the approach of putting some layer 2 capable
>>> device between the client port and DSP. This is the case I mention in my
>>> draft.
>>>
>>>
>>>> An external controller is then needed to complete and manage the
>>>> connection.
>>>> If no External Controller is available then LMP is needed to close the
>>>> loop.
>>>> This is applicable to the case where the Client is connected to
>>>> Transponder (via a xGE).
>>>> In case of DWDM interface located in the Client the LLDP is not
>>>> applicable a
>>>> Different signalling mechanism should be used to check the physical
>>>> connectivity (like toggling the
>>>> Transceiver TX and the ROADM detecting the sequence at its port, this
>>>> may work off line).
>>>>
>>>
>>> What about for Data Center Interconnect Platform cases? this is a use
>>> case we have not addressed and I am trying to address in this draft.
>>> Multiple vendors have developed these style of devices so the router,
>>> transponder and line system are all separated out. In this case, LMP is not
>>> available from vendors and LLDP snooping has been used instead. I am
>>> suggesting we create a separated out protocol but using a similar mechanism
>>> to LLDP (either with direct injection with the layer 2 device in the DCI
>>> box, or via out of band mechanism). My draft differs from LMP, it doesn't
>>> require neighbor configuration and just takes the management IP address
>>> from the management address TLV sent by the router and sends the responding
>>> Optical Device Discovery packet to that address. Like this, they discover
>>> each other.
>>>
>>>
>>>> In this case either an external Controller is needed to drive the
>>>> connectivity check or
>>>> An LMP protocol may help (running over the DCN).
>>>> I definitely encourage to work on the use cases:
>>>>  1 - In–band signalling available
>>>>         a  - Protocol based: LLDP
>>>>
>>>
>>> Optical device discovery rather than LLDP. I would like to put forward a
>>> 'new type of LLDP' for optical.
>>>
>>>
>>>>         b  - no protocol bases: Centralised controller and provisioning
>>>>  2 - No in-band signalling
>>>>         a -  Protocol based: LMP (is the available solution)
>>>
>>>         b – no protocol based: Centralised controller and provisioning
>>>>
>>>
>>> My draft does not deal with provisioning, it's aim is to simplify the
>>> implementation for the purposes of only discovery. In the case of a Data
>>> center interconnect environment, configuration will be for larger
>>> deployments via APIs that are supported.
>>>
>>>
>>>> The draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk
>>>> <https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/> can
>>>> help.
>>>> We have to make sure not to proliferate too many solutions to solve the
>>>> same issue, although I’m in favour to
>>>> Use LLDP where it is applicable.
>>>> Best Regards,
>>>> Gabriele
>>>
>>>
>>>
>>> I believe that this solution is the best approach for non OTN, non
>>> GMPLS, Data Center Interconnect transponder environments, which are new.
>>> From an operator perspective, it's minimal configuration and capitalizes on
>>> the already trending approach of LLDP snooping, but separating it out to
>>> give us freedom to create new optical related TLVs.
>>>
>>> Cheers,
>>>
>>>
>>> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713 9641
>>>
>>> On Thu, Aug 18, 2016 at 8:21 AM, Gabriele Maria Galimberti (ggalimbe) <
>>> [email-masked]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I think LLDP could be a good solution to physically check the Client to
>>>> Network connectivity and
>>>> Communicate the Client info to the Network.
>>>> The other way around is not possible so the Client does not know who is
>>>> connected to.
>>>> An external controller is then needed to complete and manage the
>>>> connection.
>>>> If no External Controller is available then LMP is needed to close the
>>>> loop.
>>>> This is applicable to the case where the Client is connected to
>>>> Transponder (via a xGE).
>>>>
>>>> In case of DWDM interface located in the Client the LLDP is not
>>>> applicable a
>>>> Different signalling mechanism should be used to check the physical
>>>> connectivity (like toggling the
>>>> Transceiver TX and the ROADM detecting the sequence at its port, this
>>>> may work off line).
>>>> In this case either an external Controller is needed to drive the
>>>> connectivity check or
>>>> An LMP protocol may help (running over the DCN).
>>>>
>>>> I definitely encourage to work on the use cases:
>>>>  1 - In–band signalling available
>>>>         a  - Protocol based: LLDP
>>>>         b  - no protocol bases: Centralised controller and provisioning
>>>>  2 - No in-band signalling
>>>>         a -  Protocol based: LMP (is the available solution)
>>>>         b – no protocol based: Centralised controller and provisioning
>>>>
>>>> The draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk
>>>> <https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/> can
>>>> help.
>>>>
>>>> We have to make sure not to proliferate too many solutions to solve the
>>>> same issue, although I’m in favour to
>>>> Use LLDP where it is applicable.
>>>>
>>>> Best Regards,
>>>>
>>>> Gabriele
>>>>
>>>>
>>>>
>>>>
>>>> *Gabriele Galimberti*
>>>> Principal Engineer
>>>> *Cisco Photonics Srl*
>>>>
>>>>
>>>>
>>>> via S.Maria Molgora, 48 C
>>>>
>>>> 20871 - Vimercate (MB)
>>>> Italy
>>>> www.cisco.com/global/IT/
>>>>
>>>>
>>>> [email-masked]
>>>> Phone :*+39 039 2091462 <%2B39%20039%202091462>*
>>>> Mobile :*+39 335 7481947 <%2B39%20335%207481947>*
>>>> Fax :*+39 039 2092049 <%2B39%20039%202092049>*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: CCAMP <[email-masked]> on behalf of Sarah Geisler <
>>>> [email-masked]>
>>>> Date: Wednesday 17 August 2016 at 01:11
>>>> To: Gert Grammel <[email-masked]>
>>>> Cc: "[email-masked]" <[email-masked]>
>>>>
>>>> Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-d
>>>> iscovery-00.txt
>>>>
>>>> Hi Gert,
>>>>
>>>> In the draft, there is an option where frames can be inserted into the
>>>> client data plane, and an option where there is no such functionality, so
>>>> it takes the management address from the TLV sent by the router, and sends
>>>> the frames out of band encapsulated in IP.
>>>>
>>>> If LLDP snooping is supported:
>>>>
>>>> LLDP snooping only snoops the LLDP packet by splitting it out based on
>>>> the destination MAC address (multicast) just before it hits the muxponding
>>>> component. What we're is TLVs that may apply particularly to optical nodes,
>>>> and mutual discovery rather than just one way (router -> optical node)
>>>> discovery.
>>>>
>>>> If LLDP isn't supported:
>>>>
>>>> I'm suggesting an approach different to LMP, that I believe pushes in
>>>> the right direction for Data Center Interconnect (separated out of the line
>>>> system and the router). I've seen that DCI boxes are supporting LLDP
>>>> snooping, this is just extending that to a new protocol, giving us freedom
>>>> to add optical specific TLVs, and freedom to have separated out discovery
>>>> between L2 and L1.
>>>>
>>>> I hope this clears it up a little more.
>>>>
>>>> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713
>>>> 9641
>>>>
>>>> On Tue, Aug 16, 2016 at 11:05 AM, Gert Grammel <[email-masked]>
>>>> wrote:
>>>>
>>>>>
>>>>> Sarah, Ruediger,
>>>>>
>>>>> It appears to me that there is a misunderstanding in the
>>>>> pre-conditions. From the discussion I get:
>>>>> Sarah: the optical device is capable to insert and extract MAC frames
>>>>> into the payload link between a router and the device. Hence LLDP is an
>>>>> option
>>>>> Rüdiger: The optical device is transparent to MAC frames, hence LLDP
>>>>> is not an option, LMP however is.
>>>>>
>>>>> Is that a fair observation?
>>>>>
>>>>> What I haven’t got out of the exchange is:
>>>>> —> if an optical device supports inband LLDP-snoopting what exactly is
>>>>> missing?
>>>>> —> if an optical device does not support LLDP-snooping, what is the
>>>>> proposal besides LMP, or a variation thereof?
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gert
>>>>>
>>>>>
>>>>> From: CCAMP <[email-masked]> on behalf of Sarah Geisler <
>>>>> [email-masked]>
>>>>> Date: Tuesday 16 August 2016 19:48
>>>>> To: Ruediger Kunze <[email-masked]>
>>>>> Cc: CCAMP <[email-masked]>
>>>>> Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-d
>>>>> iscovery-00.txt
>>>>>
>>>>> Hi Rüdiger,
>>>>>
>>>>> There is no part of the protocol that actually defines the SDN
>>>>> approach, perhaps I should change that sentence to make it more clear. The
>>>>> only point I was making was that the information shared as a result of this
>>>>> protocol can be accessed across the router and optical domain by APIs in IP
>>>>> world or Transport world. One use case I'm familiar with for this would be
>>>>> inventory.
>>>>>
>>>>> Right now, DCI boxes are moving towards LLDP snooping of LLDP packets
>>>>> coming from routers. If instead we change this to mutual discovery, an API
>>>>> could be used to periodically poll for the connectivity information, to
>>>>> help verify the inventory kept by organizations is correct by cross
>>>>> checking it with real data.
>>>>>
>>>>> I don't discuss configuration of the ROADM from the router in this
>>>>> draft, it's more purely mutual discovery. What the draft aims for is - if
>>>>> we're going to move towards LLDP snooping (haven't seen LMP supported in
>>>>> DCI boxes yet), let's move towards an approach that allows mutual
>>>>> discovery, similar configuration, and simple implementation like LLDP,
>>>>> where there are no neighbor associations, we throw a frame out on the wire
>>>>> and whoever listens (if security allows too) gets the info.
>>>>>
>>>>> From https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-
>>>>> if-mng-ctrl-fwk/):
>>>>>
>>>>> Current generation WDM netwoks are single vendor networks where the
>>>>>    optical line system and the transponders are tightly integrated.  The
>>>>>    DWDM interfaces migration from the Transponders to the Client
>>>>>    interfaces changes this scenario, by introducing a standardized
>>>>>    interface at the level of OCh between the Client DWDM interface and
>>>>>    the DWDM network.
>>>>>
>>>>>
>>>>> I'm seeing something different - multi vendor networks where the
>>>>> transponders are separated out from the router AND the line system, which
>>>>> is something new. Perhaps I need to add this particular use case and info
>>>>> in my draft too. Once the router, transponder, and line system are all
>>>>> decoupled and could be a combination of any vendor, I think this solution
>>>>> allows the router to discover what it needs to to make the life easier for
>>>>> the operator, in a light weight implementation.
>>>>>
>>>>>
>>>>> Let me know your thoughts. Thanks for your feedback so far!
>>>>>
>>>>>
>>>>> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713
>>>>> 9641
>>>>>
>>>>> On Tue, Aug 16, 2016 at 6:21 AM, <[email-masked]> wrote:
>>>>>
>>>>>> Hi Sarah, all
>>>>>>
>>>>>>
>>>>>>
>>>>>> I absolutely agree with your requirements from the operators
>>>>>> perspective. What I am missing is a more detailed uses case especially when
>>>>>> it comes to the automation part you are mention in your E-Mail. Which part
>>>>>> plays SDN here?  A description of a  use case could help here to understand
>>>>>> why LMP is not suitable.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Even if you have the transponder integrated in the router you have to
>>>>>> discover the capabilities of that transponder and vice versa of the OLS, if
>>>>>> you want to stay with the classic decentralized CP approach + multivendor.
>>>>>>
>>>>>> In our framework document (https://datatracker.ietf.org/
>>>>>> doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/) we try to solve some
>>>>>> issues by using LMP between the router and ROADM for example, especially in
>>>>>> cases where you want to automate the wavelength setup process.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Br,
>>>>>>
>>>>>> Rüdiger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Von:* CCAMP [mailto:[email-masked]] *Im Auftrag von *Sarah
>>>>>> Geisler
>>>>>> *Gesendet:* Montag, 15. August 2016 19:14
>>>>>> *An:* Dieter Beller
>>>>>> *Cc:* [email-masked]
>>>>>> *Betreff:* Re: [CCAMP] Fwd: I-D Action:
>>>>>> draft-geisler-optical-device-discovery-00.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think based on the feedback given, I should add a section outlining
>>>>>> the difference between this approach and LMP. I will work on that and
>>>>>> update a 02 version.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you for your responses so far.
>>>>>>
>>>>>>
>>>>>> Sarah Geisler | Network Engineer | [email-masked] | +1 650 713
>>>>>> 9641
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 12, 2016 at 5:30 AM, Dieter Beller <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am glad to see that this is now being discussed on the CCAMP list,
>>>>>> which is IMHO the right WG dealing with these kind of technical topics.
>>>>>>
>>>>>> Further discussion will also help us to draw a conclusion whether lmp
>>>>>> or an lmp mechanism could be a solution to the problem addressed in
>>>>>> this new draft. Most optical devices today are encapsulating the
>>>>>> client signal without looking into it (e.g. transparently mapping 10G Eth
>>>>>> into
>>>>>> an ODU2e OTN container that is carried across the OTN in an OCH
>>>>>> signal). Therefore, it needs to be carefully analyzed to what extent new
>>>>>> functionality is required for optical devices.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Dieter
>>>>>>
>>>>>> On 12.08.2016 03:15, Zhangxian (Xian) wrote:
>>>>>>
>>>>>> The same question ("Why not LMP") also pops in my mind while reading this draft. I wonder if you two have reached any conclusion/mutual understanding?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Xian
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----邮件原件-----
>>>>>>
>>>>>> 发件人: CCAMP [mailto:[email-masked] <[email-masked]>] 代表 Adrian Farrel
>>>>>>
>>>>>> 发送时间: 2016年8月11日 21:43
>>>>>>
>>>>>> 收件人: 'Fred Baker (fred)'; [email-masked]
>>>>>>
>>>>>> 抄送: [email-masked]
>>>>>>
>>>>>> 主题: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sarah and I have been having an offline conversation loosely under the title "Why not LMP".
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sarah, if you want to short-cut discussion on this list, then you have my permission to copy the thread here.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>>
>>>>>> From: CCAMP [mailto:[email-masked] <[email-masked]>] On Behalf Of Fred Baker
>>>>>>
>>>>>> (fred)
>>>>>>
>>>>>> Sent: 11 August 2016 02:05
>>>>>>
>>>>>> To: [email-masked]
>>>>>>
>>>>>> Subject: [CCAMP] Fwd: I-D Action:
>>>>>>
>>>>>> draft-geisler-optical-device-discovery-00.txt
>>>>>>
>>>>>> We have mentioned this to opsawg, but the ccamp chairs suggest that
>>>>>>
>>>>>> ccamp may be a better venue. Your comments are welcome.
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: [email-masked]
>>>>>>
>>>>>> Subject: I-D Action: draft-geisler-optical-device-discovery-00.txt
>>>>>>
>>>>>> Date: August 8, 2016 at 3:39:48 PM PDT
>>>>>>
>>>>>> To: <[email-masked]> <[email-masked]>
>>>>>>
>>>>>> Reply-To: [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>>
>>>>>> directories.
>>>>>>
>>>>>>
>>>>>>
>>>>>>        Title           : Optical Device Discovery
>>>>>>
>>>>>>        Authors         : Sarah Geisler
>>>>>>
>>>>>>                          Fred Baker
>>>>>>
>>>>>>      Filename        : draft-geisler-optical-device-discovery-00.txt
>>>>>>
>>>>>>      Pages           : 8
>>>>>>
>>>>>>      Date            : 2016-08-07
>>>>>>
>>>>>>
>>>>>>
>>>>>> Abstract:
>>>>>>
>>>>>>   This document introduces a method for Optical device discovery, by
>>>>>>
>>>>>>   introducing a new multicast group for frames to be captured by
>>>>>>
>>>>>>   optical nodes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-geisler-optical-device-discov
>>>>>>
>>>>>> ery/
>>>>>>
>>>>>>
>>>>>>
>>>>>> There's also a htmlized version available at:
>>>>>>
>>>>>> https://tools.ietf.org/html/draft-geisler-optical-device-discovery-0
>>>>>>
>>>>>> 0
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>
>>>>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> I-D-Announce mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>
>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>>>
>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> CCAMP mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> CCAMP mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

---

From: Sarah Geisler <[email-masked]>
Date: Fri, 16 Sep 2016 11:54:08 -0700

Hi All,

Would like to revive this conversation. Is there any feedback for this
draft?

On Fri, Sep 2, 2016 at 9:06 AM, Sarah Geisler <[email-masked]> wrote:

> Hi Everyone,
>
> This is my draft proposal optical device discovery through the use of a
> new multicast address, via either direct injection or an out of band
> process - please feel free to review.
>
>>>>> I think LLDP could be a good solution to physically check the Client
>>>>> to Network connectivity and
>>>>> The other way around is not possible so the Client does not know who
>>>>> is connected to.
>>>>>
>>>>
>>>> Optical device discovery rather than LLDP. I would like to put forward
>>>> a 'new type of LLDP' for optical.
>>>>
>>>>
>>>>> We have to make sure not to proliferate too many solutions to solve
>>>>> the same issue, although I’m in favour to
>>>>> I think LLDP could be a good solution to physically check the Client
>>>>> to Network connectivity and
>>>>> The other way around is not possible so the Client does not know who
>>>>> is connected to.
>>>>> We have to make sure not to proliferate too many solutions to solve
>>>>> the same issue, although I’m in favour to
>>>>>> —> if an optical device supports inband LLDP-snoopting what exactly
>>>>>> is missing?
>>>>>>> Even if you have the transponder integrated in the router you have
>>>>>>> to discover the capabilities of that transponder and vice versa of the OLS,
>>>>>>> if you want to stay with the classic decentralized CP approach +
>>>>>>> multivendor.
>>>>>>>
>>>>>>> I think based on the feedback given, I should add a section
>>>>>>> outlining the difference between this approach and LMP. I will work on that
>>>>>>> and update a 02 version.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Further discussion will also help us to draw a conclusion whether
>>>>>>> lmp or an lmp mechanism could be a solution to the problem addressed in

---

From: "qinjun (G)" <[email-masked]>
Date: Tue, 27 Sep 2016 07:00:19 +0000

Hi Sarah,

I think this is a very useful document, which targets on a real problem in the network and provides good analysis and candidate solutions. After reading the recent version of the draft, i have the following suggestions:

1)Shall the protocol be called as LLDP extensions instead of separated protocol, because most of the TLVs are reused from LLDP, and new TLVs can be defined in LLDP as needed.

2)If we don't consider separating out the network layers, could LLDP snooping implement the function? The draft gives the comparison with LMP, for the comprehensiveness of analysis, the LLDP snooping based mechanism may also be added into the draft, though some related discussion already happened on the list. If needed I will be glad to help with that.

Best Regards.

Jun

发件人: CCAMP [mailto:[email-masked]] 代表 Sarah Geisler
发送时间: 2016年9月17日 2:54
收件人: Gert Grammel
抄送: [email-masked]
主题: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi All,

Would like to revive this conversation. Is there any feedback for this draft?

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641

On Fri, Sep 2, 2016 at 9:06 AM, Sarah Geisler <[email-masked]<mailto:[email-masked]>> wrote:
Hi Everyone,

This is my draft proposal optical device discovery through the use of a new multicast address, via either direct injection or an out of band process - please feel free to review.

network domains.

Sarah

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Mon, Aug 29, 2016 at 4:43 PM, Sarah Geisler <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

I incorporated a lot of feedback I got about making the use cases clearer and siting some differences with LMP. Here is the new draft.

Thinking about this, I still think this is worth considering as a draft, due to the Data Center Interconnect options now available in DWDM systems, and due to the lean towards LLDP snooping on these particular platforms.

Cheers,

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Tue, Aug 23, 2016 at 10:44 PM, Sarah Geisler <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Given all the feedback, I will work on this draft hopefully this week! Thank you for your feedback so far and will work on some edits.

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Fri, Aug 19, 2016 at 11:38 AM, Gert Grammel <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gabriele,

After stepping back and checking what is there in LMP and in LLDP Sarah’s argument resonates with me. The client side would continue to use LLDP but made receptive to an out-of-band confirmation message.
There are 3 kinds of clients and 3 kinds of servers (optical nodes). If the goal is to achieve auto-discovery, the following combinations exist:

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

LMP would need to run a LinkVerify procedure that has to be implemented on Client and Server side. LMP also provides much more features like link property correlation, parameter negotiation  and other useful stuff for optical nodes that can’t snoop. In contrast, LLDP is widely implemented in many client devices (switches, routers) and doesn’t need parameter negotiation or link property correlation.

Admittedly LLDP is not so wide-spread on optical devices today, but implementations do exist. Looking at LMP, I came to the point that it wouldn’t be so easy to strip-off some LMP procedures (like LinkVerify) to achieve the same ease-of-use as for an LLDP based implementation. So the best way forward seems to add the use case in the framework and move on with the draft.

Best

Gert

From: Sarah Geisler <[email-masked]<mailto:[email-masked]>>
Date: Friday 19 August 2016 19:31
To: Gabriele Galimberti <[email-masked]<mailto:[email-masked]>>
Cc: Gert Grammel <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>

Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Gabriele,

Hi All,
I think LLDP could be a good solution to physically check the Client to Network connectivity and
Communicate the Client info to the Network.

It's a similar mechanism to LLDP, but not quite LLDP. Because the trend is going down the path of LLDP snooping, my approach was to split this out into a new protocol.

The other way around is not possible so the Client does not know who is connected to.

Some vendors, have chosen the approach of putting some layer 2 capable device between the client port and DSP. This is the case I mention in my draft.

An external controller is then needed to complete and manage the connection.
If no External Controller is available then LMP is needed to close the loop.
This is applicable to the case where the Client is connected to Transponder (via a xGE).
In case of DWDM interface located in the Client the LLDP is not applicable a
Different signalling mechanism should be used to check the physical connectivity (like toggling the
Transceiver TX and the ROADM detecting the sequence at its port, this may work off line).

What about for Data Center Interconnect Platform cases? this is a use case we have not addressed and I am trying to address in this draft. Multiple vendors have developed these style of devices so the router, transponder and line system are all separated out. In this case, LMP is not available from vendors and LLDP snooping has been used instead. I am suggesting we create a separated out protocol but using a similar mechanism to LLDP (either with direct injection with the layer 2 device in the DCI box, or via out of band mechanism). My draft differs from LMP, it doesn't require neighbor configuration and just takes the management IP address from the management address TLV sent by the router and sends the responding Optical Device Discovery packet to that address. Like this, they discover each other.

In this case either an external Controller is needed to drive the connectivity check or
An LMP protocol may help (running over the DCN).
I definitely encourage to work on the use cases:
 1 - In–band signalling available
        a  - Protocol based: LLDP

Optical device discovery rather than LLDP. I would like to put forward a 'new type of LLDP' for optical.

My draft does not deal with provisioning, it's aim is to simplify the implementation for the purposes of only discovery. In the case of a Data center interconnect environment, configuration will be for larger deployments via APIs that are supported.

The draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk<https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/> can help.
We have to make sure not to proliferate too many solutions to solve the same issue, although I’m in favour to
Use LLDP where it is applicable.
Best Regards,
Gabriele

I believe that this solution is the best approach for non OTN, non GMPLS, Data Center Interconnect transponder environments, which are new. From an operator perspective, it's minimal configuration and capitalizes on the already trending approach of LLDP snooping, but separating it out to give us freedom to create new optical related TLVs.

Cheers,

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Thu, Aug 18, 2016 at 8:21 AM, Gabriele Maria Galimberti (ggalimbe) <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

I think LLDP could be a good solution to physically check the Client to Network connectivity and
Communicate the Client info to the Network.
The other way around is not possible so the Client does not know who is connected to.
An external controller is then needed to complete and manage the connection.
If no External Controller is available then LMP is needed to close the loop.
This is applicable to the case where the Client is connected to Transponder (via a xGE).

In case of DWDM interface located in the Client the LLDP is not applicable a
Different signalling mechanism should be used to check the physical connectivity (like toggling the
Transceiver TX and the ROADM detecting the sequence at its port, this may work off line).
In this case either an external Controller is needed to drive the connectivity check or
An LMP protocol may help (running over the DCN).

The draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk<https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/> can help.

We have to make sure not to proliferate too many solutions to solve the same issue, although I’m in favour to
Use LLDP where it is applicable.

Best Regards,

Gabriele

[http://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[email-masked]<mailto:[email-masked]>
Phone :+39 039 2091462<tel:%2B39%20039%202091462>
Mobile :+39 335 7481947<tel:%2B39%20335%207481947>
Fax :+39 039 2092049<tel:%2B39%20039%202092049>

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Sarah Geisler <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 17 August 2016 at 01:11
To: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Gert,

In the draft, there is an option where frames can be inserted into the client data plane, and an option where there is no such functionality, so it takes the management address from the TLV sent by the router, and sends the frames out of band encapsulated in IP.

LLDP snooping only snoops the LLDP packet by splitting it out based on the destination MAC address (multicast) just before it hits the muxponding component. What we're is TLVs that may apply particularly to optical nodes, and mutual discovery rather than just one way (router -> optical node) discovery.

If LLDP isn't supported:

I'm suggesting an approach different to LMP, that I believe pushes in the right direction for Data Center Interconnect (separated out of the line system and the router). I've seen that DCI boxes are supporting LLDP snooping, this is just extending that to a new protocol, giving us freedom to add optical specific TLVs, and freedom to have separated out discovery between L2 and L1.

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Tue, Aug 16, 2016 at 11:05 AM, Gert Grammel <[email-masked]<mailto:[email-masked]>> wrote:

Sarah, Ruediger,

It appears to me that there is a misunderstanding in the pre-conditions. From the discussion I get:
Sarah: the optical device is capable to insert and extract MAC frames into the payload link between a router and the device. Hence LLDP is an option
Rüdiger: The optical device is transparent to MAC frames, hence LLDP is not an option, LMP however is.

What I haven’t got out of the exchange is:
—> if an optical device supports inband LLDP-snoopting what exactly is missing?
—> if an optical device does not support LLDP-snooping, what is the proposal besides LMP, or a variation thereof?

Thoughts?

Gert

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Sarah Geisler <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 16 August 2016 19:48
To: Ruediger Kunze <[email-masked]<mailto:[email-masked]>>
Cc: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Rüdiger,

There is no part of the protocol that actually defines the SDN approach, perhaps I should change that sentence to make it more clear. The only point I was making was that the information shared as a result of this protocol can be accessed across the router and optical domain by APIs in IP world or Transport world. One use case I'm familiar with for this would be inventory.

Right now, DCI boxes are moving towards LLDP snooping of LLDP packets coming from routers. If instead we change this to mutual discovery, an API could be used to periodically poll for the connectivity information, to help verify the inventory kept by organizations is correct by cross checking it with real data.

I don't discuss configuration of the ROADM from the router in this draft, it's more purely mutual discovery. What the draft aims for is - if we're going to move towards LLDP snooping (haven't seen LMP supported in DCI boxes yet), let's move towards an approach that allows mutual discovery, similar configuration, and simple implementation like LLDP, where there are no neighbor associations, we throw a frame out on the wire and whoever listens (if security allows too) gets the info.

From https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/):

   the DWDM network.

I'm seeing something different - multi vendor networks where the transponders are separated out from the router AND the line system, which is something new. Perhaps I need to add this particular use case and info in my draft too. Once the router, transponder, and line system are all decoupled and could be a combination of any vendor, I think this solution allows the router to discover what it needs to to make the life easier for the operator, in a light weight implementation.

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Tue, Aug 16, 2016 at 6:21 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sarah, all

I absolutely agree with your requirements from the operators perspective. What I am missing is a more detailed uses case especially when it comes to the automation part you are mention in your E-Mail. Which part plays SDN here?  A description of a  use case could help here to understand why LMP is not suitable.

Even if you have the transponder integrated in the router you have to discover the capabilities of that transponder and vice versa of the OLS, if you want to stay with the classic decentralized CP approach + multivendor.
In our framework document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/) we try to solve some issues by using LMP between the router and ROADM for example, especially in cases where you want to automate the wavelength setup process.

Br,
Rüdiger

Von: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Sarah Geisler
Gesendet: Montag, 15. August 2016 19:14
An: Dieter Beller
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

I think based on the feedback given, I should add a section outlining the difference between this approach and LMP. I will work on that and update a 02 version.

Sarah Geisler | Network Engineer | [email-masked]<mailto:[email-masked]> | +1 650 713 9641<tel:%2B1%20650%20713%209641>

On Fri, Aug 12, 2016 at 5:30 AM, Dieter Beller <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I am glad to see that this is now being discussed on the CCAMP list, which is IMHO the right WG dealing with these kind of technical topics.

Further discussion will also help us to draw a conclusion whether lmp or an lmp mechanism could be a solution to the problem addressed in
this new draft. Most optical devices today are encapsulating the client signal without looking into it (e.g. transparently mapping 10G Eth into
an ODU2e OTN container that is carried across the OTN in an OCH signal). Therefore, it needs to be carefully analyzed to what extent new
functionality is required for optical devices.

Thanks,
Dieter

Regards,

Xian

-----邮件原件-----

发件人: CCAMP [mailto:[email-masked]] 代表 Adrian Farrel

发送时间: 2016年8月11日 21:43

收件人: 'Fred Baker (fred)'; [email-masked]<mailto:[email-masked]>

抄送: [email-masked]<mailto:[email-masked]>

Adrian

-----Original Message-----

From: CCAMP [mailto:[email-masked]] On Behalf Of Fred Baker

(fred)

To: [email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]>

To: <[email-masked]><mailto:[email-masked]>

Reply-To: [email-masked]<mailto:[email-masked]>

directories.

       Authors         : Sarah Geisler

                         Fred Baker

     Pages           : 8

     Date            : 2016-08-07

Abstract:

  optical nodes.

ery/

0

submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Sarah Geisler <[email-masked]>
Date: Tue, 27 Sep 2016 09:26:22 -0700

+fred

Hi Jun,

Originally I did write this document as an LLDP extensions document. I
thought about it and opted for a separate protocol, but am open to feedback
on the best way. The reason I suggested it to be separated out was:

   1. Freedom to add optical specific TLVs without overrunning the LLDP
   protocol.
   2. LLDP is 'link layer discovery protocol', I don't consider optical
   devices link layer devices, although they MAY have link layer capabilities,
   they are traditionally operated and treated as Layer 1 nodes.
   3. When a user does 'show lldp neighbors', they would see optical AND
   link layer devices. As an automation engineer, if automation retrieved this
   information, I would have to write code to separate out optical and link
   layer devices manually (probably based on the hostname, or capabilities
   TLV). At worst it can be confusing, at best it just means extra code. As an
   optical operator, I believe the ability to type 'show lldp neighbors' and
   say 'show optical neighbors' separately is desirable.

Thank you for the feedback and let me know what you think!

On Tue, Sep 27, 2016 at 12:00 AM, qinjun (G) <[email-masked]> wrote:

> Hi Sarah,
>
>
>
> I think this is a very useful document, which targets on a real problem in
> the network and provides good analysis and candidate solutions. After
> reading the recent version of the draft, i have the following suggestions:
>
>
>
> 1)Shall the protocol be called as LLDP extensions instead of separated
> protocol, because most of the TLVs are reused from LLDP, and new TLVs can
> be defined in LLDP as needed.
>
>
>
> 2)If we don't consider separating out the network layers, could LLDP
> snooping implement the function? The draft gives the comparison with LMP,
> for the comprehensiveness of analysis, the LLDP snooping based mechanism
> may also be added into the draft, though some related discussion already
> happened on the list. If needed I will be glad to help with that.
>
>
>
> Best Regards.
>
>
>
> Jun
>
>
>
> *发件人:* CCAMP [mailto:[email-masked]] *代表 *Sarah Geisler
> *发送时间:* 2016年9月17日 2:54
> *收件人:* Gert Grammel
> *抄送:* [email-masked]
> *主题:* Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi All,
>
>
>
> After stepping back and checking what is there in LMP and in LLDP Sarah’s
> argument resonates with me. The client side would continue to use LLDP but
> made receptive to an out-of-band confirmation message.
>
> LMP would need to run a LinkVerify procedure that has to be implemented on
> Client and Server side. LMP also provides much more features like link
> *From: *Sarah Geisler <[email-masked]>
> *Date: *Friday 19 August 2016 19:31
> *To: *Gabriele Galimberti <[email-masked]>
> *Cc: *Gert Grammel <[email-masked]>, CCAMP <[email-masked]>
>
>
> *Subject: *Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi Gabriele,
>
>
>
>
>
> Hi All,
> It's a similar mechanism to LLDP, but not quite LLDP. Because the trend is
> going down the path of LLDP snooping, my approach was to split this out
> into a new protocol.
>
>
>
> What about for Data Center Interconnect Platform cases? this is a use case
> we have not addressed and I am trying to address in this draft. Multiple
> vendors have developed these style of devices so the router, transponder
> and line system are all separated out. In this case, LMP is not available
> from vendors and LLDP snooping has been used instead. I am suggesting we
> create a separated out protocol but using a similar mechanism to LLDP
> (either with direct injection with the layer 2 device in the DCI box, or
> via out of band mechanism). My draft differs from LMP, it doesn't require
> neighbor configuration and just takes the management IP address from the
> management address TLV sent by the router and sends the responding Optical
> Device Discovery packet to that address. Like this, they discover each
> other.
>
>
>
> I believe that this solution is the best approach for non OTN, non GMPLS,
> Data Center Interconnect transponder environments, which are new. From an
> operator perspective, it's minimal configuration and capitalizes on the
> already trending approach of LLDP snooping, but separating it out to give
> us freedom to create new optical related TLVs.
>
>
>
> Cheers,
>
>
>
>
> [email-masked] <[email-masked]>*
> *From: *CCAMP <[email-masked]> on behalf of Sarah Geisler <
> [email-masked]>
> *Date: *Wednesday 17 August 2016 at 01:11
> *To: *Gert Grammel <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
>
> *Subject: *Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi Gert,
>
>
>
> LLDP snooping only snoops the LLDP packet by splitting it out based on the
> destination MAC address (multicast) just before it hits the muxponding
> I'm suggesting an approach different to LMP, that I believe pushes in the
> right direction for Data Center Interconnect (separated out of the line
> Sarah: the optical device is capable to insert and extract MAC frames into
> the payload link between a router and the device. Hence LLDP is an option
>
> *From: *CCAMP <[email-masked]> on behalf of Sarah Geisler <
> [email-masked]>
> *Date: *Tuesday 16 August 2016 19:48
> *To: *Ruediger Kunze <[email-masked]>
> *Cc: *CCAMP <[email-masked]>
> *Subject: *Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi Rüdiger,
>
>
>
> There is no part of the protocol that actually defines the SDN approach,
> perhaps I should change that sentence to make it more clear. The only point
> I was making was that the information shared as a result of this protocol
> can be accessed across the router and optical domain by APIs in IP world or
> Transport world. One use case I'm familiar with for this would be inventory.
>
>
>
> I don't discuss configuration of the ROADM from the router in this draft,
> it's more purely mutual discovery. What the draft aims for is - if we're
> going to move towards LLDP snooping (haven't seen LMP supported in DCI
> boxes yet), let's move towards an approach that allows mutual discovery,
> similar configuration, and simple implementation like LLDP, where there are
> no neighbor associations, we throw a frame out on the wire and whoever
> listens (if security allows too) gets the info.
>
>
>
> I absolutely agree with your requirements from the operators perspective.
> What I am missing is a more detailed uses case especially when it comes to
> the automation part you are mention in your E-Mail. Which part plays SDN
> here?  A description of a  use case could help here to understand why LMP
> is not suitable.
>
>
>
> doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/) we try to solve some issues
> by using LMP between the router and ROADM for example, especially in cases
> where you want to automate the wavelength setup process.
>
>
>
>
>
> Br,
>
> Rüdiger
>
>
>
>
>
>
>
> *Betreff:* Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> I think based on the feedback given, I should add a section outlining the
> difference between this approach and LMP. I will work on that and update a
> 02 version.
>
>
>
> On Fri, Aug 12, 2016 at 5:30 AM, Dieter Beller <[email-masked]>
> wrote:
>
> Hi all,
>
> I am glad to see that this is now being discussed on the CCAMP list, which
> is IMHO the right WG dealing with these kind of technical topics.
>
> Further discussion will also help us to draw a conclusion whether lmp or
> an lmp mechanism could be a solution to the problem addressed in
> this new draft. Most optical devices today are encapsulating the client
> signal without looking into it (e.g. transparently mapping 10G Eth into
> an ODU2e OTN container that is carried across the OTN in an OCH signal).
> Therefore, it needs to be carefully analyzed to what extent new

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 29 Sep 2016 09:46:32 +0000

Hi Sarah,

I totally agree with your 3 bullets below, and this is why I’m still struggling to understand why you chose to use LLDP and not LMP.

BR
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Sarah Geisler
Sent: martedì 27 settembre 2016 18:26
To: qinjun (G) <[email-masked]>
Cc: [email-masked]; Fred Baker <[email-masked]>
Subject: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

+fred

Hi Jun,

Originally I did write this document as an LLDP extensions document. I thought about it and opted for a separate protocol, but am open to feedback on the best way. The reason I suggested it to be separated out was:

  1.  Freedom to add optical specific TLVs without overrunning the LLDP protocol.
  2.  LLDP is 'link layer discovery protocol', I don't consider optical devices link layer devices, although they MAY have link layer capabilities, they are traditionally operated and treated as Layer 1 nodes.
  3.  When a user does 'show lldp neighbors', they would see optical AND link layer devices. As an automation engineer, if automation retrieved this information, I would have to write code to separate out optical and link layer devices manually (probably based on the hostname, or capabilities TLV). At worst it can be confusing, at best it just means extra code. As an optical operator, I believe the ability to type 'show lldp neighbors' and say 'show optical neighbors' separately is desirable.

On Tue, Sep 27, 2016 at 12:00 AM, qinjun (G) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sarah,

Best Regards.

Jun

发件人: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] 代表 Sarah Geisler
发送时间: 2016年9月17日 2:54
收件人: Gert Grammel
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi All,

network domains.

Sarah

Cheers,

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

Best

Gert

Hi Gabriele,

Hi All,

Cheers,

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

   the DWDM network.

Br,
Rüdiger

Thanks,
Dieter

Regards,

Xian

-----邮件原件-----

发送时间: 2016年8月11日 21:43

Adrian

-----Original Message-----

(fred)

directories.

       Authors         : Sarah Geisler

                         Fred Baker

     Pages           : 8

     Date            : 2016-08-07

Abstract:

  optical nodes.

ery/

0

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 29 Sep 2016 10:18:51 +0000

Hi all,

We all know that LMP is definitely in the scope of CCAMP, but I am not sure if it is appropriate to define LLDP extensions in CCAMP.

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2016年9月29日 17:47
收件人: Sarah Geisler; qinjun (G)
抄送: [email-masked]; Fred Baker
主题: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Sarah,

BR
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Sarah Geisler
Sent: martedì 27 settembre 2016 18:26
To: qinjun (G) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Fred Baker <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

+fred

Hi Jun,

Best Regards.

Jun

Hi All,

network domains.

Sarah

Cheers,

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

Best

Gert

Hi Gabriele,

Hi All,

Cheers,

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

   the DWDM network.

Br,
Rüdiger

Thanks,
Dieter

Regards,

Xian

-----邮件原件-----

发送时间: 2016年8月11日 21:43

Adrian

-----Original Message-----

(fred)

directories.

       Authors         : Sarah Geisler

                         Fred Baker

     Pages           : 8

     Date            : 2016-08-07

Abstract:

  optical nodes.

ery/

0

CCAMP mailing list

CCAMP mailing list

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 29 Sep 2016 11:24:10 +0000

That is true.

I wanted to understand the reason for choosing LLDP vs LMP, since the motivations below seems to be driving the choice towards LMP.

If we end up saying that LLDP is the right choice we’ll sort out how to manage it (involving the IEEE)

BR
Daniele

From: Fatai Zhang [mailto:[email-masked]]
Sent: giovedì 29 settembre 2016 12:19
To: Daniele Ceccarelli <[email-masked]>; Sarah Geisler <[email-masked]>; qinjun (G) <[email-masked]>
Cc: [email-masked]; Fred Baker <[email-masked]>
Subject: 答复: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi all,

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2016年9月29日 17:47
收件人: Sarah Geisler; qinjun (G)
抄送: [email-masked]<mailto:[email-masked]>; Fred Baker
主题: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Sarah,

BR
Daniele

+fred

Hi Jun,

Best Regards.

Jun

Hi All,

network domains.

Sarah

Cheers,

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

Best

Gert

Hi Gabriele,

Hi All,

Cheers,

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

   the DWDM network.

Br,
Rüdiger

Thanks,
Dieter

Regards,

Xian

-----邮件原件-----

发送时间: 2016年8月11日 21:43

Adrian

-----Original Message-----

(fred)

directories.

       Authors         : Sarah Geisler

                         Fred Baker

     Pages           : 8

     Date            : 2016-08-07

Abstract:

  optical nodes.

ery/

0

CCAMP mailing list

CCAMP mailing list

---

From: Sarah Geisler <[email-masked]>
Date: Thu, 29 Sep 2016 10:35:53 -0700

Hi Daniele, Fatai,

In this draft I outline the differences between this solution and LMP. LMP
has not been implemented so far in Data Center Interconnect devices and the
industry has moved towards something an LLDP snooping mechanism.

In this draft I am not suggesting LLDP, I am suggesting a separated out
protocol that looks like LLDP, but is for optical layer discovery.

On Thu, Sep 29, 2016 at 4:24 AM, Daniele Ceccarelli <
[email-masked]> wrote:

> That is true.
>
>
>
> I wanted to understand the reason for choosing LLDP vs LMP, since the
> motivations below seems to be driving the choice towards LMP.
>
>
>
> *From:* Fatai Zhang [mailto:[email-masked]]
> *Sent:* giovedì 29 settembre 2016 12:19
> *To:* Daniele Ceccarelli <[email-masked]>; Sarah Geisler
> <[email-masked]>; qinjun (G) <[email-masked]>
> *Cc:* [email-masked]; Fred Baker <[email-masked]>
> *Subject:* 答复: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi all,
>
>
>
> We all know that LMP is definitely in the scope of CCAMP, but I am not
> sure if it is appropriate to define LLDP extensions in CCAMP.
>
>
>
>
>
>
>
>
>
> Thanks
>
>
>
> Fatai
>
>
>
> *发件人**:* CCAMP [mailto:[email-masked] <[email-masked]>]
> *代表* Daniele Ceccarelli
> *发送时间**:* 2016年9月29日 17:47
> *收件人**:* Sarah Geisler; qinjun (G)
> *抄送**:* [email-masked]; Fred Baker
> *主题**:* Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi Sarah,
>
>
>
> I totally agree with your 3 bullets below, and this is why I’m still
> struggling to understand why you chose to use LLDP and not LMP.
>
>
>
> BR
> Daniele
>
>
>
> *From:* CCAMP [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Sarah Geisler
> *Sent:* martedì 27 settembre 2016 18:26
> *To:* qinjun (G) <[email-masked]>
> *Cc:* [email-masked]; Fred Baker <[email-masked]>
> *Subject:* Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> +fred
>
>
>
> Hi Jun,
>
>
>
> *发件人**:* CCAMP [mailto:[email-masked]] *代表* Sarah Geisler
> *发送时间**:* 2016年9月17日 2:54
> *收件人**:* Gert Grammel
> *抄送**:* [email-masked]
>
> *主**题**:* Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi All,
>
>
>
> Phone :*+39 039 2091462* <%2B39%20039%202091462>
> Mobile :*+39 335 7481947* <%2B39%20335%207481947>
> Fax :*+39 039 2092049* <%2B39%20039%202092049>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: John E Drake <[email-masked]>
Date: Thu, 29 Sep 2016 18:27:11 +0000

Sarah,

What is the difference between asking your vendor to implement LMP and asking them to implement a “separated out protocol that looks like LLDP”?  The former has the benefits of being designed for this application and being already specified.

(I do understand that it’s more fun to design something new and that the purpose of the IETF is to make all of its protocols functionally equivalent.)

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Sarah Geisler
Sent: Thursday, September 29, 2016 1:36 PM
To: Daniele Ceccarelli <[email-masked]>
Cc: [email-masked]; Fred Baker <[email-masked]>
Subject: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi Daniele, Fatai,

In this draft I outline the differences between this solution and LMP. LMP has not been implemented so far in Data Center Interconnect devices and the industry has moved towards something an LLDP snooping mechanism.

In this draft I am not suggesting LLDP, I am suggesting a separated out protocol that looks like LLDP, but is for optical layer discovery.

On Thu, Sep 29, 2016 at 4:24 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:
That is true.

BR
Daniele

From: Fatai Zhang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: giovedì 29 settembre 2016 12:19
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Sarah Geisler <[email-masked]<mailto:[email-masked]>>; qinjun (G) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Fred Baker <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

Hi all,

Thanks

Fatai

Hi Sarah,

BR
Daniele

+fred

Hi Jun,

Best Regards.

Jun

Hi All,

network domains.

Sarah

Cheers,

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

Best

Gert

Hi Gabriele,

Hi All,

Cheers,

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

   the DWDM network.

Br,
Rüdiger

Thanks,
Dieter

Regards,

Xian

-----邮件原件-----

发送时间: 2016年8月11日 21:43

Adrian

-----Original Message-----

(fred)

directories.

       Authors         : Sarah Geisler

                         Fred Baker

     Pages           : 8

     Date            : 2016-08-07

Abstract:

  optical nodes.

ery/

0

CCAMP mailing list

CCAMP mailing list

---

From: Sarah Geisler <[email-masked]>
Date: Thu, 29 Sep 2016 11:54:10 -0700

John,

I feel that LMP has a lot of complexity just for the simple act of
discovery. LLDP is suitable to the DCI solutions where the transponder is a
separate chassis from the line system (and likely a different vendor), and
where a layer 2 switch may be included in the DCI box to communicate with
the clients.

I'm just considering what issues I have seen whilst working as a DWDM and
Network operator and customer, and the solutions that have been favorable
in industry. I see that a simple transmission of a frame with x information
in it is simple to implement, and useful, and requires minimal
configuration.

On a more general level, is the suggestion that we can't explore any other
options because we already solved it in another solution? There are
multiple solutions to issues that are suited to different network
architectures. LLDP snooping in the architectures I'm aware of is the
preferred solution. All I'm thinking is "let's not overcrowd LLDP, let's
separate it out, it will be cleaner, and allow us to add more specific TLVs
without LLDP folks wanting their protocol back".

I appreciate your feedback.

Sarah

On Thu, Sep 29, 2016 at 11:27 AM, John E Drake <[email-masked]> wrote:

> Sarah,
>
>
>
> What is the difference between asking your vendor to implement LMP and
> asking them to implement a “separated out protocol that looks like LLDP”?
> The former has the benefits of being designed for this application and
> being already specified.
>
>
>
> (I do understand that it’s more fun to design something new and that the
> purpose of the IETF is to make all of its protocols functionally
> equivalent.)
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* CCAMP [mailto:[email-masked]] *On Behalf Of *Sarah Geisler
> *Sent:* Thursday, September 29, 2016 1:36 PM
> *To:* Daniele Ceccarelli <[email-masked]>
>
> *Subject:* Re: [CCAMP]
> 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt
>
>
>
> Hi Daniele, Fatai,
>
>
>
> *发件人**:* CCAMP [mailto:[email-masked] <[email-masked]>] *代表
> *Daniele Ceccarelli
> *主**题:* Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-
> discovery-00.txt
>
>
>
> Hi All,
>
>
>
> ...
> [Message clipped]

---

From: John E Drake <[email-masked]>
Date: Thu, 29 Sep 2016 19:31:55 +0000

Sarah,

Comments inline.

Yours Irrespectively,

John

From: Sarah Geisler [mailto:[email-masked]]
Sent: Thursday, September 29, 2016 2:54 PM
To: John E Drake <[email-masked]>
Cc: Daniele Ceccarelli <[email-masked]>; [email-masked]; Fred Baker <[email-masked]>
Subject: Re: [CCAMP] 答复: Fwd: I-D Action: draft-geisler-optical-device-discovery-00.txt

John,

I feel that LMP has a lot of complexity just for the simple act of discovery. LLDP is suitable to the DCI solutions where the transponder is a separate chassis from the line system (and likely a different vendor), and where a layer 2 switch may be included in the DCI box to communicate with the clients.

[JD]  As I recall, and it has been many years, LMP is divided into functional blocks and a node indicates to its peers which of those blocks it supports.  This allows an implementation that can be tailored to a specific deployment scenario. .  (It also has a defined out-of-band control channel to deal with optical devices that can’t peak into the data plane.)   Also, I think it is a fair statement that all new protocols start out simple and end up being arbitrarily complex

I'm just considering what issues I have seen whilst working as a DWDM and Network operator and customer, and the solutions that have been favorable in industry. I see that a simple transmission of a frame with x information in it is simple to implement, and useful, and requires minimal configuration.

On a more general level, is the suggestion that we can't explore any other options because we already solved it in another solution? There are multiple solutions to issues that are suited to different network architectures. LLDP snooping in the architectures I'm aware of is the preferred solution. All I'm thinking is "let's not overcrowd LLDP, let's separate it out, it will be cleaner, and allow us to add more specific TLVs without LLDP folks wanting their protocol back".

[JD]  This is for the WG to decide.  However, I have almost never seen a case in which given the choice between doing something new and re-using an existing solution, the choice of the latter is made and I think that is extremely unfortunate in so many dimensions.

Sarah

On Thu, Sep 29, 2016 at 11:27 AM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Sarah,

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sarah Geisler
Sent: Thursday, September 29, 2016 1:36 PM
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>

Subject: Re: [CCAMP]

Hi Daniele, Fatai,

BR
Daniele

Hi all,

Thanks

Fatai

Hi Sarah,

BR
Daniele

+fred

Hi Jun,

Best Regards.

Jun

Hi All,

network domains.

Sarah

Cheers,

Servers / Clients

 C:Non-LLDP capable

 C:LLDP + add-on

C:LLDP capable

 S:Non-LLDP capable

 Use LMP

Use LMP

Use LMP

 S:LLDP snooping

Use LMP

Device-discovery-00

Device-discovery-00

 S:LLDP capable

Use LMP

n/a

LLDP

Best

Gert

Hi Gabriele,

Hi All,

Cheers,

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

[Message clipped]

---

From: Sarah Geisler <[email-masked]>
Date: Thu, 29 Sep 2016 13:47:33 -0700

Hi John,

I understand your point of view. I don't see this as a replacement for LMP,
but just another option. I guess the other way I look at this is - if
vendors are doing this already (they are) with LLDP, maybe we should
separate and standardize it while we still can to give some leeway for
future TLVs.

On Thu, Sep 29, 2016 at 12:31 PM, John E Drake <[email-masked]> wrote:

> Sarah,
>
>
>
> Comments inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Sarah Geisler [mailto:[email-masked]]
> *Sent:* Thursday, September 29, 2016 2:54 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* Daniele Ceccarelli <[email-masked]>; [email-masked];
> Fred Baker <[email-masked]>
> *[JD]  As I recall, and it has been many years, LMP is divided into
> functional blocks and a node indicates to its peers which of those blocks
> it supports.  This allows an implementation that can be tailored to a
> specific deployment scenario. .  (It also has a defined out-of-band control
> channel to deal with optical devices that can’t peak into the data
> plane.)   Also, I think it is a fair statement that all new protocols start
> out simple and end up being arbitrarily complex*
>
>
>
> *[JD]  This is for the WG to decide.  However, I have almost never seen a
> case in which given the choice between doing something new and re-using an
> existing solution, the choice of the latter is made and I think that is
> extremely unfortunate in so many dimensions.*
>
>
>