[CCAMP] Raw notes from Toronto

[Lou Berger <[e-mail]>]

Thank to all/any who contributed to the notes. All should feel free to
make changes (through Friday) at
http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-ccamp?useMonospaceFont=true


Thank you!
Lou and Deborah

These are also available from the materials page:
> 
>     0 - Combined with 1
>     1 - Agenda, Admin & WG Document Status
>     2 - draft-ietf-ccamp-wson-signaling
>     3 - draft-farrel-interconnected-te-info-exchange
>     4 - draft-dios-ccamp-control-models-customer-provider
>     5 - draft-ietf-ccamp-lsp-diversity
>     6 - draft-ietf-ccamp-rsvp-te-srlg-collect
>     7 - draft-beeram-ccamp-network-assigned-upstream-label
>     8 - Moving the overlay discussion forward
>     9 - draft-long-ccamp-rsvp-te-availability &
draft-long-ccamp-ospf-availability-extension
>     10 - draft-li-ccamp-role-based-automesh
>     11 - draft-martinelli-ccamp-wson-iv-info
>     12 - draft-dharinigert-ccamp-g-698-2-lmp
>     13 - draft-galikunze-ccamp-g-698-2-snmp-mib
>     14 - draft-zhang-ccamp-rsvpte-ber-measure
>     15 - draft-zhang-ccamp-gmpls-resource-sharing-proc
>     16 - draft-gandhi-ccamp-gmpls-restoration-lsp
>     17 - draft-ali-ccamp-otn-signal-type-subregistry
>     18 - draft-ali-ccamp-additional-signal-type-g709v3
> 
>    Session 2014-07-21 1520-1650: Tudor 7/8 - Audio stream - ccamp chatroom
>    Session 2014-07-23 0900-1130: Territories - Audio stream - ccamp chatroom
> 
> Agenda
>                                        CCAMP Agenda For IETF 90
>                                        Version:
>                                         
>                                        First Session
>                                        MONDAY, July 21, 2014
>                                        1520-1650 Monday Afternoon Session II
>                                        Room: Tudor 7/8 (MM)


> Presentation Start Time Duration Information
> 0 15:20 10 Title: Administrivia & WG Status
> Draft:

No Agenda changes.

>                                Presenter: Chairs
> 1 15:30 10 Title: WG Document Status
> Draft:
> Presenter:

- TE Metric Recording & SRLG Collection I-D
Matthew: Code points documented have already been allocated by IANA for
other I-Ds.
Lou: More inclined to request they do not have early allocation and
follow the IANA process
Oscar: (as author) we already requested an early allocation.
Lou: Lets discuss this issue during your presentation.


Re: WG I-Ds not currently on agenda - What are the authors intentions?
Rakesh Gandhi: Two months since the comments were made, but I have been
in PTO, I will look to address them in the next few weeks.
George: I need to synch with Zafar
Lou: Please get with Zafar and ask him to provide an update to the list
on when the draft might be updated

> 2 15:40 10 Title: Post LC WSON Document Changes
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling
> Presenter: Young Lee


Lou: Implementors please review the document for changes. Are there
volunteers willing to commit to a review by the end of August - 3
(including Authors.) I have some technical comments on the error
processing and will send them to the list

> 3 15:50 10 Title: Problem Statement and Architecture for Information
Exchange Between Interconnected Traffic Engineered Networks
> Draft:
http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange
> Presenter: TBD

Igor: Who owns the abstraction layer? Who configures it?
Adrian: concept of ownership is up for debate - abstraction layer may
have physical resources from both Client and Server layer, and may be
part of the contract between them.
George: Server layer or control entity would control paths are created
from the server layer.
Igor: it may be dependent on time/day, the client may want to change
(demand?)
Oscar: Document is already 40 pages, might be worth splitting the
document, maybe seperating terminology?
Adrian: Inclusion of terminology was a request from chairs.
Lou: I had made a request for seperate documents, but it seems this has
not resonated with the authors. One or two documents is secondary, what
is most important is to have terminology documented in one place.
Adrian:
Igor: Agree that it should be located in a single place.

