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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Aug 2016 14:43:10 +0100

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]] 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]>
> > 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-discovery/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-geisler-optical-device-discovery-00
> >
> >
> > 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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 12 Aug 2016 01:15:16 +0000

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]] 代表 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

> 
> We have mentioned this to opsawg, but the ccamp chairs suggest that 
> ccamp may be a better venue. Your comments are welcome.
> 
directories.
> > 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-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

---

From: Sarah Geisler <[email-masked]>
Date: Fri, 12 Aug 2016 15:02:31 +1000

I think Adrian is right that LMP is solving some of this. I also think he
is right to say I coupled LMP and GMPLs maybe a little too tightly. I see
this draft has just a different approach to LMP, definitely not a
replacement for it, but it gives options for more simplistic approaches.
The kinds of things I have in mind was automation and inventory, making
this information available to a higher software layer that builds a full
view of the network and how it's connected based on this information.

With DCI (Data Center Interconnect) DWDM boxes being the new flavor, I'm
not seeing LMP being supported on these boxes where the transponding and
line system is completely separated. Ive also seen DCI boxes with Layer 2
functionality, which seemed new to me and gives an opportunity for direct
injection of L2 packets approach, rather than using overhead bits on lower
layers or an OOB approach.

I haven't seen LMP supported by DCI, but I have seen a push towards LLDP
snooping on these DCI boxes.

I’m also seeing a lot of Alien wave requirements. I’m unsure on the status
of LMP support across multiple vendors i.e. - Vendor A Router -> Vendor C
Transponder -> Vendor C line system. Perhaps folks with more history can
keep me honest there.

This draft doesn't use a control channel, it just throws a packet out on
the wire and if you are listen, you get the info. There is no negotiations
or hello packets, config packets, etc. It runs very similar to LLDP and
that simplicity when all you need is to discover, is an attractive
implementation.

I definitely believe there is overlap as spoken about in this conversation.
I just think the simplicity of this approach is worth looking at,
especially given the industry seems to be pushing towards LLDP snooping
discovery on DCI boxes.

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

On Fri, Aug 12, 2016 at 11:15 AM, Zhangxian (Xian) <[email-masked]>
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
>
> -----邮件原件-----

---

From: Dieter Beller <[email-masked]>
Date: Fri, 12 Aug 2016 14:30:45 +0200

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:

Regards,
Xian

-----邮件原件-----
发件人: CCAMP [mailto:[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

Adrian

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Fred Baker
(fred)
Sent: 11 August 2016 02:05
To: [email-masked]
Subject: [CCAMP] Fwd: I-D Action:

directories.

Abstract:

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

---

From: Sarah Geisler <[email-masked]>
Date: Mon, 15 Aug 2016 10:14:25 -0700

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.

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
> On 12.08.2016 03:15, Zhangxian (Xian) wrote:
>
> 发件人: CCAMP [mailto:[email-masked] <[email-masked]>] 代表 Adrian Farrel
> 发送时间: 2016年8月11日 21:43
> From: CCAMP [mailto:[email-masked] <[email-masked]>] On Behalf Of Fred Baker
> (fred)
> To: <[email-masked]> <[email-masked]>
> 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
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> I-D-Announce mailing [email-masked]://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 [email-masked]://www.ietf.org/mailman/listinfo/ccamp
> CCAMP mailing [email-masked]://www.ietf.org/mailman/listinfo/ccamp
>
>
>

---

From: <[email-masked]>
Date: Tue, 16 Aug 2016 13:21:20 +0000

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.

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

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

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

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

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

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

Adrian

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

(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, 16 Aug 2016 10:48:05 -0700

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!

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
>
>
>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 16 Aug 2016 18:05:41 +0000

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]<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/):

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.

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

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

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

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: Tue, 16 Aug 2016 16:11:07 -0700

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.

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

> 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
> —> 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]>
> To: Ruediger Kunze <[email-masked]>
> Cc: CCAMP <[email-masked]>
>> *Betreff:* Re: [CCAMP] Fwd: I-D Action: draft-geisler-optical-device-d
>> iscovery-00.txt
>>
>>
>>
>> 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.
>>

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 18 Aug 2016 01:13:11 +0000

Hi Sarah,

I think maybe some people are still a little bit confused.

I am not sure if you have had a look at this draft (https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/)?

If no, I would suggest you take a look.

I think it is better to describe your use cases and requriements clearly before talking about solutions.

Do you think if the draft (https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/) can cover your use cases (and requirements) or it should be extended to cover them?

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Sarah Geisler
发送时间: 2016年8月17日 7:11
收件人: Gert Grammel
抄送: [email-masked]
主题: 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.

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

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: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Thu, 18 Aug 2016 15:21:08 +0000

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

[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
Mobile :+39 335 7481947
Fax :+39 039 2092049

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,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

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: Fri, 19 Aug 2016 10:31:19 -0700

Hi Gabriele,

Hi All,
> 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

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.

> Transceiver TX and the ROADM detecting the sequence at its port, this may

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.

>  1 - In–band signalling available

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.

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,

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

> 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.
>
> *Gabriele Galimberti*
> *Cisco Photonics Srl*
> 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>*
>
>
>
>
>
>
>
>
>
>
>
>
>
> To: Gert Grammel <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
>> 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
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>

---

From: Gert Grammel <[email-masked]>
Date: Fri, 19 Aug 2016 18:38:38 +0000

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,

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.

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.

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.

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.

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,

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

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

[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>

Hi Gert,

If LLDP isn't supported:

Sarah, Ruediger,

Thoughts?

Gert

Hi Rüdiger,

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: Tue, 23 Aug 2016 22:44:19 -0700

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.

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]>
> To: Gabriele Galimberti <[email-masked]>
> Cc: Gert Grammel <[email-masked]>, CCAMP <[email-masked]>
>
>> 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 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.
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>> signal). Therefore, it needs to be carefully analyzed to what extent new

---

From: Sarah Geisler <[email-masked]>
Date: Mon, 29 Aug 2016 16:43:03 -0700

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,

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

>> 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
>> 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'm suggesting an approach different to LMP, that I believe pushes in
>>> the right direction for Data Center Interconnect (separated out of the line
>>>> It appears to me that there is a misunderstanding in the
>>>> pre-conditions. From the discussion I get:
>>>> 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.
>>>>
>>>>> On Fri, Aug 12, 2016 at 5:30 AM, Dieter Beller <
>>>>> [email-masked]> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> client signal without looking into it (e.g. transparently mapping 10G Eth
>>>>> into