Subject: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

From: Robert Sparks <[email-masked]>
Date: Wed, 02 Sep 2015 15:04:07 -0500

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-flexigrid-lambda-label-04
Reviewer: Robert Sparks
Review Date: 2 Sep 2015
IETF LC End Date: 9 Sep 2015
IESG Telechat date: Not yet scheduled for a telechat

Summary: Ready for publication as a Proposed Standard

One thing I'd like to check, and I suspect this pokes at a conversation 
that has already happened (as hinted in the acknowledgements section):

The discussion of managements systems having to deal with a 64 bit 
wavelength label caught my eye. This is an RFC3471 section 3.2.1.1 label 
isn't it? That document shows wavelength labels as 32 bit things. Has 
something updated 3471 to say to expect a multiple of 32 bits, and not 
32 bits specifically? If not, maybe this document would be a good place 
to do so explicitly, rather than what appears to be fiat at the moment?

micro-nit: at the end of the introduction "in that regard" suggests the 
document updates the work of the ITU-T in some other regard? I suggest 
simple deleting the phrase.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Sep 2015 08:11:27 +0100

Hi Robert,

Thanks for reading.

> Summary: Ready for publication as a Proposed Standard

Excellent diagnosis :-)

> to do so explicitly, rather than what appears to be fiat at the moment?

Yeah, 6205 updates 3471 (as noted in this I-D), but still only makes a 32 bit lambda label.

But 3.2 of 3471 makes clear that a label is of variable length according to the type. And also that the type is supposed to be known a priori (since otherwise you would go crazy) by both ends of a link.

But an implementation expecting a 32 bit lambda label would not barf ungracefully because the first 32 bits follow the format of 6205. It would look at them and not recognise the grid type (new value from IANA) and so give up on the whole message. And this is good because if you don't support flexigrid labels you simply can't process any of the related signaling.

Thus, we think that the only thing that needs fixing (external to the implementation that has to support flexigrid labels) is the management system that might be inspecting LSPs within the network.

> simple deleting the phrase.

Micro-ack.

Cheers,
Adrian

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 8 Sep 2015 14:45:37 +0000

Hi Robert, 

Thanks for the careful review and your comments. 
I pretty much agree with Adrian's reply but I think explicitly having some backward compatibility text in the draft could be helpful.

Adrian, authors, I'd suggest changing section 5 from "Manageability Considerations" to "Backward Compatibility and Manageability Considerations" adding to the existing text backward compatibility considerations against legacy GMPLS and legacy NMS (mostly what you've already written below). 
WRT the legacy NMS I don't think it is a reasonable scenario, since before operating the nodes with a GMPLS implementing this draft, the node needs to be configured and the NMS must be flexi-grid compatible.

Robert, would this address your concerns?

Many thanks
Daniele

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: giovedì 3 settembre 2015 09:11
> To: 'Robert Sparks'; [email-masked];
> [email-masked]; 'General Area Review Team'; [email-masked]
> Subject: RE: Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
> 
> Hi Robert,
> 
> Thanks for reading.
> 
> > One thing I'd like to check, and I suspect this pokes at a
> > conversation that has already happened (as hinted in the
> acknowledgements section):
> >
> > wavelength label caught my eye. This is an RFC3471 section 3.2.1.1
> > label isn't it? That document shows wavelength labels as 32 bit
> > things. Has something updated 3471 to say to expect a multiple of 32
> > bits, and not
> > 32 bits specifically? If not, maybe this document would be a good
> > place to do so explicitly, rather than what appears to be fiat at the
> moment?
> 
> But 3.2 of 3471 makes clear that a label is of variable length according to the
> type. And also that the type is supposed to be known a priori (since otherwise
> you would go crazy) by both ends of a link.
> 
> But an implementation expecting a 32 bit lambda label would not barf
> ungracefully because the first 32 bits follow the format of 6205. It would
> look at them and not recognise the grid type (new value from IANA) and so
> give up on the whole message. And this is good because if you don't support
> flexigrid labels you simply can't process any of the related signaling.
> 
> Thus, we think that the only thing that needs fixing (external to the
> implementation that has to support flexigrid labels) is the management
> system that might be inspecting LSPs within the network.
> 
> > micro-nit: at the end of the introduction "in that regard" suggests
> > the document updates the work of the ITU-T in some other regard? I
> > suggest simple deleting the phrase.
> 
> Micro-ack.
> 
> Cheers,
> Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Sep 2015 17:01:41 +0100