[Poll]
How may read the document: a good number
How many would support about the same
Who has reservations regarding the document none
We will take to the list.
> 4 16:00 10 Title: Terminology and Models for Control of Traffic
Engineered Networks with Provider-Customer Relationship
> Draft:
http://tools.ietf.org/html/draft-dios-ccamp-control-models-customer-provider
> Presenter: Oscar Gonzalez De Dios

Fatai: The I-D list terminology/defintions but it does not prescribe
which terms to use.
Oscar: We compiled the terms, but it is up to the WG to decide which
terms to use, something to discssion on the list.
George: Historical purposes, re: the OIF UNI, was built around a
commercial relationship between user and the network. We then stripped
down the defintion to the essentials.
Deborah: Do not spend too much effort/involved with terminology, we will
clean up in the near future.
Hannes: Lots of progress in current draft. Should we extend terminology
to ENNI, or not?
Lou: Are there any portions of the document that could not be merged
with TE interconnection I-D.
Oscar: No reason why the document could noy be merged, the only
reservation would be on the size of the document.
George: A reason for having a terminology section in TE interconnection
document is that terms have become fuzzy and may be used differently.
Oscar's document brings some precision to the dicussion.
Lou: Ok, I see the motivation for ... In summary, lets keep the document
seperate but review the TE interconnec and see whats missing and report
to the list.
Oscar:


> 5 16:10 10 Title: Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Route
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity
> Presenter: Zafar Ali/George Swallow

Lou: Three methods defined in I-D do you expect an implementation to
supprot all three?
George: (Yes?) Scenario specific, it depends on the use.
Khuzema: Without XROs, option#1 uses crankbacks, which has scalability
issue. Suggest to add recommendation to use option#2,3 if XROs are not
used.
George: as a means for last resort, but not preferred.
Hannes: what if the server layer stops using some identifiers? Do we end
up with a network full of stale XROs?
George: these are just protocol mechanisms - we don’t specify how things
get passed around.
Gert:
George:
Lou: New requirements in I-D, that seem to conflict with your description.
George:

> 6 16:20 10 Title: RSVP-TE Extensions for Collecting SRLG Information
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect
> Presenter: Oscar Gonzalez de Dios

Lou: how many have read latest version (reasonable number). Let's get
the security stuff discussed this week.
Lou: early allocation: should we get early allocation now if we do LC?
Oscar: yes, we'd have liked it previously :)
Matt: We should get on and do it - there's no downside and will be
useful if LC takes a long time.
Loa: if you have implementations, you should definitely do it. Also, WG
chairs should stop docs attempting to allocate numbers unofficially -
docs with actual numbers should be sent back to the authors and made TBD.
Matthew: PWE3 has maintained a doc to keep tabs on proposed numbers
Lou: we've tried a lot of things... nothing works and is politically
acceptable. I think suggested values are OK.
Loa: early allocation is much better than something that's not according
to process. Suggested values also mean authors have to read many drafts
in other WGs
Lou: anyone opposed to early allocation? (none) Authors can work the
process out :)
Loa: send mail to WG chairs, copy AD, ask for early allocation
Oscar: we did that
Lou: do it again.


> 7 16:30 10 Title: Network Assigned Upstream Label
> Draft:
http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-upstream-label
> Presenter: Vishnu Pavan Beeram

Lou: This draft receieved good support at the last meeting. (poll) How
many are interested in function? [a good number], how many have read the
document [about the same], how many think this draft is a good
foundation for the WG [good support]. Okay, will confirm (poll) on the list.


> 8 16:40 10 Title: Moving the overlay discussion forward
> Draft:
> Presenter:



