Hi Folks,
I agree with Dimitri regarding the ad hoc discussions on the VLAN ID, I
think
we are close to a working solution (albeit it does not handle the case
of
very large numbers of VLAN IDs due to the message size problem Dimitri
mentions).
Regarding the interworking "cookbook", it may help for people to know
that this
was specifically scoped to the G.7713.2 and RFC 3473 specifications and
not
beyond this.
Cheers,
Lyndon
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be
Sent: Tuesday, March 20, 2007 7:06 PM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Progressing the discussion on liaison responses
adrian
o) VLAN I-D
i don't think this is a Call functionality
"No information provided on UNI TSPEC expectations (e.g. granularity of
C-VLAN within EVC) in Liaison"
i think this has been clarified on this list if my record is correct
"Any outcome of ad hoc discussions yesterday?"
rsv is associated to the vc and there are two modes 1:1
<vc/session,label/session attr.> and 1:N <vc/session,set of
labels/session attr.> we can cover base cases as long as msg size
doesn't exceed MTU size
- the question wrt progress are 1) do we have a correct understanding of
the problem 2) do we want to progress on the topic inline with MEF
expectations 3) is the base mode acceptable until a more generic is
proposed (or shall we propose a single solution covering all cases)
o) the following is odd, in a sense OIF asks to comment but is ignoring
what we have been developing since those where provided to eliminate
interworking with ASON (shouldn't that be our first comment ?)
"Our comments are solicited
Cookbook objectives seem unclear (ignores GMPLS work on UNI, ENNI,
ASON)"
o) you wrote "Can we help by describing how to map OIF UNI parameters to
GMPLS signalling?" i don't understand the question, the former is a
"profile" the latter a protocol - shouldn't be the other way around
o) optical transport plane work - i don't clearly understand what's all
about but to the question
"- No mention of GELS. Time to let them know?" answer is yes. the
point is that such exchange informative ?
o) Send a complete list and ask for it to be included?
yes
o) * Recent liaison (just in) requests us to liaise
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt "before it is published as an
RFC" and by April 2nd
- I-D is past IETF last call. Is it too late?
that's not the question, the point is WHY ? because the applicability
I-D is not yet respined ? we should address this point by committing
charter milestones here
o) routing
"Asks us to supply details of our reasoning in selecting OSPF loop
prevention mechanisms rather than applying ISIS mechanisms to OSPF We
could supply this reasoning, but to what purpose?
We note that we previously asked if the ITU-T had any technical issues
with our choice and received no answer."
isn't the answer obvious ?
"Asks for further explanation of why we declined to change "an Li may be
advertised by only one Ri at any time" to "a TE link is only advertised
by one Ri at a time.""
i'd like to re-state that the RFC 4652 (in its draft version) maintained
an open item on multiple Ri per Li - no answer, hence closed to re-open
pls provide reasoning (interest argument is a consequence not a cause)
"Restates that we should use "MUST" not "optional" in describing the
inclusion of timeslot accounting information (section 4.2) This seems to
be a misunderstanding of context New revision of I-D clarifies the text
We can liaise back to thank them for prompting us to clarify"
ok
"Request liaison of any work on multi-layer networks We should do this
especially for the MLN requirements and evaluation that are soon to have
last call Very many of our I-Ds and some in PCE are applicable to
multi-layer networks. Liaise them all?"
at least those on control plane at for the layers that concern ITU
meaning SDH & OTH, for the PCE ask to PCE, but what is their real
concern ?
"Set respond-by date to coincide with end of WG last call?
Request explanation of how redistribution of information continues when
a redistribution point fails Simply send an explanation?"
done
o) call i-d
no, i think we're done
note i observe that the list of discussion points is quite large most of
those are non-issues we should ask for splitting real concerns from
informational aspects
thanks,
-d.
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
20/03/2007 16:39
Please respond to "Adrian Farrel"
To: <ccamp@ops.ietf.org>
cc:
Subject: Progressing the discussion on liaison responses
Hi,
Would appreciate it if you looked at the various liaisons and
correspondence at www.olddog.co.uk/ccamp.htm and the slides Deborah and
I wrote at http://www3.ietf.org/proceedings/07mar/slides/ccamp-19.ppt
Please comment on any aspect of any of the correspondence as Deborah and
I
try to put together responses. Would be nice if your comments were on
the CCAMP list rather than in private.
Thanks,
Adrian