Subject: Progressing the discussion on liaison responses

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 20 Mar 2007 15:39:11 -0000

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

---

From: [email-masked]
Date: Wed, 21 Mar 2007 03:05:43 +0100

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" <[email-masked]>
Sent by: [email-masked]
20/03/2007 16:39
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        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

Thanks,
Adrian

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 21 Mar 2007 03:49:25 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, March 20, 2007 7:06 PM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: Progressing the discussion on liaison responses

adrian

o) VLAN I-D

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)

"Our comments are solicited
Cookbook objectives seem unclear (ignores GMPLS work on UNI, ENNI,
ASON)"

"-      No mention of GELS. Time to let them know?" answer is yes. the 
point is that such exchange informative ?

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

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

"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

thanks,
-d.

        To:     <[email-masked]>
        cc: 

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 22 Mar 2007 19:16:20 +0100

A way to handle the MTU issue is to signal multiple independent 
LSPs.  The LSPs could be bound together into a single logical 
connection (EVC) using the association object.  This approach could 
be used with either the VID per LSP or the multi-VID per LSP 
approach.  The difference is one of scaling and optimization; i.e., 
(a) the first has lots of LSPs, but has simple/standard VID 
change/add/drop procedures while (b) the second has few LSPs but will 
require specific procedures to handle VID changes/adds/drops.

While intuition leads me to believe that (b) is the better way to go, 
we may want to get the feedback of those presenting the requirements.

Lou