> Adjourn 16:50
>                                         
>                                         
>                                         
>                                        Second Session
>                                        WEDNESDAY, July 23, 2014
>                                        0900-1130 Wednesday Morning Session I
>                                        Room: Territories (MM)
> Presentation Start Time Duration Information
> 0 9:00 5 Title: Administrivia
> Draft:
> Presenter: Chairs
> 
> 9 9:05 10 Title: RSVP-TE Signaling Extension for Links with Variable
Discrete Bandwidth & OSPF Routing Extension for Links with Variable
Discrete Bandwidth
> Draft: http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-availability
>                                        http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension
> Presenter: Greg Mirsky
Giovani: do you advertise availability?
Greg: no
Lou: yes
(minor confusion, taking it to the list)
Giovanni: could we have the capability generalized? Could be useful
elsewhere. I have some ideas
Greg: interesting idea, discuss on the list and see what other links
might exhibit this behavior
Lou: which technologies do you care about?
Giovanni: optical ones
Lou: how many think this is useful (good number) How many have read the
docs? (pretty good number) If we were to poll on this, would anyone
object to using these docs to build on? (none)
> 
> 10 9:15 10 Title: Routing Extensions for Discovery of Role-based MPLS
Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership
> Draft: http://tools.ietf.org/html/draft-li-ccamp-role-based-automesh
> Presenter: Greg Mirsky
Lou: need to emphasize that this is an update to something that already
exists, not a completely new thing
Greg: yes, this is an improvement to existing TE mesh-groups
Lou: so this is based on RFC 4972. Do you see this as an update or bis
to that?
Greg: they can coexist
Lou: how many have 4972 implementations or care about 4972? (none) how
many have heard of it? (reasonable number)
Adrian: 4972 deployments are mostly in packet world so a lot of folks
who may care may well be in other WGs at the moment
Lou: yes, we should perhaps coordinate with MPLS WG
Greg: could Loa give us some time on Friday AM to talk about this in MPLS?
Loa: if there's time
Lou: how many would be interested in this? (reasonable number)
Lou: please send a message to MPLS and ccamp lists to solicit feedback
on draft

> 11 9:25 10 Title: Information Model for Wavelength Switched Optical
Networks (WSONs) with Impairments Validation
> Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info
> Presenter: Giovanni Martinelli
(no questions)
Lou: last meeting there was reasonable interest in this... is this still
the case? (reasonable support) How many think this is a good foundation?
(same) Any reservations? (none) OK, will take to list to confirm
Deborah: ITU question 6 meets in six weeks, and we may need to make some
updates to this draft before then


