CCAMP Session 1
9 November 2010 (0900-1130)
- We have a full agenda; presenters are asked to stick to the time
allotted.
- At IETF 79 we have a total of 36 presentations across two sessions.
- Typically we have provided slots to anyone that requested one. This may need
to be reviewed based on the increase in the number of requests. Comments are
requested on the list.
- Please see the slides for CCAMP status updates.
draft-ietf-ccamp-lmp-behavior-negotiation-01
Presenter was
Dan Li
Lou Berger: a couple technical comments.
[Slide backwards compatibility] In this document you cannot define how current nodes
operate using RFC 2119 language. This is because current nodes will not follow
this document.
Dan Li: ok.
Lou Berger: just be careful on using
RFC2119 language. You cannot dictate how non-conforming nodes will perform.
Dan Li: our intention is to define
new behaviour.
Lou Berger: also you do not describe
non-config objects, it's implied but not described. It's not clear why you're
bringing this up as a compatibility issue.
Dan Li: multiple config objects is not explicitly stated in RFC4204.
Lou Berger: it's a good topic to
discuss it's just not clear how existing nodes will handle this. We need to
highlight this as an operational issue rather than a specification issue. Also
did I previously ask you if you have considered BGP capability encoding?
Dan Li: I did consider this.
Lou Berger: just for reference, BGP in RFC3392 can negotiate capabilities and provide variable
length parameters. So if you wanted to negotiate capability and provide
additional information you could use this mechanism. I'm not advocating one
solution or another I just asking you to consider these mechanisms.
Julien Meuric: you mentioned there
was a hole regarding multiple config methods/objects. Do you have some ideas
regarding how to solve this issue?
Lou Berger: I'm just stating that
you can't dictate requirements for nodes that already exist in this
document.
Julien Meuric: so it's more the
language rather than the solution?
Lou Berger: that's right. We don't
know if existing nodes (in the field) are capable of handling new capabilities
described.
Richard Graveman: I think that the
security consideration should at least point to the LMP document that points to
things deprecated. So I'm not saying this document should fix this problem but
it should state that the problem exists and may already be resolved.
Dan Li: this has been stated on the
mailing list.
draft-ietf-ccamp-oam-configuration-fwk-04
Presenter was Attila Takacs
Deborah Brungard: did you align with ongoing
MPLS-TP work?
Lou Berger: in terms of multiple
documents, just focus on getting content correct. Cover MPLS-TP, but consider
the wider scope within the framework and we can always break the document apart
later.
Attila Takacs: I will confirm that
all of the MPLS-TP requirements are covered.
Loa Andersson: I have not read
version four, does this new document add any requirements on the other three
documents?
Attila Takacs: I added a high-level
description.
Loa Andersson: so we can split
content into separate documents.
Lou Berger: as a follow-up, the same
problem will exist when we cover the MIB requirements coming from MPLS-TP.
draft-takacs-ccamp-asymm-bw-bidir-lsps-bis-00
Presenter was Attila Takacs
Deborah Brungard: Note,
document was already accepted as WG document at last IETF. Did you address the errata?
Attila Takacs: yes.
Deborah Brungard: okay the working
group should be reviewing the document and we will last call soon.
Lou Berger: just for clarification,
associated bidir is out of scope for this document.
draft-ietf-ccamp-gmpls-g709-framework-03
Presenter was Fatai Zhang
Biao Li: I think this document addresses multistage multiplexing
requirements. How capability will be discovered, how OSPF will handle this, how
signalling will address this?
Fatai Zhang: in the framework
document we do have text to address multistage multiplexing. That shall
solution including OSPF and signaling, is not complete.
Biao Li: I think the requirements are
not complete. There are more requirements that need to be defined in this
document.
Fatai Zhang: please provide
information to we can discuss additional requirements.
Deborah Brungard: definitely, if you
have recommendations to refine requirements and please provide them.
Lou Berger: this is another example
where language plays an important role. This document should be discussing what
information should be propagated, not how information should be propagated.
Eve Varma: just a comment. I would
like to reinforce Deborah's comments on the mailing list. G709 is silent in
terms of equipment approaches and implementations.
Deborah Brungard: yes thank you Eve.
We only define functionality not the equipment capabilities.
Lou Berger: yes. Of course this
makes your job harder as the specification need to be flexible and does not
restrict different capabilities. Have you considered how to manage change, on
the data plane, and how to track that in the framework document? We have
functionality that we are trying to standardise for the control plane but the
functionality keeps changing.
Fatai Zhang: yes we are monitoring
ITU progress, and update the framework document accordingly. Especially
on the data plane technologies.
Lou Berger: well we need to consider
that this document may never stabilise, until the data plane specification
stabilises. This is an evolving process, perhaps we need to consider a way of
managing and separating this.
Eve Varma: no.
Lou Berger: I'm not saying that this
is the right thing to do; it’s a question we should consider. Otherwise this
work will be gated.
Xihua Fu: based on the liaison this
document should provide requirements and solution as soon as possible.
Lou Berger: so you
endorsing a base document, and a separate document for evolving items?
Xihua Fu: the framework document
should define requirements. A separate document should be useful solutions for
multistage multiplexing.
Eve Varma: for clarification the
G709 (2009 version) is quite stable it includes ODU flex. The hitless resize
application is targeted for consent in February (2010). So the topic under discussion
is related to how the control and management plane interact, when your performing a resize operation. The data plane aspects, for the resize, is really stabilizing and will be
completed by February.
Lou Berger: this is good information.
I do not think we've had a liaison with a workplan for G709. If the data plane
is stable and the specifications are stable in February then there is no reason
to perform split. However if we meet again at the next IETF (March 2010) and
there is continuing work in the data plane we may have to rethink this. This is
not a specific chair requests this is something I would ask you to consider as
a document and process management issue.
Fatai Zhang: yes we need to check
progress data plane technologies.
Malcolm
Betts: the workplan was liaised from SG 15 to various
working groups including CCAMP. This will tell you the status of the work.
There is also no new plan for G709, so the work is stable. The part under
consideration is hitless resize. So if you're considering a
pragmatic cut and run, cut off hitless resizing and continue with the rest of
G709. I'm not advocating this should be done, just stating that this
might be an appropriate point.
Lou Berger: right. That’s what I was
implying.
Deborah Brungard: yes. We simply wanted to make sure that we weren’t going to
be waiting too long.
Eve Varma: it's very
important to consider hitless resize as it does have impact on calculations and
trib slots. So my recommendation is to keep this work
together.
draft-bccg-ccamp-otn-g709-info-model-02 to
Presenter was
Daniele Ceccarelli
draft-zhang-ccamp-gmpls-evolving-g709-06
Xihua Fu: [slide 6] this depends on the network planning. The PCE can
define where multi-stage multiplexing should occur. This draft does not provide
a solution.
Daniele Ceccarelli: we analyse the
problem and the draft provides an informational model.
Xihua Fu: so you need two drafts,
this document and a protocol solution.
Daniele Ceccarelli: I believe
capability is something that needs to be advertised not signaled.
Rajan Rao: it’s still not clear what
does not work currently? What is the use of a termination switching flag? What
is being advertised, via routing, for the ODU 0 connections [slide 6]?
Daniele Ceccarelli: we are saying
that we advertise if an interface is capable of terminating or switching ODU
containers being advertised.
Rajan Rao: it's still not clear what
OTN service is not supported without this information. When you set up the ODU1
LSP it implied that one or more ODU are being terminated. There is no explicit
indication required.
Danielle: in this example [slide 6] the
load need to understand if the second level of multiplexing is capable or not.
Rajan Rao: it would simplify routing
if you hide this information. All you need to know is if ODU1 can be set up
from node A to E. Regardless of which mux layer it uses along the way.
Lou Berger: if the document
describes required function. Then we need agreements on the requirements. Right
now we are hearing feedback on mechanisms.
Deborah Brungard: as Lou mentioned
you need to consider the requirements more not the solution.
Jon Sadler: Is the purpose of the
TNS bits?
Daniele Ceccarelli: Not only bundle
link.
Jon
Sadler: is the purpose of TNS bits to remove ambiguity on the G-Z link if
G-Z link? The intent is to show what can be used across the interior?
Daniele Ceccarelli: exactly.
Rajan Rao: the purpose of the draft
is confusing; it's duplicating what’s in the framework document? The only new
thing I see is terminating and switching capability.
Daniele Ceccarelli: the framework
document defines that terminating capability must be known.
Rajan Rao: I do not think the
framework document discusses that capability.
Lou Berger: since this is describing
functionality we should see how much of this document and information can be
moved into the framework document. The solution parts can be moved into the solutions
document.
Cyril Margaria: you indicate in the
framework that the tributary port information, in a label, is used to configure
the data plane correctly.
Daniele Ceccarelli: in the
information model, it needs to be considered.
Biao Li: certain vendor equipment
may have different capability; you need information to advertise if you can
only terminate a certain ODU. This is not included in this document.
Daniele Ceccarelli: that is not in
scope of this document. The OSPF draft needs to be updated.
Biao Li: the solution should discuss
multistage multiplexing.
Daniele Ceccarelli: yes.
Lou Berger: it should also be
covered in the framework.
Dmitri Papadimitriou: why do you not
call this an evaluation document? Your evaluating
capabilities against what exists? You should look all the mechanisms defined
and see if anything could be used and generalized.
Lou Berger: yes I think there is
agreement that the will take existing solutions and see if there's anything can
be reused.
draft-bccg-ccamp-otn-g709-info-model-02
Presenter was Fatai
Zhang
Xihua Fu: please clarify how RFC4206 support multistage multiplexing.
Fatai Zhang: we know we need to
create ODU connection. We know RFC4206 may have something missing. We need to
follow a general solution.
Xihua Fu: how could you determine which ODU tunnel
should be used.
Fatai Zhang: you can put this kind
of information in the signaling.
Xihua Fu: we should carry
multi-stage, hierarchy, information.
Fatai Zhang: that solution is not
defined in this draft.
Lou Berger: please discuss more on
the list.
Julien Meuric: regarding TPN
question. It seems a check value in the data plane. It’s not a requirement.
What the meaning of this field, where it should be used. Please elaborate.
Lou Berger: You may want to look at
egress label control RFC4003.
Biao Li: ODU 0 is visible. We just
look at this example, node C can support it. Do you want to setup FA.
Fatai Zhang: FA already supported.
Biao Li: You need FA to be
supported. My question is does it mandate FA to support multistage/multiplexing.
Eve Varma: I wanted to clarify TPN,
when you mentioned endpoints, it should relate to link endpoints.
Lou Berger: Then the comment on
egress label control RFC4003 probably doesn’t apply
draft-bccdg-ccamp-gmpls-ospf-agnostic-00
Presenter is Daniele Ceccarelli
Lou Berger: I did ask you offline, we have two directions. 1) Build on work
from before, or do as you suggest. 2) Throw out and start again. We need
examples so we can make a decision. In order of magnitude, 140 bytes, versus
14-20 bytes, this is control plane data. Is that such a big deal for the
networks, with existing RFCs?
Daniele Ceccarelli: my personal
stand-point. For 100 bytes, per link basis. My initial
reaction is no.
Rajan Rao: it’s still not clear to
us. What is not in RFC4202 that this trying to address?
Lou Berger: this is trying to
optimize the case when there are not many priorities. If you believe you will
have a small number of priorities this is an attempt to optimise the case.
Daniele Ceccarelli: a lot of
different containers. This could be summarised together into a single LSA/TLV.
Deborah Brungard: we need more comparison
with the existing approach and what are the savings? How many priorities do
operators have? From operators perspective this will introduce additional
complexity, what are the real savings?
Rajan Rao: what is the implication
the new routers which method but they support?
Daniele Ceccarelli: you can
advertise different types of bandwidth.
Rajan Rao: that's clear, but what is
the expectation of existing routers. You're calling it technology agnostic, but
it's new and impacts existing routers.
Daniele Ceccarelli: we need to
decide if this is necessary.
Lou Berger: yes we need to evaluate
and discuss.
Lyndon Ong:
in support of Daniele the technology agnostic aspect was a request. We also had
a couple of proposals about technology agnostic extensions. It's not just about
priority; there are other factors of the advertisement for OTN. Getting
agreement on requirements is a good first step.7
draft-ceccarelli-ccamp-gmpls-ospf-g709-04
Presenter is
Daniele Ceccarelli
No comments.
draft-ashok-ccamp-gmpls-ospf-g709-00
Presenter is Rajan Rao
Daniele Ceccarelli: your latest version solves
some problems identified on the list.
Rajan Rao: backwards compatibility
[slide 1]. ST knows what the ODU that can be carried is. There are examples in
the slides.
Jon Sadler: [slide 7] is ODU5
correct I think it 80?
Rajan Rao: its 82, because…[missed comments].
Lou Berger: this sounds like a good
discussion for the list. From the chair perspective, which requirements and way
to optimize is an open question for the WG.
draft-zhang-ccamp-gmpls-h-lsp-mln-02
Presenter is Fatai Zhang
Dmitri Papadimitriou: this capability already
exists. What is the benefit of having node A [Open discussion multi-carrier]?
Lou Berger: please answer question
on the list. Same for Jonathon.
draft-fuxh-ccamp-boundary-explicit-control-ext-01
Presenter is Fatai Zhang.
No comments.
draft-wang-ccamp-latency-te-metric-01
Presenter is Xihua Fu
Dave McDysan: people should read this draft.
The composite links document defines requirements, this is a potential
solution.
Deborah Brungard: I think this work
is important but it needs further identification of requirements.
Lou Berger: when you consider
solutions consider IntServ as it already has
semantics for latency.
draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
Presenter is Rajan Rao
No comments.
draft-zhang-ccamp-srlg-fa-configuration-01
Presenter is Oscar Gonzalez de Dios
Lou Berger: From a WG standpoint, this flag space is scarce. Please update
the document as the mechanisms you are currently using will not go forward within
the WG.
Oscar Gonzalez de Dios: ok.
Xihua Fu: [Daniel King: I
did not hear the question]
Lou Berber: please send question to
the list.
draft-malis-ccamp-rfc5787bis-01
Presenter is Acee Lindem
Lou Berger: traditionally we keep original authors on the document, unless
they want to be removed. We can talk further offline. Also on
the last slide. Can you elaborate on RFC4652 comment?
Deborah Brungard:
regarding at the last meeting that you said you would check with the ITU on the
capability which you removed, is there any feedback from the ITU on this?
Lyndon Ong:
we did look at RFC4258 to see if there was anything we were removing from the
requirements. We could not find anything. I did not get any comments back from
the ITU that anything was missing.
Deborah Brungard: The difficulty is
that it was highlighted in several ITU liaisons. So they previously saw this as
a key capability.
Acee Lindem: that
refers to recovery, not this discovery mechanism? There's nothing that mentions
you need more than one router/RC advertising information between levels in an
ASON hierarchy.
Lou Berger: this refers to
discovery.
Acee Lindem: that
was broken that's why it was removed.
Deborah Brungard:
we need to understand why you are removing this capability at this time.
Lou Berger: it's fine to change it.
If it's broken feel free to ask ITU to send a liaison removing the requirement.
Currently it is our understanding that this discovery capability is a
requirement.
Acee Lindem: I
would like to see this specific requirement.
Lou Berger: sure, let’s take this
off list. If we receive a liaison removing the requirement then we can remove
it.
CCAMP Session 2
12 November 2010 (1300-1500)
Administrivia
- WSON switched to second
CCAMP day due to OTN/G709 drafts.
- Link to agenda and slides is a little unstable from the IETF agenda page. Use
the CCAMP tools link to the agenda.
- Pierre Peloso was unable to attend. Someone else
will present his topic. [draft-peloso-ccamp-wson-ospf-oeo-01]
draft-ietf-ccamp-wson-impairments-04
Presenter was Young Lee
Lou Berger: can you clarify
the first two bullets. You believe you have completed the document and it’s
ready for last call?
Young Lee: yes.
Lou Berger: how many people think
it’s ready to move forward? [About
the same number as who have read it.] Does anyone have any reservations? [No]
Jon Sadler: useful to send a Liaison
to ITU notifying of last call.
Lou Berger: agree a useful thing to
do as part of the last call.
draft-ietf-ccamp-rwa-info-09
Presenter was Greg Bernstein
Deborah Brungard: how many have read the
document?
Lou Berger: this document represents what is being done in the solutions
document. There was a discussion on waiting on the LC to wait on the solutions
document, do that as a set.
Giovanni Martinelli:
first comment, is on the same line of Lou’s
comment. The second comment, regarding
BNF, to represent information. The same BNF represented in the encoding draft.
Is it worth having two BNF definitions for the same thing?
Greg Bernstein: we can take that
question offline. I'm happy to do it either way.
Lou Berger: it’s good to define in
just one place and just to refer to it.
draft-ietf-ccamp-rwa-wson-encode-06
Presenter was Greg Bernstein
No comments.
draft-ietf-ccamp-general-constraint-encode-03
Presenter was Greg Bernstein
Young Lee: the only pending issue is the WSON specific encoding. The
generic encoding is stable.
Lou Berger: Greg got it right when
he said these documents were. As a general principle, these documents feed the
other ones. We propose to move these document’s forward as a set.
draft-ietf-ccamp-wson-signaling-00
Presenter: Giovanni Martinelli
Greg Bernstein: on wavelength items we will
try to go with something general.
Lou Berger: that’s good we do not
restrict which algorithms we use. [Chair hat off] Bidir
is not supported or described. You also need to justify why you need an
additional mechanism for symmetric allocation. Crankback
may be good enough, just document what’s available and why there are issues.
draft-ietf-ccamp-wson-signal-compatibility-ospf-02
Presenter was Young Lee
Lou Berger: [With regard to the mailing list discussion and other draft,] certainly
if holes exist, or have been raised, we should fill them. If you think we can
merge great, if not lets discuss on the list.
Greg Bernstein: we have had
discussions. There is not a strong reason to change things, or what is being
asked. We will try to tie this up on the list soon.
Lou Berger: discussions are good, we
would like to see this resolved. How many read the document? [A small number, similar to the number discussing
the issues on the list.]
draft-bernstein-wson-impairment-info-03
Presenter was Giovanni Martinelli
Deborah Brungard: if we polled how many read, I
suspect it will be a similar number. Any other comments?
Greg Bernstein: helpful with update to
G.697, some other things we had assumed was a nice way to encode, was included
in the update. This allowed us to reference their document.
Greg Bernstein: we encourage people
to work with us on this.
draft-peloso-ccamp-wson-ospf-oeo-01
Presenter was Giovanni Martinelli on behalf of Pierre Peloso
Igor Bryskin: what happens when the TLV
becomes too large? It’s not just this draft, its other
WSON work as well. I see a lot of drafts. Have you considered how much info can
fit into a TLV?
Lou Berger: comments also apply to
other OSPF documents.
Igor Bryskin:
I would suggest not making the top level TLV to large. Do not put everything in
the top level TLV.
Giovanni Martinelli: in this case we add a new
top level TLV, carrying additional information. T do
not know what the final WSON solution will be.
Young Lee: let me try to elaborate.
To represent OEO's elements, we agreed what node information needs to be
propagated. Now you're bringing internal links, SLG< TE metric, admin group.
Also do you still have identifies?
Giovanni Martinelli:
yes.
Young Lee: if we need represent a link
and if we need to advertise externally, PCE, is this legitimate? If the WG says
this info is needed then we can address sit. Also as Igor says, do we really need
another top level TLV. We also soon there is no ODU
switching. This was based on current WSON scope. Once we agree, we can merge.
Giovanni Martinelli:
the idea was to represent some property of OEO pools.
Igor Bryskin:
this is a big problem. Let's take connectivity matrix, it could be huge. If you
put this in the top level link TLV, it may not fit in one LSA.
Giovanni Martinelli:
there is no disagreement.
Igor Bryskin:
we should provide a mechanism that is outside top level link TLV.
Acee Lindem: theoretical
maximum (64k) flooding works a lot better if it fits in an MTU without having
to fragment.
Young Lee: use existing opaque LSAs.
We still need to answer if dissemination of internal link information is
required.
Lou Berger: we have multiple points,
Acee and Igor make a scaling point and this applies
to all WSON OSPF documents.
Young Lee: we can discuss.
Lou Berger: I think we need a
specific section on LSA scalability. The second is a requirement. Does the framework documents cover your [Giovanni Martinelli] requirements?
Giovanni Martinelli:
the framework is good. The informational model is also OK. The encoding
document is OK; except they define the sub TLV and suggest which top level TLV
will use the sub TLV.
Lou Berger: please make that comment
on the list. Also is OEO in the encoding document.
Young Lee: in terms of requirements,
framework/information model, do we have OSPF support?
Lou Berger: It seems we’re having a
requirements discussion in the context of a solutions document, please go back to
the top level documents and verify your requirements are being covered. If they aren’t, the make a comment to the list. We can then discuss the requirement, and once
there is consensus on the requirement we can debate mechanisms.
draft-zhang-ccamp-general-constraints-ospf-ext-00
Presenter
was Fatai Zhang
Deborah Brungard: How many have read document?
[A good showing] How many think it’s ready for WG document? [A reasonable
number] Let’s take it to the list.
Deborah Brungard:
I suggest some examples and scaling information.
draft-ietf-ccamp-assoc-info-00
Presenter was Lou Berger
No comments.
draft-ietf-ccamp-rsvp-resource-sharing-00
Presenter
was Francois Le Faucheur
Deborah Brungard: what applications do you have
in mind?
Francois Le Faucheur: In telephony, home/office, we
make two reservations. I do not want to reserve two amounts of BWs, only one phone will be answered. its
only use to tell the receiver to say this is a good value to use.
Deborah Brungard:
what about protection or multi-homing?
Francois Le Faucheur: perhaps, but may not be the
best way.
Lou Berger: Is there ever a case
where the receiver says “no”? [No] Then why not make it sender sharing?
Francois Le Faucheur: in RSVP all the BW allocation
is at receiver time., so don’t want to use path state.
Lou Berger: this only happens if you
have path state. Let’s talk offline.
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-01
Presenter was Fei Zhang
Lou Berger: If no one else has comments, I have some technical comments you
discuss three cases. What is the provisioning model in MPLS-TP on associated
bidirectional LSP? Here you allow either side to trigger, and then you
associate. Do you think this is the right usage model? It's not clear to me
that this is the right provisioning model for TP.
Fei Zhang: maybe some equipment doesn't
support upstream labels. The solution supports that case.
Julian Meuric:
as a reminder RFC3473, makes bi-dir LSPs available in
MPLS.
Lou Berger: That’s for co-routed
case. This is the associated case, where paths are difference and such
association is required [in MPLS-TP]. We need to discuss what is needed and
define a model of operation based on requirements. Would like to see a
definition of the provisioning model so that we’re all in agreement on what is
to be done before we define how to support the function. Please bring this
issue up in the wider MPLS-TP joint session or in mail.
draft-ietf-ccamp-dpm-01
Presenter was Weiqiang Sun
Deborah Brungard: Poll. [A
reasonable number, including the chair of BM WG]
Al Morton: I think you are using the
term “availability” to mean something different than is typical. You may want to choose a different term.
Weiqiang Sun: When we composed the draft. We
discussed if this is applicable to other technologies. So I do not agree that
availability is not a good term.
Deborah Brungard:
The availability gets confused with the in-service usage of availability.
Weiqiang Sun: We borrowed the term from the Adrian/Shiomoto document [switch programming].
Lou Berger: We need to be careful to
use their terms carefully. We need to select the right term for this. Please, work
with Al.
Adrian Farrel:
Author comment [switch programming] If I used the wrong term in my document we
should change this and align it.
Presenter was Hui Ding
No comments.
draft-jiyf-ccamp-lsp-00
Presenter
was Weiwei Bian
No comments.
draft-zhangm-ccamp-reroute-00
Presenter
was Lifang Zhang
No Comments.
OIF Communications
Presenter
was Lyndon Ong
Rajan Rao: the two clients are shown, are
they the same or different clients?
Lyndon Ong:
the assumption is they are the same type of clients.
Rajan Rao: there
is probably an adaptation function needed when different types are supported.
Lou Berger: I think you want to two
levels of feedback from the WG. The first is how to progress the document;
please follow the standard WG process. This applies to both the requirements
and solution documents. You can modify them and discuss on the list, if there
are issues you can discuss them on the list. If no one is working on it the
draft it will die. In terms of the technical topics, you seem focused on an
ASON UNI, we do have a GMPLS UNI, and we also found we needed to extend that to
support MEF requirements, so we now also have a MEF UNI. I would suggest you
review the GMPLS and MEF UNIs and if we need an ASON UNI that’s fine.
Lyndon Ong:
from an organizational standpoint we had been trying to progress the work, but
we have not received a lot of feedback.
Lou Berger: in general the formal
OIF Communications will not get you there; it requires WG discussion and
participation.
Lou: has anyone read these drafts [Not
many]. Well that gives you the level of interest in this topic.
draft-roch-ccamp-lsp-hier-ason-00
Presenter
was Lyndon Ong
draft-roch-ccamp-lsp-hiser-multi-client-00
Presenter
was Lyndon Ong