Hi Daniele,

> I pretty much agree with Adrian's reply but I think explicitly having some
> backward compatibility text in the draft could be helpful.
> 
> Adrian, authors, I'd suggest changing section 5 from "Manageability
> Considerations" to "Backward Compatibility and Manageability Considerations"
> adding to the existing text backward compatibility considerations against legacy
> GMPLS and legacy NMS (mostly what you've already written below).

I can work on this.

> WRT the legacy NMS I don't think it is a reasonable scenario, since before
> operating the nodes with a GMPLS implementing this draft, the node needs to be
> configured and the NMS must be flexi-grid compatible.

But wait! This is exactly the point.
Suppose there is an NMS that is inspecting an LSP at a transit node. 
That NMS does not need to be flexigrid compatible to read the details of the LSP at that transit node.
However, it *does* need to have some capabilities in order to not barf when it gets the response from the LSR.
The first thing is to handle a 64 bit label as an opaque string.
The advanced thing is to be able to parse out the 64 bits into the relevant fields.

Indeed, to request the setup of a flexigrid LSP does not require a flexigrid compatible NMS since it is possible to simply request a path and bandwidth (or not even request a path).

My contention is that it is quite likely that someone would try to use a legacy NMS to manage a new flexigrid network since "it is all just GMPLS". And it is not an unreasonable assumption to be able to do this if some fields (for example, label) can be displayed as opaque quantities.

Now, if you are talking about an EMS, I completely agree.

Cheers,
Adrian

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 9 Sep 2015 07:41:22 +0000

Hi Adrian,

I tend disagree with this statement:

"My contention is that it is quite likely that someone would try to use a legacy NMS to manage a new flexigrid network since "it is all just GMPLS". And it is not an unreasonable assumption to be able to do this if some fields (for example, label) can be displayed as opaque quantities."

I'm not sure an operator would be happy to see 96 channels called lambda1, lambda2,..., lambda 96 from his NMS while the network is flexi grid.
We'll have to face these issues when we'll be speaking about YANG models for flexi grid but for the time being let's be on the safe side and address the compatibility issue as you're suggesting.

Cheers,
Daniele

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: martedì 8 settembre 2015 18:02
> To: Daniele Ceccarelli; 'Adrian Farrel'; 'Robert Sparks'; draft-ietf-ccamp-
> [email-masked]; [email-masked]; 'General Area Review
> Team'; [email-masked]
> > I pretty much agree with Adrian's reply but I think explicitly having
> > some backward compatibility text in the draft could be helpful.
> >
> > adding to the existing text backward compatibility considerations
> > against legacy GMPLS and legacy NMS (mostly what you've already written
> below).
> 
> I can work on this.
> 
> > WRT the legacy NMS I don't think it is a reasonable scenario, since
> > before operating the nodes with a GMPLS implementing this draft, the
> > node needs to be configured and the NMS must be flexi-grid compatible.
> 
> Indeed, to request the setup of a flexigrid LSP does not require a flexigrid
> compatible NMS since it is possible to simply request a path and bandwidth
> (or not even request a path).
> 
> My contention is that it is quite likely that someone would try to use a legacy
> NMS to manage a new flexigrid network since "it is all just GMPLS". And it is
> not an unreasonable assumption to be able to do this if some fields (for
> example, label) can be displayed as opaque quantities.
>

---

From: <[email-masked]>
Date: Wed, 9 Sep 2015 10:52:33 +0200

Ciao Daniele.

SP's hat on, I need to disagree with you there.

What Adrian proposes allows me to add new pieces of equipment to address 
traffic needs, without waiting for an NMS release supporting 100% of the 
feature I use. In this situation, I can choose between upgrading or 
waiting for the full package alignment: it remains my call, on a case by 
case basis. The wording also emphasizes the generalized beauty of GMPLS: 
new label encodings should not prevent the management of other protocol 
aspects ("be liberal in what you accept...).

What you suggest would prohibit that scenario, i.e., I need wait for 
fully-featured NMS, whatever the network is capable of. This is 
sometimes not acceptable: service needs prevail on fully detailed 
management, the NMS should not be a network limitation. The current 
example, where label resolution could rely on a (temporary?) external 
tool, makes it even more realistic.

Regards,

Julien

Sep. 09, 2015 - [email-masked]:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 9 Sep 2015 09:00:31 +0000

Hi Julien,

Thanks for providing and operator point of view and for proving I'm wrong :)
We have one more reason to update the draft with the backward compatibility statements then.

Thanks a lot,
Daniele

> From: [email-masked] [mailto:[email-masked]]
> Sent: mercoledì 9 settembre 2015 10:53
> To: Daniele Ceccarelli; [email-masked]; 'Adrian Farrel'; 'Robert Sparks';
> [email-masked]; [email-masked]; 'General
> Area Review Team'; [email-masked]
> Subject: Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-
> label-04
> 
> Ciao Daniele.
> 
> feature I use. In this situation, I can choose between upgrading or waiting for
> the full package alignment: it remains my call, on a case by case basis. The
> wording also emphasizes the generalized beauty of GMPLS:
> What you suggest would prohibit that scenario, i.e., I need wait for fully-
> featured NMS, whatever the network is capable of. This is sometimes not
> acceptable: service needs prevail on fully detailed management, the NMS
> should not be a network limitation. The current example, where label
> resolution could rely on a (temporary?) external tool, makes it even more
> realistic.
> 
> Regards,
> 
> Julien
> 
> 
> > "My contention is that it is quite likely that someone would try to use a
> legacy NMS to manage a new flexigrid network since "it is all just GMPLS".
> And it is not an unreasonable assumption to be able to do this if some fields
> (for example, label) can be displayed as opaque quantities."
> >
> > I'm not sure an operator would be happy to see 96 channels called
> lambda1, lambda2,..., lambda 96 from his NMS while the network is flexi
> grid.
> > We'll have to face these issues when we'll be speaking about YANG models
> for flexi grid but for the time being let's be on the safe side and address the
> compatibility issue as you're suggesting.
> >
> > Cheers,
> > Daniele
> >
> >>> I pretty much agree with Adrian's reply but I think explicitly
> >>> having some backward compatibility text in the draft could be helpful.
> >>>
> >> However, it *does* need to have some capabilities in order to not
> >> barf when it gets the response from the LSR.
> >> Indeed, to request the setup of a flexigrid LSP does not require a
> >> flexigrid compatible NMS since it is possible to simply request a
> >> path and bandwidth (or not even request a path).
> >>
> >> My contention is that it is quite likely that someone would try to
> >> use a legacy NMS to manage a new flexigrid network since "it is all
> >> just GMPLS". And it is not an unreasonable assumption to be able to
> >> do this if some fields (for example, label) can be displayed as opaque
> quantities.
> >>
> ______________________________________________________________
> ___________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Sep 2015 15:36:01 -0500

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-ccamp-flexigrid-lambda-label
Reviewer: Robert Sparks
Review Date: 14 Sep 2015
IETF LC End Date: past
IESG Telechat date: 17 Sep 2015

Summary: (still) Ready for publication as Proposed Standard

Thanks for the improvements in -05.

On 9/2/15 3:04 PM, Robert Sparks wrote:
> bits, and not 32 bits specifically? If not, maybe this document would 
> be a good place to do so explicitly, rather than what appears to be 
> fiat at the moment?
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Sep 2015 09:04:27 -0700

Thank you very much Robert again for the review. I have placed a no-objection position
for this document in the upcoming IESG telechat.

Jari