> 12 9:35 10 Title: Extension to the Link Management Protocol (LMP/DWDM
-rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line
Systems to manage application code of optical interface parameters in
DWDM application
> Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp
> Presenter: Gert Grammel
(no comments, combined with next presentation)

> 13 9:45 10 Title: An SNMP MIB extension to RFC3591 to manage optical
interface parameters of DWDM applications
> Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib
> Presenter: Gabriele Galimberti
Julien, via jabber: WDM is mesh networks. How do we deploy this
proposal? (LMP, rather than SNMP)
Gert: LMP is the link between the roadm and transponder, so it's WSON
rather than signaling
Lou: so it's still what used to be called alien wave
Gert: (scribe missed this bit)
Deborah: What's the expectation if the ROADM doesn't support LMP?
Gert: you go to the MIB
Julien: what data plane channel is the information referring to? Just
the link between ROADM and access point, or the whole link?
Gert: the first hop between router and ROADM. You need to have a lambda
already to have end to end correlation
Lou (for Julien via Jabber): The LMP parameters - are you referring to
data channel, or just the link?
Gert: we're trying to correlate the sender and receiver application code
so that on the access link both sides know what they're connected to.
There's no lambda yet. You need to understand the link and make sure
it's set up properly
Gabriele: two steps in setting up network. 1st: understand parameters
relative to transceivers, and you use LMP to make neighbors aware of
these. 2nd: how do you flood these around the control plane? That's not LMP.
Lou: so this is out of scope for LMP - signaling/routing do this, and so
there may be PCE implications which may be Julien's interest
Lou: next steps in slides seem reasonable, and we'll discuss again as
docs mature.

> 14 9:55 10 Title: RSVP-TE Extensions for Bit Error Rate (BER) Measurement
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-rsvpte-ber-measure
> Presenter: Zhenbin Li
Pat King: from an RF background, we can't tell you what the BER is - e
only know we received things when the frame check is right, so the only
way we can give you a BER is if you're using acknowledgement. So there's
a lot of information here that the lower layers in RF can't supply.
Packet error ratio is probably the best we can give you. And there are
many things in the lower layers that you're not aware of so I'd question
the need for a BER since many devices can't give it to you
Julien: question 3 on slides is still relevant, and it doesn't apply.
Look at RFC4260
Deborah: OAM is based on what data plane can support... includes MIPs
Julien: there are tech-specific TLVs that can be used.
Lou: you should look at prior work
Zhenbin: OK
Deborah: you have to align with the dataplane, and it doesn't support a
bit error ratio. It's a block error ratio. You have to go on what the
dataplane can support
Giovanni: even when BER is available, it's only in a few places
Deborah: you don't need to get into the granularity of telling the
head-end the BER is off. The head can tell that the signal has degraded
on its own.

> 15 10:05 10 Title: Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Signaling Procedure for Resource Sharing-based LSP Setup/Teardown
> Draft:
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-resource-sharing-proc
> Presenter: Haomian Zheng
Lou: relating to next draft too: last meeting we talked about merging
these two. Any comments?
Haomian: this is prior information that enables re-use of resources.
Lou: so this is applicable to restoration?
Haomian: yes
Lou: at some point Chairs will ask you to consider merging documents as
mechanisms are similar, even if applications are different.
Lou: how many think this information is useful? (a good number) So
continue the draft and Chairs will think about polling the list.
Lou: personally I'd like to see the drafts combined.
Fatai: I think the authors tried to combine them but they were too different
Deborah: why?
Fatai: next draft is about protection object, this draft is not - it's
broader than just protection

> 16 10:15 10 Title: RSVP-TE Signaling For GMPLS Restoration LSP
> Draft: http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp
> Presenter: Rakesh Gandhi
Pavel: why do you say the two drafts are completely orthogonal? You can
always share resources between associated LSPs
Rakesh: yes, pairs of working and protecting LSPs can share. But there's
no overlap
Pavel: so you explicitly don't want working/protecting LSPs to share.
Lou: remember that once the docs are WG docs the WG decides whether they
merge or not :)
Lou: "If you are an implementer working on the association object, do
you have to read both document or you just need to read only one?"
Rakesh: RFC 6689 covers the association object and there's a gap there
that this draft covers. But there are more drafts to read to implement
everything.
Haomian: better if you're focusing on just one problem to only need to
look at one draft.
Lou: chairs think combination is good. How many are interested in docs?
(good number) how many think we should combine (bit less) how many think
it's a bad idea? (a few)
Lou: please look at combining the docs and we can then poll WG on the
combined doc
Julien: if goal is clarification, single doc is easier


> 17 10:35 10 Title: RSVP-TE Extension for Additional Signal Types in
G.709 OTN
> Draft:
http://tools.ietf.org/html/draft-ali-ccamp-additional-signal-type-g709v3
> Presenter: Matt Hartley
Lou: the vendor-specific types cannot be standardized and should be
removed from the doc
Lou: how many have read (few) how many support the doc (same),
Lou: This work compliments related work completed by the WG, please do
the updates as discussed

> 18 10:25 10 Title: IANA Allocation Procedures for OTN Signal Type
Subregistry to the GMPLS Signaling Parameters Registry
> Draft:
http://tools.ietf.org/html/draft-ali-ccamp-otn-signal-type-subregistry
> Presenter: Matt Hartley
Lou: I suspect you mean "Standards Action" rather than "Unassigned"
Lou: Any comments from our AD - expect there are two areas where he may
comment
Adrian: The Experimental range looks large, also perhaps "Expert Reivew"
is better than "Experimental"
Adrian: the G.Supp43 values should be under Expert Review rather than
Experimental, as they're going to be around for too long to be really
experimental
Lou: Agreed, not sure why we (AD&Chair) focused on Experimental at the
last meeting, but Expert Reviews is clearly a better choice. Authors,
please make the change to allow for Expert review, consider shrinking
the experimental range and remove the private range. The document should
indicate that the expert (for the expert review) will be appointed by
the CCAMP WG chairs.

Lou: The prior document should also request "Expert Review" values.

> Adjourn 11:00

notes controbution by Matt