Subject: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
From: Zhi-Wei Lin <[email-masked]>
To: manoj juneja <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Kireeti Kompella <[email-masked]>
Date: Wed, 01 Aug 2001 01:13:43 -0400

Hi,

I have not heard any response to Manoj's question from the folks who
added this field as to what use it is envisioned...

Can someone enlighten me? Thanks!

Zhi

manoj juneja wrote:
> 
> Hi All,
>          I have following doubt in
> "draft-ietf-mpls-generalized-signalling-05.txt" draft.
> This draft has introduced new field switching type in Generalized
> Label Request Object. After looking at the structure of switching type
> field in latest OSPF document (GMPLS extensions to OSPF, Field Name :
> Interface switching capability descriptor), I could not make out why
> this is present in per LSP establishment request ? This field
> advertises the bandwidth (both min. and max.) for various priority
> levels (p = 0 -> 7). Furthermore, this field also contain Encoding
> (I assume LSP encoding type) field which is already there in
> Generalized Label Reqest object.
> I am not able to understand why this type of information is required
> in Per Connection Establishment Request ? Is the "switching type" field only
> applicable when FA (forwarding adjacency) need to be established ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 31 Jul 2001 20:26:41 -0700
From: "Vasant Sahay" <[email-masked]>
To: "Bilel Jamoussi" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Optical Link Interface: re send
Date: Tue, 31 Jul 2001 20:23:52 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11A39.63805F60
Content-Type: text/plain;
	charset="iso-8859-1"

Andre,
Bilel, Osama and I have discussed the LMP related extra-work with you in our
teleconference a few months ago. 
 
The scope of LMP is much wider than just OLI. Before LMP gets accepted as a
standard, there is a lot of functionality and requirements in LMP that have
to be agreed upon. Dependence on LMP will only complicate and delay OLI.
Besides, reliable transport of failure-messages is broken in LMP. The
current LMP and WDM-LMP drafts imply that the application will have to build
a mechanism for tracking and retransmitting lost messages. This translates
into additional baggage for OLI. 
 
As an example LMP has ability to isolate faults. It is not needed for OLI.
You can argue that you will reuse the same messages in OLI to report faults,
but it is not the same thing. When LMP gets fully defined with states and
procedures then we will find that the procedure for handling a failure
message between two OXCs (LMP), is very different than that for between OXC
and DWDM (OLI). As an aside my take is that failure-isolation does not even
belong fully in LMP. It is a function that belongs between
connection-management and link management.
 
There are more examples of extra work due to LMP but we can discuss them one
at a time.
 
I did a quick back of the envelope and came up with a total of 24 states and
46 events in LMP. That is a lot of states for a simple protocol. This does
not even include the application states for (potential) retransmission of
messages.
 
Cheers
Vasant

From: Andre Fredette [mailto:[email-masked]]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; [email-masked]
Subject: RE: Optical Link Interface

Bilel,

I might not have worded my response exactly as John did (being the nice guy
that I am), but I agree with his answers.

In particular, you continue to talk about "unnecessary LMP baggage", or
"complexity", but cannot describe what it is. 

Andre

At 01:24 PM 7/30/2001 -0700, John Drake wrote:

-----Original Message----- 

From: Bilel Jamoussi [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Monday, July 30, 2001 8:14 AM 

To: 'Andre Fredette'; [email-masked]' 

Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" period
announced in advance to gauge community interest. 

[John Drake] 

This is silly.  Who else would you like to hear from? 

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space. 

[John Drake] 

The fact that you perceive yourself to be a key player shouldn't a priori
give your opinion any additional weight 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a
merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are: 

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP 

[John Drake] 

What is the basis for this assertion?   When we started the LMP-WDM work we
asked you to work on it with us 

and you refused, citing lack of need. 

(b) there is significant baggage to be carried from LMP down to the WDM-LMP 

[John Drake] 

You've made this assertion inumerable times, and have been asked inumerable
times to enumerate what this 

excess baggage is.  You have yet to do so. 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one. 

[John Drake] 

This is an assertion.  Some of the co-authors of the LMP WDM draft work for
WDM vendors and  they're happy with 

the peer relationship between the two devices   

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 

[John Drake] 

Once again, this would be what? 

- adopt a client-server model 

[John Drake] 

No 

- allow for TCP as the transport 

[John Drake] 

No one but you and your co-authors think that this is either necessary or
desirable 

- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 

From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Thursday, July 26, 2001 2:52 PM 

To: [email-masked] 

Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far: 

LMP-WDM:  8 

NTIP: 3 (All from Nortel) 

Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted 

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 

>Kireeti, 

> 

>I have been following this thread with great interest. I agree with your 

>conclusion that we should pick one protocol and move forward. 

> 

>You are talking about WG reaching a consensus. I cannot see how this is 

>possible given the two very different views I see in the latest email 

>exchanges. 

> 

>How can we resolve the current dispute? What forum should we use to make 

>a final decision on this? 

> 

>Martin 

> 

>-----Original Message----- 

>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 

>Sent: Wednesday, July 25, 2001 9:57 PM 

>To: [email-masked]; [email-masked]; 

>[email-masked] 

>Cc: [email-masked]; [email-masked]; 

>[email-masked] 

>Subject: RE: Optical Link Interface 

> 

> 

>Hi Osama, 

> 

> > Even though I don't think reviving CR-LDP and RSVP-TE history will get 

>us 

> > anywhere 

> 

>"Those who forget (ignore) history are doomed to repeat it." 

> 

>Yes, it makes for painful recollections.  We're living with the 

>consequences now, though, and I don't want to again. 

> 

> > the existence of two protocols here have proven to be useful. 

> 

>That's not what I'm hearing, either from customers, or from the 

>WG (admittedly, the sample is small). 

> 

>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 

>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 

>consensus is.  LMP-WDM and LMP works too. 

> 

>So: you've got the WG chairs (scarred and grumpy), the ADs 

>and TA (speak up if I'm misrepresenting you), and customers 

>saying, Pick one protocol and move forward.  Let's do that. 

>And, please, as Vijay says, let's resolve this already. 

> 

>Kireeti. 

------_=_NextPart_001_01C11A39.63805F60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2614.3401" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2><BR></DIV></FONT>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>Andre,</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>Bilel, Osama and I have discussed the 
  LMP&nbsp;related extra-work with you in our teleconference a few months ago. 
  </SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>The scope of LMP is much wider than just OLI. <FONT 
  color=#0000ff face=Arial size=2><SPAN class=761112618-31072001>Before LMP gets 
  accepted as a standard, there is a lot of functionality and requirements in 
  LMP that have to be agreed upon. Dependence on LMP will only complicate and 
  delay OLI. Besides, reliable transport of failure-messages is broken in LMP. 
  </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>The current LMP and WDM-LMP drafts imply that the 
  application will have to build a mechanism for tracking and retransmitting 
  lost messages. This translates into additional baggage for OLI. 
  </SPAN></FONT></SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT>As an example LMP has ability to 
  isolate faults. It is not needed for OLI. You can argue that you will reuse 
  the same messages in OLI to report faults, but it is not the same thing. When 
  LMP gets fully defined with states and procedures then we will find that the 
  procedure for handling a failure message between two OXCs (LMP), is very 
  different than that for between OXC and DWDM (OLI). As an aside my 
  take&nbsp;is that failure-isolation does not even belong fully in LMP. It is a 
  function that belongs between connection-management and link 
  management.</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>There are more examples of extra work due to LMP but 
  we can discuss them one at a time.</SPAN></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr 
  style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial 
  size=2><FONT color=#0000ff face=Arial size=2><SPAN class=761112618-31072001>I 
  did a quick back of the envelope and came up with a total of 24 states and 46 
  events in LMP. That is a lot of states for a simple protocol. This does not 
  even include the application states for (potential) retransmission of 
  messages.</SPAN></FONT></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial 
  size=2><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial 
  size=2><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>Cheers</SPAN></FONT></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial 
  size=2><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001>Vasant</SPAN></FONT></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial 
  size=2><FONT color=#0000ff face=Arial size=2><SPAN 
  class=761112618-31072001></SPAN></FONT></FONT><FONT face=Tahoma 
  size=2><BR><B>From:</B> Andre Fredette 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 30, 2001 1:51 
  PM<BR><B>To:</B> Jamoussi, Bilel [BL60:1A00-M:EXCH]<BR><B>Cc:</B> John Drake; 
  [email-masked]<BR><B>Subject:</B> RE: Optical Link Interface<BR><BR></DIV>
  <DIV dir=ltr style="MARGIN-RIGHT: 0px"></FONT>Bilel,<BR><BR>I might not have 
  worded my response exactly as John did (being the nice guy that I am), but I 
  agree with his answers.<BR><BR>In particular, you continue to talk about 
  "<FONT size=2>unnecessary LMP baggage</FONT>", or "complexity", but cannot 
  describe what it is. <BR><BR>Andre<BR><BR>At 01:24 PM 7/30/2001 -0700, John 
  Drake wrote:</DIV><BR>
  <DIV class=cite dir=ltr style="MARGIN-RIGHT: 0px" cite type="cite"></DIV>
  <DIV class=cite dir=ltr style="MARGIN-RIGHT: 0px" cite type="cite">
  <DL><FONT face=tahoma size=2>
    <DD>-----Original Message----- 
    <DD>From:</B> Bilel Jamoussi [<A href="mailto:[email-masked]" 
    eudora="autourl">mailto:[email-masked]</A>] 
    <DD>Sent:</B> Monday, July 30, 2001 8:14 AM 
    <DD>To:</B> 'Andre Fredette'; [email-masked]' 
    <DD>Subject:</B> RE: Optical Link Interface<BR><BR></FONT>
    <DD>Andre, <FONT size=2>
    <DD>2 comments on you statistics, then a proposal to progress:</FONT> 
    <BR><BR><FONT size=2>
    <DD>1. The stats are not that significant, since there was no "last call" 
    period announced in advance to gauge community interest.</FONT><FONT 
    color=#0000ff face=arial size=2> 
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>This is silly.&nbsp; Who else would you like to hear from? </FONT><FONT 
    size=2>
    <DD>2. I do not think IETF uses company affiliation when measuring 
    consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, 
    is an indication that there is an immediate need for NTIP given Nortel is a 
    key player in this space.</FONT><FONT color=#0000ff face=arial size=2> 
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>The fact that you perceive yourself to be a key player shouldn't a 
    priori give your opinion any additional weight </FONT><FONT size=2>
    <DD>------</FONT> <BR><BR><FONT size=2>
    <DD>All,</FONT> <BR><BR><FONT size=2>
    <DD>Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, 
    or a merged version),</FONT> <BR><BR><FONT size=2>
    <DD>- There is consensus on a single protocol which I respect.</FONT> 
    <BR><BR><FONT size=2>
    <DD>- Key distinctions between NTIP and WDM-LMP:</FONT> <BR><BR><FONT 
size=2>
    <DD>1. WDM-LMP assumes that LMP is a priority, people will implement LMP, 
    hence WDM-LMP is a natural extension. The issues here are:</FONT><FONT 
    size=2> 
    <DD>(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) 
    are more urgent than LMP</FONT><FONT color=#0000ff face=arial size=2> 
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>What is the basis for this assertion?&nbsp;&nbsp; When we started the 
    LMP-WDM work we asked you to work on it with us</FONT><FONT color=#0000ff 
    face=arial size=2> 
    <DD>and you refused, citing lack of need.</FONT> 
    <DD><FONT size=2>
    <DD>(b) there is significant baggage to be carried from LMP down to the 
    WDM-LMP </FONT><FONT color=#0000ff face=arial size=2>
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>You've made this assertion inumerable times, and have been asked 
    inumerable times to enumerate what this</FONT><FONT color=#0000ff face=arial 
    size=2> 
    <DD>excess baggage is.&nbsp; You have yet to do so. </FONT><FONT size=2>
    <DD>2. WDM-LMP assumes a peer model between the OXC and the WDM system. The 
    issue: </FONT><FONT size=2>
    <DD>- this model doesn't reflect the reality that OXC and WDM are two 
    different devices - the OXC-WDM relationship is client-server 
    one.</FONT><FONT color=#0000ff face=arial size=2> 
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>This is an assertion.&nbsp; Some of the co-authors of the LMP WDM draft 
    work for WDM vendors and&nbsp; they're happy with</FONT><FONT color=#0000ff 
    face=arial size=2> 
    <DD>the peer relationship between the two devices&nbsp;&nbsp; </FONT><FONT 
    size=2>
    <DD>I suggest merging the two proposals as follows:</FONT> <BR><BR><FONT 
    size=2>
    <DD>- remove unnecessary LMP baggage</FONT> <FONT color=#0000ff face=arial 
    size=2>
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>Once again, this would be what?</FONT> 
    <DD>- adopt a client-server model <FONT color=#0000ff face=arial size=2>
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>No</FONT> 
    <DD>- allow for TCP as the transport <FONT color=#0000ff face=arial size=2>
    <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
    <DD>No one but you and your co-authors think that this is either necessary 
    or desirable</FONT><FONT size=2> 
    <DD>
    <DD>- clarify a simplified autodiscovery mechanism</FONT> <BR><BR><FONT 
    size=2>
    <DD>Bilel.</FONT> <BR><BR><FONT size=2>
    <DD>-----Original Message-----</FONT> <FONT size=2>
    <DD>From: Andre Fredette [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <FONT size=2>
    <DD>Sent: Thursday, July 26, 2001 2:52 PM</FONT> <FONT size=2>
    <DD>To: [email-masked]</FONT> <FONT size=2>
    <DD>Subject: RE: Optical Link Interface</FONT> <BR><BR><FONT size=2>
    <DD>&nbsp;From my count on the mailing list we have the following results so 
    far:</FONT> <BR><BR><FONT size=2>
    <DD>LMP-WDM:&nbsp; 8</FONT> <FONT size=2>
    <DD>NTIP: 3 (All from Nortel)</FONT> <FONT size=2>
    <DD>Agnostic: 1</FONT> <BR><BR><FONT size=2>
    <DD>And then there are the other 16 co-authors of LMP-WDM who haven't posted 
    </FONT><FONT size=2>
    <DD>(perhaps because they don't think they have any new points to 
    add).</FONT> <BR><BR><FONT size=2>
    <DD>Andre</FONT> <BR><BR><FONT size=2>
    <DD>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</FONT> <FONT size=2>
    <DD>&gt;Kireeti,</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;I have been following this thread with great interest. I agree with 
    your</FONT> <FONT size=2>
    <DD>&gt;conclusion that we should pick one protocol and move forward.</FONT> 
    <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;You are talking about WG reaching a consensus. I cannot see how this 
    is</FONT> <FONT size=2>
    <DD>&gt;possible given the two very different views I see in the latest 
    email</FONT> <FONT size=2>
    <DD>&gt;exchanges.</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;How can we resolve the current dispute? What forum should we use to 
    make</FONT> <FONT size=2>
    <DD>&gt;a final decision on this?</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;Martin</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;-----Original Message-----</FONT> <FONT size=2>
    <DD>&gt;From: Kireeti Kompella [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <FONT size=2>
    <DD>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> <FONT size=2>
    <DD>&gt;To: [email-masked]; [email-masked];</FONT> <FONT 
    size=2>
    <DD>&gt;[email-masked]</FONT> <FONT size=2>
    <DD>&gt;Cc: [email-masked]; [email-masked];</FONT> <FONT size=2>
    <DD>&gt;[email-masked]</FONT> <FONT size=2>
    <DD>&gt;Subject: RE: Optical Link Interface</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;Hi Osama,</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt; &gt; Even though I don't think reviving CR-LDP and RSVP-TE history 
    will get</FONT> <FONT size=2>
    <DD>&gt;us</FONT> <FONT size=2>
    <DD>&gt; &gt; anywhere</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;"Those who forget (ignore) history are doomed to repeat it."</FONT> 
    <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;Yes, it makes for painful recollections.&nbsp; We're living with 
    the</FONT> <FONT size=2>
    <DD>&gt;consequences now, though, and I don't want to again.</FONT> <FONT 
    size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt; &gt; the existence of two protocols here have proven to be 
    useful.</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;That's not what I'm hearing, either from customers, or from 
    the</FONT> <FONT size=2>
    <DD>&gt;WG (admittedly, the sample is small).</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving 
    forward.</FONT> <FONT size=2>
    <DD>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is what the WG</FONT> 
    <FONT size=2>
    <DD>&gt;consensus is.&nbsp; LMP-WDM and LMP works too.</FONT> <FONT size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</FONT> 
    <FONT size=2>
    <DD>&gt;and TA (speak up if I'm misrepresenting you), and customers</FONT> 
    <FONT size=2>
    <DD>&gt;saying, Pick one protocol and move forward.&nbsp; Let's do 
    that.</FONT> <FONT size=2>
    <DD>&gt;And, please, as Vijay says, let's resolve this already.</FONT> <FONT 
    size=2>
    <DD>&gt;</FONT> <FONT size=2>
    <DD>&gt;Kireeti.</FONT> </DD></DL></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11A39.63805F60--

Delivery-date: Tue, 31 Jul 2001 20:20:04 -0700
From: "Vasant Sahay" <[email-masked]>
To: "Bilel Jamoussi" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Optical Link Interface
Date: Tue, 31 Jul 2001 20:17:46 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11A38.890CE920
Content-Type: text/plain;
	charset="iso-8859-1"

Andre,
Bilel, Osama and I have discussed the LMP related extra-work with you in our
teleconference a few months ago. 
 
The scope of LMP is much wider than just OLI. Before LMP gets accepted as a
standard, there is a lot of functionality and requirements in LMP that have
to be agreed upon. Dependence on LMP will only complicate and delay OLI.
Besides, reliable transport of failure-messages is broken in LMP. The
current LMP and WDM-LMP drafts imply that the application will have to build
a mechanism for tracking and retransmitting lost messages. This translates
into additional baggage for OLI. 
 
As an example LMP has ability to isolate faults. It is not needed for OLI.
You can argue that you will reuse the same messages in OLI to report faults,
but it is not the same thing. When LMP gets fully defined with states and
procedures then we will find that the procedure for handling a failure
message between two OXCs (LMP), is very different than that for between OXC
and DWDM (OLI). As an aside my take is that failure-isolation does not even
belong fully in LMP. It is a function that belongs between
connection-management and link management.
 
There are more examples of extra work due to LMP but we can discuss them one
at a time.
 
I did a quick back of the envelope and came up with a total of 24 states and
46 events in LMP. That is a lot of states for a simple protocol. This does
not even include the application states for (potential) retransmission of
messages.
 
Cheers
Vasant

From: Andre Fredette [mailto:[email-masked]]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; [email-masked]
Subject: RE: Optical Link Interface

Bilel,

I might not have worded my response exactly as John did (being the nice guy
that I am), but I agree with his answers.

In particular, you continue to talk about "unnecessary LMP baggage", or
"complexity", but cannot describe what it is. 

Andre

At 01:24 PM 7/30/2001 -0700, John Drake wrote:

-----Original Message----- 

From: Bilel Jamoussi [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Monday, July 30, 2001 8:14 AM 

To: 'Andre Fredette'; [email-masked]' 

Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" period
announced in advance to gauge community interest. 

[John Drake] 

This is silly.  Who else would you like to hear from? 

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space. 

[John Drake] 

The fact that you perceive yourself to be a key player shouldn't a priori
give your opinion any additional weight 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a
merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are: 

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP 

[John Drake] 

What is the basis for this assertion?   When we started the LMP-WDM work we
asked you to work on it with us 

and you refused, citing lack of need. 

(b) there is significant baggage to be carried from LMP down to the WDM-LMP 

[John Drake] 

You've made this assertion inumerable times, and have been asked inumerable
times to enumerate what this 

excess baggage is.  You have yet to do so. 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one. 

[John Drake] 

This is an assertion.  Some of the co-authors of the LMP WDM draft work for
WDM vendors and  they're happy with 

the peer relationship between the two devices   

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 

[John Drake] 

Once again, this would be what? 

- adopt a client-server model 

[John Drake] 

No 

- allow for TCP as the transport 

[John Drake] 

No one but you and your co-authors think that this is either necessary or
desirable 

- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 

From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Thursday, July 26, 2001 2:52 PM 

To: [email-masked] 

Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far: 

LMP-WDM:  8 

NTIP: 3 (All from Nortel) 

Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted 

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 

>Kireeti, 

> 

>I have been following this thread with great interest. I agree with your 

>conclusion that we should pick one protocol and move forward. 

> 

>You are talking about WG reaching a consensus. I cannot see how this is 

>possible given the two very different views I see in the latest email 

>exchanges. 

> 

>How can we resolve the current dispute? What forum should we use to make 

>a final decision on this? 

> 

>Martin 

> 

>-----Original Message----- 

>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 

>Sent: Wednesday, July 25, 2001 9:57 PM 

>To: [email-masked]; [email-masked]; 

>[email-masked] 

>Cc: [email-masked]; [email-masked]; 

>[email-masked] 

>Subject: RE: Optical Link Interface 

> 

> 

>Hi Osama, 

> 

> > Even though I don't think reviving CR-LDP and RSVP-TE history will get 

>us 

> > anywhere 

> 

>"Those who forget (ignore) history are doomed to repeat it." 

> 

>Yes, it makes for painful recollections.  We're living with the 

>consequences now, though, and I don't want to again. 

> 

> > the existence of two protocols here have proven to be useful. 

> 

>That's not what I'm hearing, either from customers, or from the 

>WG (admittedly, the sample is small). 

> 

>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 

>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 

>consensus is.  LMP-WDM and LMP works too. 

> 

>So: you've got the WG chairs (scarred and grumpy), the ADs 

>and TA (speak up if I'm misrepresenting you), and customers 

>saying, Pick one protocol and move forward.  Let's do that. 

>And, please, as Vijay says, let's resolve this already. 

> 

>Kireeti. 

------_=_NextPart_001_01C11A38.890CE920
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2614.3401" name=GENERATOR></HEAD>
<BODY>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>Andre,</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>Bilel, Osama and I have discussed the LMP&nbsp;related 
extra-work with you in our teleconference a few months ago. </SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>The scope of LMP is much wider than just OLI. <FONT 
color=#0000ff face=Arial size=2><SPAN class=761112618-31072001>Before LMP gets 
accepted as a standard, there is a lot of functionality and requirements in LMP 
that have to be agreed upon. Dependence on LMP will only complicate and delay 
OLI. Besides, reliable transport of failure-messages is broken in LMP. 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>The current LMP and WDM-LMP drafts imply that the 
application will have to build a mechanism for tracking and retransmitting lost 
messages. This translates into additional baggage for OLI. 
</SPAN></FONT></SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT>As an example LMP has ability to isolate 
faults. It is not needed for OLI. You can argue that you will reuse the same 
messages in OLI to report faults, but it is not the same thing. When LMP gets 
fully defined with states and procedures then we will find that the procedure 
for handling a failure message between two OXCs (LMP), is very different than 
that for between OXC and DWDM (OLI). As an aside my take&nbsp;is that 
failure-isolation does not even belong fully in LMP. It is a function that 
belongs between connection-management and link management.</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>There are more examples of extra work due to LMP but we 
can discuss them one at a time.</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr 
style="MARGIN-RIGHT: 0px"><FONT color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial size=2><FONT 
color=#0000ff face=Arial size=2><SPAN class=761112618-31072001>I did a quick 
back of the envelope and came up with a total of 24 states and 46 events in LMP. 
That is a lot of states for a simple protocol. This does not even include the 
application states for (potential) retransmission of 
messages.</SPAN></FONT></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial size=2><FONT 
color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial size=2><FONT 
color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>Cheers</SPAN></FONT></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial size=2><FONT 
color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001>Vasant</SPAN></FONT></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Arial size=2><FONT 
color=#0000ff face=Arial size=2><SPAN 
class=761112618-31072001></SPAN></FONT></FONT><FONT face=Tahoma 
size=2><BR><B>From:</B> Andre Fredette 
[mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 30, 2001 1:51 
PM<BR><B>To:</B> Jamoussi, Bilel [BL60:1A00-M:EXCH]<BR><B>Cc:</B> John Drake; 
[email-masked]<BR><B>Subject:</B> RE: Optical Link Interface<BR><BR></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"></FONT>Bilel,<BR><BR>I might not have 
worded my response exactly as John did (being the nice guy that I am), but I 
agree with his answers.<BR><BR>In particular, you continue to talk about "<FONT 
size=2>unnecessary LMP baggage</FONT>", or "complexity", but cannot describe 
what it is. <BR><BR>Andre<BR><BR>At 01:24 PM 7/30/2001 -0700, John Drake 
wrote:</DIV><BR>
<DIV class=cite dir=ltr style="MARGIN-RIGHT: 0px" type="cite" cite> </DIV>
<DIV class=cite dir=ltr style="MARGIN-RIGHT: 0px" type="cite" cite>
<DL><FONT face=tahoma size=2>
  <DD>-----Original Message----- 
  <DD>From:</B> Bilel Jamoussi [<A href="mailto:[email-masked]" 
  eudora="autourl">mailto:[email-masked]</A>] 
  <DD>Sent:</B> Monday, July 30, 2001 8:14 AM 
  <DD>To:</B> 'Andre Fredette'; [email-masked]' 
  <DD>Subject:</B> RE: Optical Link Interface<BR><BR></FONT>
  <DD>Andre, <FONT size=2>
  <DD>2 comments on you statistics, then a proposal to progress:</FONT> 
  <BR><BR><FONT size=2>
  <DD>1. The stats are not that significant, since there was no "last call" 
  period announced in advance to gauge community interest.</FONT><FONT 
  color=#0000ff face=arial size=2> 
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>This is silly.&nbsp; Who else would you like to hear from? </FONT><FONT 
  size=2>
  <DD>2. I do not think IETF uses company affiliation when measuring consensus. 
  If it did, then the fact that 3 from Nortel are supporting NTIP, is an 
  indication that there is an immediate need for NTIP given Nortel is a key 
  player in this space.</FONT><FONT color=#0000ff face=arial size=2> 
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>The fact that you perceive yourself to be a key player shouldn't a priori 
  give your opinion any additional weight </FONT><FONT size=2>
  <DD>------</FONT> <BR><BR><FONT size=2>
  <DD>All,</FONT> <BR><BR><FONT size=2>
  <DD>Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or 
  a merged version),</FONT> <BR><BR><FONT size=2>
  <DD>- There is consensus on a single protocol which I respect.</FONT> 
  <BR><BR><FONT size=2>
  <DD>- Key distinctions between NTIP and WDM-LMP:</FONT> <BR><BR><FONT size=2>
  <DD>1. WDM-LMP assumes that LMP is a priority, people will implement LMP, 
  hence WDM-LMP is a natural extension. The issues here are:</FONT><FONT size=2> 

  <DD>(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) 
  are more urgent than LMP</FONT><FONT color=#0000ff face=arial size=2> 
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>What is the basis for this assertion?&nbsp;&nbsp; When we started the 
  LMP-WDM work we asked you to work on it with us</FONT><FONT color=#0000ff 
  face=arial size=2> 
  <DD>and you refused, citing lack of need.</FONT> 
  <DD><FONT size=2>
  <DD>(b) there is significant baggage to be carried from LMP down to the 
  WDM-LMP </FONT><FONT color=#0000ff face=arial size=2>
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>You've made this assertion inumerable times, and have been asked 
  inumerable times to enumerate what this</FONT><FONT color=#0000ff face=arial 
  size=2> 
  <DD>excess baggage is.&nbsp; You have yet to do so. </FONT><FONT size=2>
  <DD>2. WDM-LMP assumes a peer model between the OXC and the WDM system. The 
  issue: </FONT><FONT size=2>
  <DD>- this model doesn't reflect the reality that OXC and WDM are two 
  different devices - the OXC-WDM relationship is client-server one.</FONT><FONT 
  color=#0000ff face=arial size=2> 
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>This is an assertion.&nbsp; Some of the co-authors of the LMP WDM draft 
  work for WDM vendors and&nbsp; they're happy with</FONT><FONT color=#0000ff 
  face=arial size=2> 
  <DD>the peer relationship between the two devices&nbsp;&nbsp; </FONT><FONT 
  size=2>
  <DD>I suggest merging the two proposals as follows:</FONT> <BR><BR><FONT 
  size=2>
  <DD>- remove unnecessary LMP baggage</FONT> <FONT color=#0000ff face=arial 
  size=2>
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>Once again, this would be what?</FONT> 
  <DD>- adopt a client-server model <FONT color=#0000ff face=arial size=2>
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>No</FONT> 
  <DD>- allow for TCP as the transport <FONT color=#0000ff face=arial size=2>
  <DD>[John Drake] </FONT><FONT color=#0000ff face=arial size=2>
  <DD>No one but you and your co-authors think that this is either necessary or 
  desirable</FONT><FONT size=2> 
  <DD>
  <DD>- clarify a simplified autodiscovery mechanism</FONT> <BR><BR><FONT 
size=2>
  <DD>Bilel.</FONT> <BR><BR><FONT size=2>
  <DD>-----Original Message-----</FONT> <FONT size=2>
  <DD>From: Andre Fredette [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
  <FONT size=2>
  <DD>Sent: Thursday, July 26, 2001 2:52 PM</FONT> <FONT size=2>
  <DD>To: [email-masked]</FONT> <FONT size=2>
  <DD>Subject: RE: Optical Link Interface</FONT> <BR><BR><FONT size=2>
  <DD>&nbsp;From my count on the mailing list we have the following results so 
  far:</FONT> <BR><BR><FONT size=2>
  <DD>LMP-WDM:&nbsp; 8</FONT> <FONT size=2>
  <DD>NTIP: 3 (All from Nortel)</FONT> <FONT size=2>
  <DD>Agnostic: 1</FONT> <BR><BR><FONT size=2>
  <DD>And then there are the other 16 co-authors of LMP-WDM who haven't posted 
  </FONT><FONT size=2>
  <DD>(perhaps because they don't think they have any new points to add).</FONT> 
  <BR><BR><FONT size=2>
  <DD>Andre</FONT> <BR><BR><FONT size=2>
  <DD>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</FONT> <FONT size=2>
  <DD>&gt;Kireeti,</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;I have been following this thread with great interest. I agree with 
  your</FONT> <FONT size=2>
  <DD>&gt;conclusion that we should pick one protocol and move forward.</FONT> 
  <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;You are talking about WG reaching a consensus. I cannot see how this 
  is</FONT> <FONT size=2>
  <DD>&gt;possible given the two very different views I see in the latest 
  email</FONT> <FONT size=2>
  <DD>&gt;exchanges.</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;How can we resolve the current dispute? What forum should we use to 
  make</FONT> <FONT size=2>
  <DD>&gt;a final decision on this?</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;Martin</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;-----Original Message-----</FONT> <FONT size=2>
  <DD>&gt;From: Kireeti Kompella [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <FONT 
  size=2>
  <DD>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> <FONT size=2>
  <DD>&gt;To: [email-masked]; [email-masked];</FONT> <FONT 
  size=2>
  <DD>&gt;[email-masked]</FONT> <FONT size=2>
  <DD>&gt;Cc: [email-masked]; [email-masked];</FONT> <FONT size=2>
  <DD>&gt;[email-masked]</FONT> <FONT size=2>
  <DD>&gt;Subject: RE: Optical Link Interface</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;Hi Osama,</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt; &gt; Even though I don't think reviving CR-LDP and RSVP-TE history 
  will get</FONT> <FONT size=2>
  <DD>&gt;us</FONT> <FONT size=2>
  <DD>&gt; &gt; anywhere</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;"Those who forget (ignore) history are doomed to repeat it."</FONT> 
  <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;Yes, it makes for painful recollections.&nbsp; We're living with 
  the</FONT> <FONT size=2>
  <DD>&gt;consequences now, though, and I don't want to again.</FONT> <FONT 
  size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt; &gt; the existence of two protocols here have proven to be 
  useful.</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;That's not what I'm hearing, either from customers, or from the</FONT> 
  <FONT size=2>
  <DD>&gt;WG (admittedly, the sample is small).</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving forward.</FONT> 
  <FONT size=2>
  <DD>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is what the WG</FONT> 
  <FONT size=2>
  <DD>&gt;consensus is.&nbsp; LMP-WDM and LMP works too.</FONT> <FONT size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</FONT> 
  <FONT size=2>
  <DD>&gt;and TA (speak up if I'm misrepresenting you), and customers</FONT> 
  <FONT size=2>
  <DD>&gt;saying, Pick one protocol and move forward.&nbsp; Let's do 
  that.</FONT> <FONT size=2>
  <DD>&gt;And, please, as Vijay says, let's resolve this already.</FONT> <FONT 
  size=2>
  <DD>&gt;</FONT> <FONT size=2>
  <DD>&gt;Kireeti.</FONT> </DD></DL></DIV></BODY></HTML>

------_=_NextPart_001_01C11A38.890CE920--

Delivery-date: Tue, 31 Jul 2001 14:18:10 -0700
From: "Dawkins, Spencer" <[email-masked]>
To: "[email-masked]' ' '" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Tue, 31 Jul 2001 16:17:01 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11A06.2405A440
Content-Type: text/plain;
	charset="iso-8859-1"

Dear Vasant,
 
OK, I'll bite.
 
My copy of TCP/IP Illustrated, volume 1, shows TCP doing exponential backoff (page 299), at a pretty leisurely pace, for about nine minutes before giving up. This is, of course, measured using a general-purpose OS, but at some point - well, how long were you planning to wait for TCP retransmissions?
 
I am somewhat confused as to how this lines up with successfully retransmitting lost "events" in 10s of ms.
 
I am somewhat confused as to how using TCP (with exponential retransmission timers) is a substitute for application-level timers. If you have to run application-level timers anyway... well, I thought that was where SCTP came from!
 
If you guys were flogging SCTP, I would still be confused, but at least I would think that you weren't ignoring decades of wailing about using TCP for real-time signaling. http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html#TopOfPage <http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html#TopOfPage>  is an interesting overview, but doesn't BEGIN to reflect the volume level.
 
Thanks for any insights you can provide.
 
Spencer

------_=_NextPart_001_01C11A06.2405A440
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM>Dear Vasant,</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM></EM></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM>OK, I'll bite.</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM><FONT color=3D#800000 face=3DArial =
size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT></EM></SPAN></FONT>&nbsp;</DIV>=

<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM><FONT color=3D#800000 face=3DArial =
size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT>My copy of TCP/IP Illustrated, =
volume 1,=20
shows TCP doing exponential backoff (page 299), at a pretty leisurely =
pace, for=20
about nine minutes before giving up. This is, of course, measured using =
a=20
general-purpose OS, but at some point - well, how long were you =
planning to wait=20
for TCP retransmissions?</EM></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN =
class=3D763284220-31072001><EM>I=20
am somewhat confused as to how this lines up with successfully =
retransmitting=20
lost "events" in 10s of ms.</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN =
class=3D763284220-31072001><EM>I=20
am somewhat confused as to how using TCP (with exponential =
retransmission=20
timers) is a substitute for application-level timers. If you have to =
run=20
application-level timers anyway... well, I thought that was where SCTP =
came=20
from!</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN =
class=3D763284220-31072001><EM>If=20
you guys were flogging SCTP, I would still be confused, but at =
least&nbsp;I=20
would think that you weren't ignoring&nbsp;decades of wailing about =
using TCP=20
for real-time signaling. <A=20
href=3D"http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html#T=
opOfPage">http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html=
#TopOfPage</A>&nbsp;is=20
an interesting overview, but doesn't BEGIN to reflect the volume=20
level.</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM>Thanks for any insights you can=20
provide.</EM></SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3DArial size=3D2><SPAN=20
class=3D763284220-31072001><EM>Spencer</EM></SPAN></FONT></DIV></BODY></=
HTML>

------_=_NextPart_001_01C11A06.2405A440--

Delivery-date: Tue, 31 Jul 2001 13:34:44 -0700
From: "Vasant Sahay" <[email-masked]>
To: Jonathan Lang <[email-masked]>, "'Mannie, Eric '" <[email-masked]>, "Bilel Jamoussi" <[email-masked]>, "'''Andre Fredette' ' '" <[email-masked]>, "[email-masked]' ' '" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Tue, 31 Jul 2001 13:31:59 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C119FF.D90605D0
Content-Type: text/plain;
	charset="iso-8859-1"

Jonathan,
My comments are in the text.

Regards
Vasant

-----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 11:55 AM
To: Sahay, Vasant [SC9:6909:EXCH]; 'Mannie, Eric '; Jamoussi, Bilel
[BL60:1A00-M:EXCH]; '''Andre Fredette' ' '; [email-masked]' ' '
Subject: RE: Optical Link Interface

Vasant,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Vasant Sahay
To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' ';
[email-masked]' '
Sent: 7/30/2001 4:34 PM
Subject: RE: Optical Link Interface

>>>>>>>>From my point of view, I don't see any reason to replace a
protocol by 
>>>>>>>>another one if they have the same functionalities. 

>The misconception here is that they have the same functionalities and
>that LMP definition is complete. I believe there is a lot of discussion
>and thought that needs to go into LMP if used as basis for OLI. WDM-LMP
>being based on LMP will also suffer that thrash.
[Jonathan]...and NTIP is complete and will not suffer any thrashing?
[vasant]---- NTIP has a much smaller scope than LMP. It focuses on OXC-WDM
only. Hence the thrash (if at all) will be much less.

>Let us start with reliable transport(or lack thereof). 
>How are failures conveyed reliably from WDM to OXC ? 
>
>LMP defines ACK messages, however I couldnt find any reference to how
>they should be used to recover lost messages.
[Jonathan]Failures notification is idempotent.  LMP is optimized to
react to alarms rapidly and doesn't require stop-and-wait procedures.
Alarms are treated as independent events.  Eash alarm is transmitted until
acknowledged (see Section 6).  If an alarm status changes, prior to
receiving the Ack, the new status is simply transmitted.
For a procedural reference, LMP works very much like that of RSVP-TE
message Ids in RFC2961.
[vasant]-----that is a lot of traffic.Could cause bottlenecks. Also unlike
the usual "telecom alarms" these events (I prefer that name) need to be
successfully received in "real time"(failure reporting ---say 10
millisecond). Which means the periodic transmission rate will be 10s of
milliseconds--until acknowledged. That will create a lot of traffic for
sure.The situation is not the same as RSVP refresh here. The refresh rate
will need to be much higher than RSVP.

>WDM-LMP draft specifies that an ACK should be sent for each
>channelStatus message. This level of definition is far from complete.
>
>So the question is if a few hundred failures were reported, what is the
>nature of this ACK scheme for recovering lost messages ? Are we going
to
>recommend a stop and wait protocol or a sliding window protocol ? (A
>stop and wait scheme is easy to implement but slow at recovering
>messages ) Or is the recovery scheme beyond the scope of the protocol ?
[Jonathan]Currently, a window size is intentionally not specified.  We
can add a recommendation in terms of message transmission and processing if
that is helpful.
[vasant]-----it is not that simple. Once you enter the world of sliding
window protocols, you have to test out the window sizes and timers for
different networks and operating systems.What I meant by reinventing TCP was
this maturing cycle and the sliding window part.Why put implementors through
this pain when a readymade solution is available in TCP?

[vasant]----I see a contradiction in your statement. May be you can clarify.
Earlier you said you retransmit alarms until acknowledged. If you take that
approcah you dont need any protocol for message recovery-and you dont need
any window sizes. So are you recommending the "alarm-retransmission method"
or the "window protocol method" ?

>If a sliding window is chosen, the implementor will develop code to
>reinvent what TCP does and will have to go through a maturing cycle for
>his  sliding window scheme. There will also be implementation issues
>with managing real time OS timers at application level.
[Jonathan]We certainly don't want to reinvent TCP.  We don't need such a
heavy-weight protocol for this interface.  What we need is a reliable
lightweight messaging protocol that can react to failures rapidly.

>Keep in mind the WDM vendors are not in the business of developing
>transmission protocols for reliablity.They need a solution that can be
>easily added to their existing systems, many of which are legacy
>systems.
>  
>In contrast NTIP has thought through these issues and uses TCP as the
>reliable transport. 
>
>
>To start with that is one fundamental difference in the transport of
>NTIP vs LMP or WDM-LMP 
>
>I am concerned about such open items in LMP which will come to haunt
OLI
>later. 
>
>Vasant 

-----Original Message----- 
From: Mannie, Eric [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, July 30, 2001 3:21 PM 
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' '; 
[email-masked]' ' 
Subject: RE: Optical Link Interface 

Dear all, 

>1. The stats are not that significant, since there was no "last call" 
period announced in advance to gauge community interest. 

Well, at least it shows some preferences for a specification based on an

existing protocol on which the IETF is working since a while and that
was 
accepted as a WG document. 

>From my point of view, I don't see any reason to replace a protocol by 
another one if they have the same functionalities. 

So, 

LMP-WDM:  8  +  1 = 9. 

Kind regards, 

Eric 

Eric Mannie 
EBONE 

-----Original Message----- 
From: Bilel Jamoussi 
To: 'Andre Fredette'; [email-masked]' 
Sent: 7/30/01 5:14 PM 
Subject: RE: Optical Link Interface 

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" 
period announced in advance to gauge community interest. 

2. I do not think IETF uses company affiliation when measuring 
consensus. If it did, then the fact that 3 from Nortel are supporting 
NTIP, is an indication that there is an immediate need for NTIP given 
Nortel is a key player in this space. 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, 
or a merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, 
hence WDM-LMP is a natural extension. The issues here are: 

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) 
are more urgent than LMP 
(b) there is significant baggage to be carried from LMP down to the 
WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The 
issue: 

- this model doesn't reflect the reality that OXC and WDM are two 
different devices - the OXC-WDM relationship is client-server one. 

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
- adopt a client-server model 
- allow for TCP as the transport 
- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with 
your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to 
make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will 
get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

------_=_NextPart_001_01C119FF.D90605D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jonathan,</FONT>
<BR><FONT SIZE=3D2>My comments are in the text.</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Vasant</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Lang [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, July 31, 2001 11:55 AM</FONT>
<BR><FONT SIZE=3D2>To: Sahay, Vasant [SC9:6909:EXCH]; 'Mannie, Eric '; =
Jamoussi, Bilel</FONT>
<BR><FONT SIZE=3D2>[BL60:1A00-M:EXCH]; '''Andre Fredette' ' '; =
[email-masked]' ' '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Vasant,</FONT>
<BR><FONT SIZE=3D2>&nbsp; Please see inline.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Jonathan</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Vasant Sahay</FONT>
<BR><FONT SIZE=3D2>To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' =
';</FONT>
<BR><FONT SIZE=3D2>[email-masked]' '</FONT>
<BR><FONT SIZE=3D2>Sent: 7/30/2001 4:34 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;From my point of =
view, I don't see any reason to replace a</FONT>
<BR><FONT SIZE=3D2>protocol by </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;another one if they =
have the same functionalities. </FONT>
</P>

<P><FONT SIZE=3D2>&gt;The misconception here is that they have the same =
functionalities and</FONT>
<BR><FONT SIZE=3D2>&gt;that LMP definition is complete. I believe there =
is a lot of discussion</FONT>
<BR><FONT SIZE=3D2>&gt;and thought that needs to go into LMP if used as =
basis for OLI. WDM-LMP</FONT>
<BR><FONT SIZE=3D2>&gt;being based on LMP will also suffer that =
thrash.</FONT>
<BR><FONT SIZE=3D2>[Jonathan]...and NTIP is complete and will not =
suffer any thrashing?</FONT>
<BR><FONT SIZE=3D2>[vasant]---- NTIP has a much smaller scope than LMP. =
It focuses on OXC-WDM only. Hence the thrash (if at all) will be much =
less.</FONT></P>

<P><FONT SIZE=3D2>&gt;Let us start with reliable transport(or lack =
thereof). </FONT>
<BR><FONT SIZE=3D2>&gt;How are failures conveyed reliably from WDM to =
OXC ? </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;LMP defines ACK messages, however I couldnt find =
any reference to how</FONT>
<BR><FONT SIZE=3D2>&gt;they should be used to recover lost =
messages.</FONT>
<BR><FONT SIZE=3D2>[Jonathan]Failures notification is idempotent.&nbsp; =
LMP is optimized to</FONT>
<BR><FONT SIZE=3D2>react to alarms rapidly and doesn't require =
stop-and-wait procedures.</FONT>
<BR><FONT SIZE=3D2>Alarms are treated as independent events.&nbsp; Eash =
alarm is transmitted until</FONT>
<BR><FONT SIZE=3D2>acknowledged (see Section 6).&nbsp; If an alarm =
status changes, prior to</FONT>
<BR><FONT SIZE=3D2>receiving the Ack, the new status is simply =
transmitted.</FONT>
<BR><FONT SIZE=3D2>For a procedural reference, LMP works very much like =
that of RSVP-TE</FONT>
<BR><FONT SIZE=3D2>message Ids in RFC2961.</FONT>
<BR><FONT SIZE=3D2>[vasant]-----that is a lot of traffic.Could cause =
bottlenecks. Also unlike the usual &quot;telecom alarms&quot; these =
events (I prefer that name) need to be successfully received in =
&quot;real time&quot;(failure reporting ---say 10 millisecond). Which =
means the periodic transmission rate will be 10s of milliseconds--until =
acknowledged. That will create a lot of traffic for sure.The situation =
is not the same as RSVP refresh here. The refresh rate will need to be =
much higher than RSVP.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt;WDM-LMP draft specifies that an ACK should be =
sent for each</FONT>
<BR><FONT SIZE=3D2>&gt;channelStatus message. This level of definition =
is far from complete.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;So the question is if a few hundred failures =
were reported, what is the</FONT>
<BR><FONT SIZE=3D2>&gt;nature of this ACK scheme for recovering lost =
messages ? Are we going</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>&gt;recommend a stop and wait protocol or a sliding =
window protocol ? (A</FONT>
<BR><FONT SIZE=3D2>&gt;stop and wait scheme is easy to implement but =
slow at recovering</FONT>
<BR><FONT SIZE=3D2>&gt;messages ) Or is the recovery scheme beyond the =
scope of the protocol ?</FONT>
<BR><FONT SIZE=3D2>[Jonathan]Currently, a window size is intentionally =
not specified.&nbsp; We</FONT>
<BR><FONT SIZE=3D2>can add a recommendation in terms of message =
transmission and processing if</FONT>
<BR><FONT SIZE=3D2>that is helpful.</FONT>
<BR><FONT SIZE=3D2>[vasant]-----it is not that simple. Once you enter =
the world of sliding window protocols, you have to test out the window =
sizes and timers for different networks and operating systems.What I =
meant by reinventing TCP was this maturing cycle and the sliding window =
part.Why put implementors through this pain when a readymade solution =
is available in TCP?</FONT></P>

<P><FONT SIZE=3D2>[vasant]----I see a contradiction in your statement. =
May be you can clarify. Earlier you said you retransmit alarms until =
acknowledged. If you take that approcah you dont need any protocol for =
message recovery-and you dont need any window sizes. So are you =
recommending the &quot;alarm-retransmission method&quot; or the =
&quot;window protocol method&quot; ?</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt;If a sliding window is chosen, the implementor =
will develop code to</FONT>
<BR><FONT SIZE=3D2>&gt;reinvent what TCP does and will have to go =
through a maturing cycle for</FONT>
<BR><FONT SIZE=3D2>&gt;his&nbsp; sliding window scheme. There will also =
be implementation issues</FONT>
<BR><FONT SIZE=3D2>&gt;with managing real time OS timers at application =
level.</FONT>
<BR><FONT SIZE=3D2>[Jonathan]We certainly don't want to reinvent =
TCP.&nbsp; We don't need such a</FONT>
<BR><FONT SIZE=3D2>heavy-weight protocol for this interface.&nbsp; What =
we need is a reliable</FONT>
<BR><FONT SIZE=3D2>lightweight messaging protocol that can react to =
failures rapidly.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Keep in mind the WDM vendors are not in the =
business of developing</FONT>
<BR><FONT SIZE=3D2>&gt;transmission protocols for reliablity.They need =
a solution that can be</FONT>
<BR><FONT SIZE=3D2>&gt;easily added to their existing systems, many of =
which are legacy</FONT>
<BR><FONT SIZE=3D2>&gt;systems.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;In contrast NTIP has thought through these =
issues and uses TCP as the</FONT>
<BR><FONT SIZE=3D2>&gt;reliable transport. </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;To start with that is one fundamental difference =
in the transport of</FONT>
<BR><FONT SIZE=3D2>&gt;NTIP vs LMP or WDM-LMP </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I am concerned about such open items in LMP =
which will come to haunt</FONT>
<BR><FONT SIZE=3D2>OLI</FONT>
<BR><FONT SIZE=3D2>&gt;later. </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Vasant </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Mannie, Eric [ <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></=
FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&g=
t; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 30, 2001 3:21 PM </FONT>
<BR><FONT SIZE=3D2>To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre =
Fredette' '; </FONT>
<BR><FONT SIZE=3D2>[email-masked]' ' </FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dear all, </FONT>
</P>

<P><FONT SIZE=3D2>&gt;1. The stats are not that significant, since =
there was no &quot;last call&quot; </FONT>
<BR><FONT SIZE=3D2>period announced in advance to gauge community =
interest. </FONT>
</P>

<P><FONT SIZE=3D2>Well, at least it shows some preferences for a =
specification based on an</FONT>
</P>

<P><FONT SIZE=3D2>existing protocol on which the IETF is working since =
a while and that</FONT>
<BR><FONT SIZE=3D2>was </FONT>
<BR><FONT SIZE=3D2>accepted as a WG document. </FONT>
</P>

<P><FONT SIZE=3D2>From my point of view, I don't see any reason to =
replace a protocol by </FONT>
<BR><FONT SIZE=3D2>another one if they have the same functionalities. =
</FONT>
</P>

<P><FONT SIZE=3D2>So, </FONT>
</P>

<P><FONT SIZE=3D2>LMP-WDM:&nbsp; 8&nbsp; +&nbsp; 1 =3D 9. </FONT>
</P>

<P><FONT SIZE=3D2>Kind regards, </FONT>
</P>

<P><FONT SIZE=3D2>Eric </FONT>
</P>

<P><FONT SIZE=3D2>Eric Mannie </FONT>
<BR><FONT SIZE=3D2>EBONE </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Bilel Jamoussi </FONT>
<BR><FONT SIZE=3D2>To: 'Andre Fredette'; [email-masked]' </FONT>
<BR><FONT SIZE=3D2>Sent: 7/30/01 5:14 PM </FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface </FONT>
</P>

<P><FONT SIZE=3D2>Andre, </FONT>
</P>

<P><FONT SIZE=3D2>2 comments on you statistics, then a proposal to =
progress: </FONT>
</P>

<P><FONT SIZE=3D2>1. The stats are not that significant, since there =
was no &quot;last call&quot; </FONT>
<BR><FONT SIZE=3D2>period announced in advance to gauge community =
interest. </FONT>
</P>

<P><FONT SIZE=3D2>2. I do not think IETF uses company affiliation when =
measuring </FONT>
<BR><FONT SIZE=3D2>consensus. If it did, then the fact that 3 from =
Nortel are supporting </FONT>
<BR><FONT SIZE=3D2>NTIP, is an indication that there is an immediate =
need for NTIP given </FONT>
<BR><FONT SIZE=3D2>Nortel is a key player in this space. </FONT>
</P>

<P><FONT SIZE=3D2>------ </FONT>
</P>

<P><FONT SIZE=3D2>All, </FONT>
</P>

<P><FONT SIZE=3D2>Now to focus the discussion back on the OLI solutions =
(NTIP or LMP-WDM, </FONT>
<BR><FONT SIZE=3D2>or a merged version), </FONT>
</P>

<P><FONT SIZE=3D2>- There is consensus on a single protocol which I =
respect. </FONT>
</P>

<P><FONT SIZE=3D2>- Key distinctions between NTIP and WDM-LMP: </FONT>
</P>

<P><FONT SIZE=3D2>1. WDM-LMP assumes that LMP is a priority, people =
will implement LMP, </FONT>
<BR><FONT SIZE=3D2>hence WDM-LMP is a natural extension. The issues =
here are: </FONT>
</P>

<P><FONT SIZE=3D2>(a) this assumption is not accurate, the functions of =
NTIP (or WDM-LMP) </FONT>
<BR><FONT SIZE=3D2>are more urgent than LMP </FONT>
<BR><FONT SIZE=3D2>(b) there is significant baggage to be carried from =
LMP down to the </FONT>
<BR><FONT SIZE=3D2>WDM-LMP </FONT>
</P>

<P><FONT SIZE=3D2>2. WDM-LMP assumes a peer model between the OXC and =
the WDM system. The </FONT>
<BR><FONT SIZE=3D2>issue: </FONT>
</P>

<P><FONT SIZE=3D2>- this model doesn't reflect the reality that OXC and =
WDM are two </FONT>
<BR><FONT SIZE=3D2>different devices - the OXC-WDM relationship is =
client-server one. </FONT>
</P>

<P><FONT SIZE=3D2>I suggest merging the two proposals as follows: =
</FONT>
</P>

<P><FONT SIZE=3D2>- remove unnecessary LMP baggage </FONT>
<BR><FONT SIZE=3D2>- adopt a client-server model </FONT>
<BR><FONT SIZE=3D2>- allow for TCP as the transport </FONT>
<BR><FONT SIZE=3D2>- clarify a simplified autodiscovery mechanism =
</FONT>
</P>

<P><FONT SIZE=3D2>Bilel. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Andre Fredette [ <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></=
FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&g=
t;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&lt; <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A> =
&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&g=
t; &gt; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 26, 2001 2:52 PM </FONT>
<BR><FONT SIZE=3D2>To: [email-masked] </FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;From my count on the mailing list we have the =
following results so far:</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>LMP-WDM:&nbsp; 8 </FONT>
<BR><FONT SIZE=3D2>NTIP: 3 (All from Nortel) </FONT>
<BR><FONT SIZE=3D2>Agnostic: 1 </FONT>
</P>

<P><FONT SIZE=3D2>And then there are the other 16 co-authors of LMP-WDM =
who haven't posted</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>(perhaps because they don't think they have any new =
points to add). </FONT>
</P>

<P><FONT SIZE=3D2>Andre </FONT>
</P>

<P><FONT SIZE=3D2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: =
</FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;I have been following this thread with great =
interest. I agree with </FONT>
<BR><FONT SIZE=3D2>your </FONT>
<BR><FONT SIZE=3D2>&gt;conclusion that we should pick one protocol and =
move forward. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;You are talking about WG reaching a consensus. I =
cannot see how this is</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;possible given the two very different views I see =
in the latest email </FONT>
<BR><FONT SIZE=3D2>&gt;exchanges. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;How can we resolve the current dispute? What =
forum should we use to </FONT>
<BR><FONT SIZE=3D2>make </FONT>
<BR><FONT SIZE=3D2>&gt;a final decision on this? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Martin </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt;From: Kireeti Kompella [ <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT=
>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;&n=
bsp; </FONT>
<BR><FONT SIZE=3D2>&lt; <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A> =
&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt; =
&gt; ] </FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM </FONT>
<BR><FONT SIZE=3D2>&gt;To: [email-masked]; =
[email-masked]; </FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [email-masked]; [email-masked]; =
</FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: Optical Link Interface </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Hi Osama, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Even though I don't think reviving CR-LDP =
and RSVP-TE history will </FONT>
<BR><FONT SIZE=3D2>get </FONT>
<BR><FONT SIZE=3D2>&gt;us </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; anywhere </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&quot;Those who forget (ignore) history are =
doomed to repeat it.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Yes, it makes for painful recollections.&nbsp; =
We're living with the </FONT>
<BR><FONT SIZE=3D2>&gt;consequences now, though, and I don't want to =
again. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the existence of two protocols here have =
proven to be useful. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;That's not what I'm hearing, either from =
customers, or from the </FONT>
<BR><FONT SIZE=3D2>&gt;WG (admittedly, the sample is small). </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Listen carefully: I don't want LMP-WDM and NTIP =
moving forward. </FONT>
<BR><FONT SIZE=3D2>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is =
what the WG </FONT>
<BR><FONT SIZE=3D2>&gt;consensus is.&nbsp; LMP-WDM and LMP works too. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;So: you've got the WG chairs (scarred and =
grumpy), the ADs </FONT>
<BR><FONT SIZE=3D2>&gt;and TA (speak up if I'm misrepresenting you), =
and customers </FONT>
<BR><FONT SIZE=3D2>&gt;saying, Pick one protocol and move forward.&nbsp;=
 Let's do that. </FONT>
<BR><FONT SIZE=3D2>&gt;And, please, as Vijay says, let's resolve this =
already. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C119FF.D90605D0--

Delivery-date: Tue, 31 Jul 2001 12:30:01 -0700
Date: Tue, 31 Jul 2001 15:29:28 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Drafts update

I seemed to have missed a document:

 4. draft-many-ccamp-gmpls-framework-00.txt - YES

Zhi-Wei Lin wrote:
> 
> Hi Kireeti,
> 
> > 1. draft-dubuc-lmp-mib-02.txt [yes]
> > 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes]
> > 3. draft-kompella-ospf-gmpls-extensions-02.txt [not sure]
> > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes]
> > 6. draft-many-ccamp-gmpls-routing-00.txt [yes]

Delivery-date: Tue, 31 Jul 2001 12:00:24 -0700
From: Jonathan Lang <[email-masked]>
To: 'Vasant Sahay ' <[email-masked]>, "'Mannie, Eric '" <[email-masked]>, 'Bilel Jamoussi ' <[email-masked]>,  '''Andre Fredette' ' ' <[email-masked]>,  "[email-masked]' ' '" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Tue, 31 Jul 2001 11:55:00 -0700

Vasant,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Vasant Sahay
To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' ';
[email-masked]' '
Sent: 7/30/2001 4:34 PM
Subject: RE: Optical Link Interface

>>>>>>>>From my point of view, I don't see any reason to replace a
protocol by 
>>>>>>>>another one if they have the same functionalities. 

>The misconception here is that they have the same functionalities and
>that LMP definition is complete. I believe there is a lot of discussion
>and thought that needs to go into LMP if used as basis for OLI. WDM-LMP
>being based on LMP will also suffer that thrash.
[Jonathan]...and NTIP is complete and will not suffer any thrashing?

>Let us start with reliable transport(or lack thereof). 
>How are failures conveyed reliably from WDM to OXC ? 
>
>LMP defines ACK messages, however I couldnt find any reference to how
>they should be used to recover lost messages.
[Jonathan]Failures notification is idempotent.  LMP is optimized to
react to alarms rapidly and doesn't require stop-and-wait procedures.
Alarms are treated as independent events.  Eash alarm is transmitted until
acknowledged (see Section 6).  If an alarm status changes, prior to
receiving the Ack, the new status is simply transmitted.
For a procedural reference, LMP works very much like that of RSVP-TE
message Ids in RFC2961.

>WDM-LMP draft specifies that an ACK should be sent for each
>channelStatus message. This level of definition is far from complete.
>
>So the question is if a few hundred failures were reported, what is the
>nature of this ACK scheme for recovering lost messages ? Are we going
to
>recommend a stop and wait protocol or a sliding window protocol ? (A
>stop and wait scheme is easy to implement but slow at recovering
>messages ) Or is the recovery scheme beyond the scope of the protocol ?
[Jonathan]Currently, a window size is intentionally not specified.  We
can add a recommendation in terms of message transmission and processing if
that is helpful.

>If a sliding window is chosen, the implementor will develop code to
>reinvent what TCP does and will have to go through a maturing cycle for
>his  sliding window scheme. There will also be implementation issues
>with managing real time OS timers at application level.
[Jonathan]We certainly don't want to reinvent TCP.  We don't need such a
heavy-weight protocol for this interface.  What we need is a reliable
lightweight messaging protocol that can react to failures rapidly.

>Keep in mind the WDM vendors are not in the business of developing
>transmission protocols for reliablity.They need a solution that can be
>easily added to their existing systems, many of which are legacy
>systems.
>  
>In contrast NTIP has thought through these issues and uses TCP as the
>reliable transport. 
>
>
>To start with that is one fundamental difference in the transport of
>NTIP vs LMP or WDM-LMP 
>
>I am concerned about such open items in LMP which will come to haunt
OLI
>later. 
>
>Vasant 

-----Original Message----- 
From: Mannie, Eric [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, July 30, 2001 3:21 PM 
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' '; 
[email-masked]' ' 
Subject: RE: Optical Link Interface 

Dear all, 

>1. The stats are not that significant, since there was no "last call" 
period announced in advance to gauge community interest. 

Well, at least it shows some preferences for a specification based on an

existing protocol on which the IETF is working since a while and that
was 
accepted as a WG document. 

>From my point of view, I don't see any reason to replace a protocol by 
another one if they have the same functionalities. 

So, 

LMP-WDM:  8  +  1 = 9. 

Kind regards, 

Eric 

Eric Mannie 
EBONE 

-----Original Message----- 
From: Bilel Jamoussi 
To: 'Andre Fredette'; [email-masked]' 
Sent: 7/30/01 5:14 PM 
Subject: RE: Optical Link Interface 

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" 
period announced in advance to gauge community interest. 

2. I do not think IETF uses company affiliation when measuring 
consensus. If it did, then the fact that 3 from Nortel are supporting 
NTIP, is an indication that there is an immediate need for NTIP given 
Nortel is a key player in this space. 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, 
or a merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, 
hence WDM-LMP is a natural extension. The issues here are: 

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) 
are more urgent than LMP 
(b) there is significant baggage to be carried from LMP down to the 
WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The 
issue: 

- this model doesn't reflect the reality that OXC and WDM are two 
different devices - the OXC-WDM relationship is client-server one. 

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
- adopt a client-server model 
- allow for TCP as the transport 
- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with 
your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to 
make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will 
get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

Delivery-date: Tue, 31 Jul 2001 08:39:35 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Drafts update
Date: Tue, 31 Jul 2001 11:37:53 -0400

All:

  I didn't understand why there is lot of confusion 
  in TE drafts. To sum up...

  OSPF TE Draft is not part of any WG
     draft-katz-yeung-ospf-traffic-04.txt

  ISIS TE Draft is part of ISIS WG
     draft-ietf-isis-traffic-03.txt

  OSPF Diff TE Drafts are going in TE-WG
     draft-ietf-ospf-diff-te-00.txt
     draft-ietf-isis-diff-te-00.txt
  
  OSPF GMPLS are in CCAMP WG
     draft-kompella-ospf-gmpls-extensions-02.txt

  ISIS GMPLS are in ISIS WG
     draft-ietf-isis-gmpls-extensions-03.txt

  I strongly suggest/request, all extensions related to OSPF 
  and ISIS should go to respective (OSPF/ISIS) WGs.
  Because the extensions (TLVs etc) are closely related
  to the protocols (irrespective of the features - TE, 
  Diffserv, GMPLS etc)

--Venkata Naidu

-> presumably because draft-ietf-isis-gmpls-extensions-03.txt (note 03, 
-> not 02) is already an ISIS WG document.
-> 
-> -----Original Message-----
-> From: rpapneja [mailto:[email-masked]]
-> Sent: Tuesday, July 31, 2001 9:52 AM
-> To: kireeti
-> Cc: rpapneja; ccamp
-> Subject: RE: Drafts update
-> 
-> 
-> Hello Kireeti
->  
->  A correction-
-> 
->  I meant to say why 
-> "draft-ietf-isis-gmpls-extensions-02.txt" did not 
-> make
-> it to the list instead of "draft-ietf-isis-traffic-02.txt".
-> 
->  -Rajiv
-> 
-> On Tue, 31 Jul 2001, Rajiv Papneja wrote:
-> 
-> > Hello Kireeti,
-> > 
-> >  Here is my opinion on the list of proposed drafts:
-> >  
-> >  1. draft-dubuc-lmp-mib-02.txt:				
->         {Yes}
-> > 			           (CCAMP WG documnet)	
-> >  2. draft-fontana-ccamp-gmpls-g709-00.txt:  		
-> 	{Wait}
-> >  3. draft-kompella-ospf-gmpls-extensions-02.txt: 		{Yes}
-> >  4. draft-many-ccamp-gmpls-framework-00.txt - Yes:		{Yes}
-> >  5. 
-> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt:   {Wait}
-> >  6. draft-many-ccamp-gmpls-routing-00.txt:			{Yes}
-> > 
-> >  I was just wondering that why 
-> (draft-ietf-isis-traffic-02.txt) did 
-> not
-> > make it to the list. Thanks.
-> >  
-> >   Regards,
-> >    -Rajiv
-> > 
-> > ********************************
-> > Rajiv Papneja (GRA)
-> > Advanced Internet Laboratory
-> > George Mason University,
-> > G10, Johnson Center,
-> > Fairfax, VA 22030-4444
-> > Tel: 703.993.4703
-> > email: [email-masked]
-> > ********************************
-> > 
-> > 
-> > > -----Original Message-----
-> > > From: [email-masked] 
[mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Saturday, July 28, 2001 5:37 AM
> > To: [email-masked]
> > Subject: Drafts update
> > 
> > 
> > Hi Folks,
> > 
> > Can we get a sense of the consensus whether the following drafts
> > should be made CCAMP WG documents?  Please respond with
> > (a) yes
> > (b) no
> > (c) wait
> > 
> > 1. draft-dubuc-lmp-mib-02.txt
> > 2. draft-fontana-ccamp-gmpls-g709-00.txt
> > 3. draft-kompella-ospf-gmpls-extensions-02.txt
> > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > 6. draft-many-ccamp-gmpls-routing-00.txt
> > 
> > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
> >  be a WG document, either in MPLS or CCAMP.)
> > 
> > Thanks,
> > Kireeti.
> > 
> > 
> 
> 
> 
> 
> 
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

Delivery-date: Tue, 31 Jul 2001 08:07:51 -0700
From: [email-masked]
Date: Tue, 31 Jul 2001 10:03:12 -0500
Subject: RE: Drafts update
TO: [email-masked], [email-masked]
CC: [email-masked]

presumably because draft-ietf-isis-gmpls-extensions-03.txt (note 03, 
not 02) is already an ISIS WG document.

-----Original Message-----
From: rpapneja [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 9:52 AM
To: kireeti
Cc: rpapneja; ccamp
Subject: RE: Drafts update

Hello Kireeti
 
 A correction-

 I meant to say why "draft-ietf-isis-gmpls-extensions-02.txt" did not 
make
it to the list instead of "draft-ietf-isis-traffic-02.txt".

 -Rajiv

On Tue, 31 Jul 2001, Rajiv Papneja wrote:

> Hello Kireeti,
> 
>  Here is my opinion on the list of proposed drafts:
>  
>  1. draft-dubuc-lmp-mib-02.txt:				        {Yes}
> 			           (CCAMP WG documnet)	
>  2. draft-fontana-ccamp-gmpls-g709-00.txt:  			{Wait}
>  3. draft-kompella-ospf-gmpls-extensions-02.txt: 		{Yes}
>  4. draft-many-ccamp-gmpls-framework-00.txt - Yes:		{Yes}
>  5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt:   {Wait}
>  6. draft-many-ccamp-gmpls-routing-00.txt:			{Yes}
> 
>  I was just wondering that why (draft-ietf-isis-traffic-02.txt) did 
not
> make it to the list. Thanks.
>  
>   Regards,
>    -Rajiv
> 
> ********************************
> Rajiv Papneja (GRA)
> Advanced Internet Laboratory
> George Mason University,
> G10, Johnson Center,
> Fairfax, VA 22030-4444
> Tel: 703.993.4703
> email: [email-masked]
> ********************************
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Saturday, July 28, 2001 5:37 AM
> > To: [email-masked]
> > Subject: Drafts update
> > 
> > 
> > Hi Folks,
> > 
> > Can we get a sense of the consensus whether the following drafts
> > should be made CCAMP WG documents?  Please respond with
> > (a) yes
> > (b) no
> > (c) wait
> > 
> > 1. draft-dubuc-lmp-mib-02.txt
> > 2. draft-fontana-ccamp-gmpls-g709-00.txt
> > 3. draft-kompella-ospf-gmpls-extensions-02.txt
> > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > 6. draft-many-ccamp-gmpls-routing-00.txt
> > 
> > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
> >  be a WG document, either in MPLS or CCAMP.)
> > 
> > Thanks,
> > Kireeti.
> > 
> > 
> 
> 
> 
> 
> 
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

Delivery-date: Tue, 31 Jul 2001 08:07:37 -0700
From: John Drake <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Drafts update
Date: Tue, 31 Jul 2001 08:04:14 -0700

Kireeti,

> 1. draft-dubuc-lmp-mib-02.txt [yes]
> 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes] 
> 3. draft-kompella-ospf-gmpls-extensions-02.txt [yes]
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes]
> 6. draft-many-ccamp-gmpls-routing-00.txt [yes]

Delivery-date: Tue, 31 Jul 2001 07:55:17 -0700
Date: Tue, 31 Jul 2001 10:52:00 -0400 (EDT)
From: Rajiv Papneja <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked]
Subject: RE: Drafts update 

Hello Kireeti
 
 A correction-

 I meant to say why "draft-ietf-isis-gmpls-extensions-02.txt" did not make
it to the list instead of "draft-ietf-isis-traffic-02.txt".

 -Rajiv

On Tue, 31 Jul 2001, Rajiv Papneja wrote:

> Hello Kireeti,
> 
>  Here is my opinion on the list of proposed drafts:
>  
>  1. draft-dubuc-lmp-mib-02.txt:				        {Yes}
> 			           (CCAMP WG documnet)	
>  2. draft-fontana-ccamp-gmpls-g709-00.txt:  			{Wait}
>  3. draft-kompella-ospf-gmpls-extensions-02.txt: 		{Yes}
>  4. draft-many-ccamp-gmpls-framework-00.txt - Yes:		{Yes}
>  5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt:   {Wait}
>  6. draft-many-ccamp-gmpls-routing-00.txt:			{Yes}
> 
>  I was just wondering that why (draft-ietf-isis-traffic-02.txt) did not
> make it to the list. Thanks.
>  
>   Regards,
>    -Rajiv
> 
> ********************************
> Rajiv Papneja (GRA)
> Advanced Internet Laboratory
> George Mason University,
> G10, Johnson Center,
> Fairfax, VA 22030-4444
> Tel: 703.993.4703
> email: [email-masked]
> ********************************
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Saturday, July 28, 2001 5:37 AM
> > To: [email-masked]
> > Subject: Drafts update
> > 
> > 
> > Hi Folks,
> > 
> > Can we get a sense of the consensus whether the following drafts
> > should be made CCAMP WG documents?  Please respond with
> > (a) yes
> > (b) no
> > (c) wait
> > 
> > 1. draft-dubuc-lmp-mib-02.txt
> > 2. draft-fontana-ccamp-gmpls-g709-00.txt
> > 3. draft-kompella-ospf-gmpls-extensions-02.txt
> > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > 6. draft-many-ccamp-gmpls-routing-00.txt
> > 
> > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
> >  be a WG document, either in MPLS or CCAMP.)
> > 
> > Thanks,
> > Kireeti.
> > 
> > 
> 
> 
> 
> 
> 
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

Delivery-date: Tue, 31 Jul 2001 07:11:08 -0700
Date: Tue, 31 Jul 2001 10:07:37 -0400 (EDT)
From: Rajiv Papneja <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked]
Subject: RE: Drafts update 

Hello Kireeti,

 Here is my opinion on the list of proposed drafts:
 
 1. draft-dubuc-lmp-mib-02.txt:				        {Yes}
			           (CCAMP WG documnet)	
 2. draft-fontana-ccamp-gmpls-g709-00.txt:  			{Wait}
 3. draft-kompella-ospf-gmpls-extensions-02.txt: 		{Yes}
 4. draft-many-ccamp-gmpls-framework-00.txt - Yes:		{Yes}
 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt:   {Wait}
 6. draft-many-ccamp-gmpls-routing-00.txt:			{Yes}

 I was just wondering that why (draft-ietf-isis-traffic-02.txt) did not
make it to the list. Thanks.
 
  Regards,
   -Rajiv

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Saturday, July 28, 2001 5:37 AM
> To: [email-masked]
> Subject: Drafts update
> 
> 
> Hi Folks,
> 
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
> 
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
> 
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 31 Jul 2001 05:06:31 -0700
Date: Tue, 31 Jul 2001 08:01:48 -0400
From: Matt Squire <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Drafts update

More votes...

Yes          draft-dubuc-lmp-mib-02.txt
Don't know   draft-fontana-ccamp-gmpls-g709-00.txt 
Yes          draft-kompella-ospf-gmpls-extensions-02.txt 
Yes          draft-many-ccamp-gmpls-framework-00.txt
Don't know   draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt 
Yes          draft-many-ccamp-gmpls-routing-00.txt 

> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Saturday, July 28, 2001 5:37 AM
> > To: [email-masked]
> > Subject: Drafts update
> >
> >
> > Hi Folks,
> >
> > Can we get a sense of the consensus whether the following drafts
> > should be made CCAMP WG documents?  Please respond with
> > (a) yes
> > (b) no
> > (c) wait
> >
> > 1. draft-dubuc-lmp-mib-02.txt
> > 2. draft-fontana-ccamp-gmpls-g709-00.txt
> > 3. draft-kompella-ospf-gmpls-extensions-02.txt
> > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > 6. draft-many-ccamp-gmpls-routing-00.txt
> >
> > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
> >  be a WG document, either in MPLS or CCAMP.)
> >
> > Thanks,
> > Kireeti.
> >
> >

Delivery-date: Mon, 30 Jul 2001 23:34:42 -0700
From: "Hirokazu Ishimatsu" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: Drafts update
Date: Tue, 31 Jul 2001 15:37:18 +0900

Kireeti,

My opinion is :
 
 1. draft-dubuc-lmp-mib-02.txt - Yes
 2. draft-fontana-ccamp-gmpls-g709-00.txt - Yes
 3. draft-kompella-ospf-gmpls-extensions-02.txt - Yes
 4. draft-many-ccamp-gmpls-framework-00.txt - Yes
 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - Wait
 6. draft-many-ccamp-gmpls-routing-00.txt - Yes
 
Best regards,
Hirokazu Ishimatsu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Saturday, July 28, 2001 5:37 AM
> To: [email-masked]
> Subject: Drafts update
> 
> 
> Hi Folks,
> 
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
> 
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
> 
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Mon, 30 Jul 2001 23:06:37 -0700
Date: Tue, 31 Jul 2001 02:05:29 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Drafts update

Hi Kireeti,

> 1. draft-dubuc-lmp-mib-02.txt [yes]
> 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes] 
> 3. draft-kompella-ospf-gmpls-extensions-02.txt [not sure]
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes]
> 6. draft-many-ccamp-gmpls-routing-00.txt [yes]

Delivery-date: Mon, 30 Jul 2001 16:37:21 -0700
From: "Vasant Sahay" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "Bilel Jamoussi" <[email-masked]>, "''Andre Fredette' '" <[email-masked]>, "[email-masked]' '" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Mon, 30 Jul 2001 16:34:19 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11950.27A2E6F0
Content-Type: text/plain;
	charset="iso-8859-1"

>>>>>>>>From my point of view, I don't see any reason to replace a protocol
by
>>>>>>>>another one if they have the same functionalities.

The misconception here is that they have the same functionalities and that
LMP definition is complete. I believe there is a lot of discussion and
thought that needs to go into LMP if used as basis for OLI. WDM-LMP being
based on LMP will also suffer that thrash.

Let us start with reliable transport(or lack thereof). 
How are failures conveyed reliably from WDM to OXC ?

LMP defines ACK messages, however I couldnt find any reference to how they
should be used to recover lost messages.

WDM-LMP draft specifies that an ACK should be sent for each channelStatus
message. This level of definition is far from complete.

So the question is if a few hundred failures were reported, what is the
nature of this ACK scheme for recovering lost messages ? Are we going to
recommend a stop and wait protocol or a sliding window protocol ? (A stop
and wait scheme is easy to implement but slow at recovering messages ) Or is
the recovery scheme  beyond the scope of the protocol ? If a sliding window
is chosen, the implementor will develop code to reinvent what TCP does and
will have to go through a maturing cycle for his  sliding window scheme.
There will also be implementation issues with managing real time OS timers
at application level.
Keep in mind the WDM vendors are not in the business of developing
transmission protocols for reliablity.They need a solution that can be
easily added to their existing systems, many of which are legacy systems.
 
In contrast NTIP has thought through these issues and uses TCP as the
reliable transport.

To start with that is one fundamental difference in the transport of NTIP vs
LMP or WDM-LMP 

I am concerned about such open items in LMP which will come to haunt OLI
later.

Vasant

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, July 30, 2001 3:21 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' ';
[email-masked]' '
Subject: RE: Optical Link Interface

Dear all,

>1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.

Well, at least it shows some preferences for a specification based on an
existing protocol on which the IETF is working since a while and that was
accepted as a WG document.

>From my point of view, I don't see any reason to replace a protocol by
another one if they have the same functionalities.

So,

LMP-WDM:  8  +  1 = 9.

Kind regards,

Eric

Eric Mannie
EBONE

-----Original Message-----
From: Bilel Jamoussi
To: 'Andre Fredette'; [email-masked]'
Sent: 7/30/01 5:14 PM
Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.

2. I do not think IETF uses company affiliation when measuring
consensus. If it did, then the fact that 3 from Nortel are supporting
NTIP, is an indication that there is an immediate need for NTIP given
Nortel is a key player in this space.

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM,
or a merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP,
hence WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP)
are more urgent than LMP 
(b) there is significant baggage to be carried from LMP down to the
WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two
different devices - the OXC-WDM relationship is client-server one.

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
- adopt a client-server model 
- allow for TCP as the transport 
- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with
your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to
make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will
get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

------_=_NextPart_001_01C11950.27A2E6F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;From my point of =
view, I don't see any reason to replace a protocol by</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;another one if they =
have the same functionalities.</FONT>
</P>

<P><FONT SIZE=3D2>The misconception here is that they have the same =
functionalities and that LMP definition is complete. I believe there is =
a lot of discussion and thought that needs to go into LMP if used as =
basis for OLI. WDM-LMP being based on LMP will also suffer that =
thrash.</FONT></P>

<P><FONT SIZE=3D2>Let us start with reliable transport(or lack =
thereof). </FONT>
<BR><FONT SIZE=3D2>How are failures conveyed reliably from WDM to OXC =
?</FONT>
</P>

<P><FONT SIZE=3D2>LMP defines ACK messages, however I couldnt find any =
reference to how they should be used to recover lost messages.</FONT>
</P>

<P><FONT SIZE=3D2>WDM-LMP draft specifies that an ACK should be sent =
for each channelStatus message. This level of definition is far from =
complete.</FONT></P>

<P><FONT SIZE=3D2>So the question is if a few hundred failures were =
reported, what is the nature of this ACK scheme for recovering lost =
messages ? Are we going to recommend a stop and wait protocol or a =
sliding window protocol ? (A stop and wait scheme is easy to implement =
but slow at recovering messages ) Or is the recovery scheme&nbsp; =
beyond the scope of the protocol ? If a sliding window is chosen, the =
implementor will develop code to reinvent what TCP does and will have =
to go through a maturing cycle for his&nbsp; sliding window scheme. =
There will also be implementation issues with managing real time OS =
timers at application level.</FONT></P>

<P><FONT SIZE=3D2>Keep in mind the WDM vendors are not in the business =
of developing transmission protocols for reliablity.They need a =
solution that can be easily added to their existing systems, many of =
which are legacy systems.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>In contrast NTIP has thought through these issues =
and uses TCP as the reliable transport.</FONT>
</P>

<P><FONT SIZE=3D2>To start with that is one fundamental difference in =
the transport of NTIP vs LMP or WDM-LMP </FONT>
</P>

<P><FONT SIZE=3D2>I am concerned about such open items in LMP which =
will come to haunt OLI later.</FONT>
</P>

<P><FONT SIZE=3D2>Vasant</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mannie, Eric [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 30, 2001 3:21 PM</FONT>
<BR><FONT SIZE=3D2>To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre =
Fredette' ';</FONT>
<BR><FONT SIZE=3D2>[email-masked]' '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dear all,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;1. The stats are not that significant, since =
there was no &quot;last call&quot;</FONT>
<BR><FONT SIZE=3D2>period announced in advance to gauge community =
interest.</FONT>
</P>

<P><FONT SIZE=3D2>Well, at least it shows some preferences for a =
specification based on an</FONT>
<BR><FONT SIZE=3D2>existing protocol on which the IETF is working since =
a while and that was</FONT>
<BR><FONT SIZE=3D2>accepted as a WG document.</FONT>
</P>

<P><FONT SIZE=3D2>From my point of view, I don't see any reason to =
replace a protocol by</FONT>
<BR><FONT SIZE=3D2>another one if they have the same =
functionalities.</FONT>
</P>

<P><FONT SIZE=3D2>So,</FONT>
</P>

<P><FONT SIZE=3D2>LMP-WDM:&nbsp; 8&nbsp; +&nbsp; 1 =3D 9.</FONT>
</P>

<P><FONT SIZE=3D2>Kind regards,</FONT>
</P>

<P><FONT SIZE=3D2>Eric</FONT>
</P>

<P><FONT SIZE=3D2>Eric Mannie</FONT>
<BR><FONT SIZE=3D2>EBONE</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bilel Jamoussi</FONT>
<BR><FONT SIZE=3D2>To: 'Andre Fredette'; [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Sent: 7/30/01 5:14 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=3D2>Andre, </FONT>
</P>

<P><FONT SIZE=3D2>2 comments on you statistics, then a proposal to =
progress: </FONT>
</P>

<P><FONT SIZE=3D2>1. The stats are not that significant, since there =
was no &quot;last call&quot;</FONT>
<BR><FONT SIZE=3D2>period announced in advance to gauge community =
interest.</FONT>
</P>

<P><FONT SIZE=3D2>2. I do not think IETF uses company affiliation when =
measuring</FONT>
<BR><FONT SIZE=3D2>consensus. If it did, then the fact that 3 from =
Nortel are supporting</FONT>
<BR><FONT SIZE=3D2>NTIP, is an indication that there is an immediate =
need for NTIP given</FONT>
<BR><FONT SIZE=3D2>Nortel is a key player in this space.</FONT>
</P>

<P><FONT SIZE=3D2>------ </FONT>
</P>

<P><FONT SIZE=3D2>All, </FONT>
</P>

<P><FONT SIZE=3D2>Now to focus the discussion back on the OLI solutions =
(NTIP or LMP-WDM,</FONT>
<BR><FONT SIZE=3D2>or a merged version), </FONT>
</P>

<P><FONT SIZE=3D2>- There is consensus on a single protocol which I =
respect. </FONT>
</P>

<P><FONT SIZE=3D2>- Key distinctions between NTIP and WDM-LMP: </FONT>
</P>

<P><FONT SIZE=3D2>1. WDM-LMP assumes that LMP is a priority, people =
will implement LMP,</FONT>
<BR><FONT SIZE=3D2>hence WDM-LMP is a natural extension. The issues =
here are:</FONT>
</P>

<P><FONT SIZE=3D2>(a) this assumption is not accurate, the functions of =
NTIP (or WDM-LMP)</FONT>
<BR><FONT SIZE=3D2>are more urgent than LMP </FONT>
<BR><FONT SIZE=3D2>(b) there is significant baggage to be carried from =
LMP down to the</FONT>
<BR><FONT SIZE=3D2>WDM-LMP </FONT>
</P>

<P><FONT SIZE=3D2>2. WDM-LMP assumes a peer model between the OXC and =
the WDM system. The</FONT>
<BR><FONT SIZE=3D2>issue: </FONT>
</P>

<P><FONT SIZE=3D2>- this model doesn't reflect the reality that OXC and =
WDM are two</FONT>
<BR><FONT SIZE=3D2>different devices - the OXC-WDM relationship is =
client-server one.</FONT>
</P>

<P><FONT SIZE=3D2>I suggest merging the two proposals as follows: =
</FONT>
</P>

<P><FONT SIZE=3D2>- remove unnecessary LMP baggage </FONT>
<BR><FONT SIZE=3D2>- adopt a client-server model </FONT>
<BR><FONT SIZE=3D2>- allow for TCP as the transport </FONT>
<BR><FONT SIZE=3D2>- clarify a simplified autodiscovery mechanism =
</FONT>
</P>

<P><FONT SIZE=3D2>Bilel. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Andre Fredette [ <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></=
FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&g=
t; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 26, 2001 2:52 PM </FONT>
<BR><FONT SIZE=3D2>To: [email-masked] </FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;From my count on the mailing list we have the =
following results so far:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>LMP-WDM:&nbsp; 8 </FONT>
<BR><FONT SIZE=3D2>NTIP: 3 (All from Nortel) </FONT>
<BR><FONT SIZE=3D2>Agnostic: 1 </FONT>
</P>

<P><FONT SIZE=3D2>And then there are the other 16 co-authors of LMP-WDM =
who haven't posted</FONT>
</P>

<P><FONT SIZE=3D2>(perhaps because they don't think they have any new =
points to add). </FONT>
</P>

<P><FONT SIZE=3D2>Andre </FONT>
</P>

<P><FONT SIZE=3D2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: =
</FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;I have been following this thread with great =
interest. I agree with</FONT>
<BR><FONT SIZE=3D2>your </FONT>
<BR><FONT SIZE=3D2>&gt;conclusion that we should pick one protocol and =
move forward. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;You are talking about WG reaching a consensus. I =
cannot see how this is</FONT>
</P>

<P><FONT SIZE=3D2>&gt;possible given the two very different views I see =
in the latest email </FONT>
<BR><FONT SIZE=3D2>&gt;exchanges. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;How can we resolve the current dispute? What =
forum should we use to</FONT>
<BR><FONT SIZE=3D2>make </FONT>
<BR><FONT SIZE=3D2>&gt;a final decision on this? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Martin </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt;From: Kireeti Kompella [ <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT=
>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt; =
] </FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM </FONT>
<BR><FONT SIZE=3D2>&gt;To: [email-masked]; =
[email-masked]; </FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [email-masked]; [email-masked]; =
</FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: Optical Link Interface </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Hi Osama, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Even though I don't think reviving CR-LDP =
and RSVP-TE history will</FONT>
<BR><FONT SIZE=3D2>get </FONT>
<BR><FONT SIZE=3D2>&gt;us </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; anywhere </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&quot;Those who forget (ignore) history are =
doomed to repeat it.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Yes, it makes for painful recollections.&nbsp; =
We're living with the </FONT>
<BR><FONT SIZE=3D2>&gt;consequences now, though, and I don't want to =
again. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the existence of two protocols here have =
proven to be useful. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;That's not what I'm hearing, either from =
customers, or from the </FONT>
<BR><FONT SIZE=3D2>&gt;WG (admittedly, the sample is small). </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Listen carefully: I don't want LMP-WDM and NTIP =
moving forward. </FONT>
<BR><FONT SIZE=3D2>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is =
what the WG </FONT>
<BR><FONT SIZE=3D2>&gt;consensus is.&nbsp; LMP-WDM and LMP works too. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;So: you've got the WG chairs (scarred and =
grumpy), the ADs </FONT>
<BR><FONT SIZE=3D2>&gt;and TA (speak up if I'm misrepresenting you), =
and customers </FONT>
<BR><FONT SIZE=3D2>&gt;saying, Pick one protocol and move =
forward.&nbsp; Let's do that. </FONT>
<BR><FONT SIZE=3D2>&gt;And, please, as Vijay says, let's resolve this =
already. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C11950.27A2E6F0--

Delivery-date: Mon, 30 Jul 2001 16:06:50 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Jonathan Lang '" <[email-masked]>, Bala Rajagopalan <[email-masked]>, "'''Andre Fredette ' ' '" <[email-masked]>
Cc: "[email-masked]' ' ' '" <[email-masked]>
Subject: RE: Optical Link Interface - LMP-WDM comments
Date: Mon, 30 Jul 2001 19:04:52 -0400

Jonathan & Andre:

My intent was to give a constructive suggestion
on moving forward. Specifically, if the motivation
for NTIP was to do a targetted protocol for OLI,
the same purpose could perhaps be achieved by
streamlining LMP-WDM. So, please look at the technical
issues pointed out and of course, we can discuss these.
Some of my questions in the attachment were for clarification
also. 

With regard to Jonathan's comments:

1. OLI: Yes, I am an author in the OLI requirements. I have 
repeatedly said that OLI is important. Yet, I don't (and didn't)
agree with every requirement in the OLI document. (I'm not
the only author in that document). The way I see it, we
just have the 00 version. Things could change going forward.

2. LMP vs LMP-WDM: I've indicated some particulars about this
in the attachment. I'll look into this further.

3. Link verification: It's a matter of cost vs benefit.  Again,
as I said earlier, this is an area requiring more thought and
refinement.

Regards,

Bala

-----Original Message-----
From: Jonathan Lang
To: Jonathan Lang; ''Bala Rajagopalan ' '; ''Andre Fredette ' '
Cc: [email-masked]' ' '
Sent: 7/30/01 5:37 PM
Subject: RE: Optical Link Interface - LMP-WDM comments

Bala,

[replying to my previous email]

I just realized there was an attachment to your email.  Having gone over
those details, I see you have given specifics to your points (1) and
(4).
Please ignore my comment for (4) - we will work on clarifications here.
I
believe my comments on the other points, other than "What specific
information are you talking about here?" in (1), are still valid.

Thanks,
Jonathan

-----Original Message-----
From: Jonathan Lang
To: 'Bala Rajagopalan '; 'Andre Fredette '
Cc: [email-masked]' '
Sent: 7/30/2001 1:47 PM
Subject: RE: Optical Link Interface - LMP-WDM comments

 Bala,
  Please see inline.

Thanks,
Jonathan 

>-----Original Message-----
>From: Bala Rajagopalan
>To: Andre Fredette
>Cc: [email-masked]'
>Sent: 7/30/2001 7:38 AM
>Subject: Optical Link Interface - LMP-WDM comments
>
>Andre:
>
>I'm attaching specific comments on LMP-WDM. Top level issues are
>as follows:
>
>1. Layer mix-up: In some places, the WDM system is required to
>send information which is not native to OLS to the OXCs. In fact, 
>this is very strange, because this information must originate from
>the OXC domain, get configured in WDM, and then go back to OXCs. This
>is a problem with OLI definition, not LMP-WDM itself. This requires
>some discussion and clean up. 
What specific information are you talking about here?  As you say, this
is
an issue with OLI definition itself and the parameters were discussed at
quite length among both LMP-WDM authors and NTIP authors.  (I do notice
that
you are also listed as an OLI author...).  Certainly we can revisit
these
issues if they need to be addressed...

>2. Rather than tailoring the procedures for the particular requirements
>(OLI), the draft seems to be written with the goal of maximal reuse of
>LMP. This sometimes adds to the complexity of the proposal.  
LMP-WDM was written to satisfy the OLI requirements and reuse the LMP
protocol.  This is similar to the approach taken for GMPLS RSVP-TE and
CR-LDP.

>Specifically, LMP-WDM has many "extensions" to LMP, giving the
impression
>that LMP-WDM is a superset of LMP. I think there are differences in the
>situations where LMP is applied as compared to LMP-WDM and these
aspects
>are not discussed sufficiently. I think a meticulous examination of the
>OLI requirements and LMP procedures is necessary to just carve out a
set 
>of procedures for OLI, rather than the superset approach. The maximal
>"re-use" argument doesn't make any sense on the WDM side where there is
>no LMP. Or, for that matter, where OXCs don't implement LMP. (This is
>where NTIP makes a good point).
Which LMP-WDM procedures are not required for OLI?

>3. I'm afraid the current LMP link verification definition (and as a
>corollary, LMP-WDM link verification) has only a marginal value
>considering the investment on hardware and protocol implementation.
This 
>is an area that requires more work.
If you believe link verification has marginal value, you don't have to
implement it (remember it's optional).  We have heard otherwise from
customers.

>4. Some of the procedures in the draft must be more explicitly
described
>rather than saying that they are same as LMP's.
Please clarify which procedures you are referring to.

>As you noted, a more careful examination of LMP itself is in order.
This is greatly encouraged.

I also think it would be useful for you to do a similar analysis of
NTIP.

Thanks,
Jonathan

>Regards,
>
>Bala
>
>Bala Rajagopalan
>Tellium, Inc.
>2 Crescent Place
>P.O. Box 901
>Oceanport, NJ 07757-0901
>Tel: (732) 923-4237
>Fax: (732) 923-9804
>Email: [email-masked] 

Delivery-date: Mon, 30 Jul 2001 15:25:15 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Bilel Jamoussi ' <[email-masked]>, ''Andre Fredette' ' <[email-masked]>, "[email-masked]' '" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Tue, 31 Jul 2001 00:21:25 +0200

Dear all,

>1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.

Well, at least it shows some preferences for a specification based on an
existing protocol on which the IETF is working since a while and that was
accepted as a WG document.

>From my point of view, I don't see any reason to replace a protocol by
another one if they have the same functionalities.

So,

LMP-WDM:  8  +  1 = 9.

Kind regards,

Eric

Eric Mannie
EBONE

-----Original Message-----
From: Bilel Jamoussi
To: 'Andre Fredette'; [email-masked]'
Sent: 7/30/01 5:14 PM
Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.

2. I do not think IETF uses company affiliation when measuring
consensus. If it did, then the fact that 3 from Nortel are supporting
NTIP, is an indication that there is an immediate need for NTIP given
Nortel is a key player in this space.

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM,
or a merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP,
hence WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP)
are more urgent than LMP 
(b) there is significant baggage to be carried from LMP down to the
WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two
different devices - the OXC-WDM relationship is client-server one.

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
- adopt a client-server model 
- allow for TCP as the transport 
- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with
your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to
make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will
get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

Delivery-date: Mon, 30 Jul 2001 15:15:00 -0700
From: Andre Fredette <[email-masked]>
To: Bala Rajagopalan <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Jul 2001 18:09:58 -0400
Subject: RE: Optical Link Interface - LMP-WDM comments

Bala,

Sorry, but I missed your attachment also.  I'll get back to you on your 
specific issues.

Andre

At 02:37 PM 7/30/2001 -0700, you wrote:
>Bala,
>
>[replying to my previous email]
>
>I just realized there was an attachment to your email.  Having gone over
>those details, I see you have given specifics to your points (1) and (4).
>Please ignore my comment for (4) - we will work on clarifications here.  I
>believe my comments on the other points, other than "What specific
>information are you talking about here?" in (1), are still valid.
>
>Thanks,
>Jonathan
>
>-----Original Message-----
>From: Jonathan Lang
>To: 'Bala Rajagopalan '; 'Andre Fredette '
>Cc: [email-masked]' '
>Sent: 7/30/2001 1:47 PM
>Subject: RE: Optical Link Interface - LMP-WDM comments
>
>  Bala,
>   Please see inline.
>
>Thanks,
>Jonathan
>
> >-----Original Message-----
> >From: Bala Rajagopalan
> >To: Andre Fredette
> >Cc: [email-masked]'
> >Sent: 7/30/2001 7:38 AM
> >Subject: Optical Link Interface - LMP-WDM comments
> >
> >Andre:
> >
> >I'm attaching specific comments on LMP-WDM. Top level issues are
> >as follows:
> >
> >1. Layer mix-up: In some places, the WDM system is required to
> >send information which is not native to OLS to the OXCs. In fact,
> >this is very strange, because this information must originate from
> >the OXC domain, get configured in WDM, and then go back to OXCs. This
> >is a problem with OLI definition, not LMP-WDM itself. This requires
> >some discussion and clean up.
>What specific information are you talking about here?  As you say, this
>is
>an issue with OLI definition itself and the parameters were discussed at
>quite length among both LMP-WDM authors and NTIP authors.  (I do notice
>that
>you are also listed as an OLI author...).  Certainly we can revisit
>these
>issues if they need to be addressed...
>
> >2. Rather than tailoring the procedures for the particular requirements
> >(OLI), the draft seems to be written with the goal of maximal reuse of
> >LMP. This sometimes adds to the complexity of the proposal.
>LMP-WDM was written to satisfy the OLI requirements and reuse the LMP
>protocol.  This is similar to the approach taken for GMPLS RSVP-TE and
>CR-LDP.
>
> >Specifically, LMP-WDM has many "extensions" to LMP, giving the
>impression
> >that LMP-WDM is a superset of LMP. I think there are differences in the
> >situations where LMP is applied as compared to LMP-WDM and these
>aspects
> >are not discussed sufficiently. I think a meticulous examination of the
> >OLI requirements and LMP procedures is necessary to just carve out a
>set
> >of procedures for OLI, rather than the superset approach. The maximal
> >"re-use" argument doesn't make any sense on the WDM side where there is
> >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is
> >where NTIP makes a good point).
>Which LMP-WDM procedures are not required for OLI?
>
> >3. I'm afraid the current LMP link verification definition (and as a
> >corollary, LMP-WDM link verification) has only a marginal value
> >considering the investment on hardware and protocol implementation.
>This
> >is an area that requires more work.
>If you believe link verification has marginal value, you don't have to
>implement it (remember it's optional).  We have heard otherwise from
>customers.
>
> >4. Some of the procedures in the draft must be more explicitly
>described
> >rather than saying that they are same as LMP's.
>Please clarify which procedures you are referring to.
>
> >As you noted, a more careful examination of LMP itself is in order.
>This is greatly encouraged.
>
>I also think it would be useful for you to do a similar analysis of
>NTIP.
>
>Thanks,
>Jonathan
>
> >Regards,
> >
> >Bala
> >
> >Bala Rajagopalan
> >Tellium, Inc.
> >2 Crescent Place
> >P.O. Box 901
> >Oceanport, NJ 07757-0901
> >Tel: (732) 923-4237
> >Fax: (732) 923-9804
> >Email: [email-masked]

Delivery-date: Mon, 30 Jul 2001 15:06:40 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Yangguang Xu ' <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Drafts update
Date: Tue, 31 Jul 2001 00:04:12 +0200

Dear All,

>5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure

I hope at least that all the people that claimed that virtual concatenation
is THE solution will enjoy and support this work since it is only intended
to maximize the use of virtual concatenation in a network using GMPLS
signaling. I am also claiming that virtual concatenation is THE solution in
this draft.

It does NOT define ANY concatenation type.

It just tries to find an ITU-T converter between standard contiguous
concatenation and standard virtual concatenation as close as possible to the
source.

At least this time I am only referring to ITU-T standards :-) So don't blame
me :-)

Kind regards,

Eric

-----Original Message-----
From: Yangguang Xu
To: [email-masked]
Cc: [email-masked]
Sent: 7/30/01 7:04 PM
Subject: Re: Drafts update

Kireeti,

My "votes" :
 
 1. draft-dubuc-lmp-mib-02.txt - YES
 2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure
 3. draft-kompella-ospf-gmpls-extensions-02.txt - if 6 is in, should
this belong
to OSPF WG?
 4. draft-many-ccamp-gmpls-framework-00.txt - YES
 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure
 6. draft-many-ccamp-gmpls-routing-00.txt - YES
 
Thanks,

Yangguang

> -----Original Message-----
> From: kireeti [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 3:37 PM
> To: ccamp
> Cc: kireeti
> Subject: Drafts update
> 
> Hi Folks,
> 
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
> 
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
> 
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
> 
> Thanks,
> Kireeti.

Delivery-date: Mon, 30 Jul 2001 14:45:38 -0700
From: Jonathan Lang <[email-masked]>
To: Jonathan Lang <[email-masked]>, ''Bala Rajagopalan ' ' <[email-masked]>, ''Andre Fredette ' ' <[email-masked]>
Cc: "[email-masked]' ' '" <[email-masked]>
Subject: RE: Optical Link Interface - LMP-WDM comments
Date: Mon, 30 Jul 2001 14:37:20 -0700

Bala,

[replying to my previous email]

I just realized there was an attachment to your email.  Having gone over
those details, I see you have given specifics to your points (1) and (4).
Please ignore my comment for (4) - we will work on clarifications here.  I
believe my comments on the other points, other than "What specific
information are you talking about here?" in (1), are still valid.

Thanks,
Jonathan

-----Original Message-----
From: Jonathan Lang
To: 'Bala Rajagopalan '; 'Andre Fredette '
Cc: [email-masked]' '
Sent: 7/30/2001 1:47 PM
Subject: RE: Optical Link Interface - LMP-WDM comments

 Bala,
  Please see inline.

Thanks,
Jonathan 

>-----Original Message-----
>From: Bala Rajagopalan
>To: Andre Fredette
>Cc: [email-masked]'
>Sent: 7/30/2001 7:38 AM
>Subject: Optical Link Interface - LMP-WDM comments
>
>Andre:
>
>I'm attaching specific comments on LMP-WDM. Top level issues are
>as follows:
>
>1. Layer mix-up: In some places, the WDM system is required to
>send information which is not native to OLS to the OXCs. In fact, 
>this is very strange, because this information must originate from
>the OXC domain, get configured in WDM, and then go back to OXCs. This
>is a problem with OLI definition, not LMP-WDM itself. This requires
>some discussion and clean up. 
What specific information are you talking about here?  As you say, this
is
an issue with OLI definition itself and the parameters were discussed at
quite length among both LMP-WDM authors and NTIP authors.  (I do notice
that
you are also listed as an OLI author...).  Certainly we can revisit
these
issues if they need to be addressed...

>2. Rather than tailoring the procedures for the particular requirements
>(OLI), the draft seems to be written with the goal of maximal reuse of
>LMP. This sometimes adds to the complexity of the proposal.  
LMP-WDM was written to satisfy the OLI requirements and reuse the LMP
protocol.  This is similar to the approach taken for GMPLS RSVP-TE and
CR-LDP.

>Specifically, LMP-WDM has many "extensions" to LMP, giving the
impression
>that LMP-WDM is a superset of LMP. I think there are differences in the
>situations where LMP is applied as compared to LMP-WDM and these
aspects
>are not discussed sufficiently. I think a meticulous examination of the
>OLI requirements and LMP procedures is necessary to just carve out a
set 
>of procedures for OLI, rather than the superset approach. The maximal
>"re-use" argument doesn't make any sense on the WDM side where there is
>no LMP. Or, for that matter, where OXCs don't implement LMP. (This is
>where NTIP makes a good point).
Which LMP-WDM procedures are not required for OLI?

>3. I'm afraid the current LMP link verification definition (and as a
>corollary, LMP-WDM link verification) has only a marginal value
>considering the investment on hardware and protocol implementation.
This 
>is an area that requires more work.
If you believe link verification has marginal value, you don't have to
implement it (remember it's optional).  We have heard otherwise from
customers.

>4. Some of the procedures in the draft must be more explicitly
described
>rather than saying that they are same as LMP's.
Please clarify which procedures you are referring to.

>As you noted, a more careful examination of LMP itself is in order.
This is greatly encouraged.

I also think it would be useful for you to do a similar analysis of
NTIP.

Thanks,
Jonathan

>Regards,
>
>Bala
>
>Bala Rajagopalan
>Tellium, Inc.
>2 Crescent Place
>P.O. Box 901
>Oceanport, NJ 07757-0901
>Tel: (732) 923-4237
>Fax: (732) 923-9804
>Email: [email-masked] 

Delivery-date: Mon, 30 Jul 2001 14:35:11 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Mon, 30 Jul 2001 17:31:01 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1193E.EE2EDD40
Content-Type: text/plain;
	charset="iso-8859-1"

John,

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space.
[John Drake] 

The fact that you perceive yourself to be a key player shouldn't a priori
give your opinion any additional weight 
 
[Jamoussi, Bilel ]  I am speaking of a market reality and stating facts not
perceptions. My point is clear, IETF does not use company affiliations and I
am not advocating more or less weight. 

. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP
[John Drake] 

What is the basis for this assertion?   When we started the LMP-WDM work we
asked you to work on it with us

and you refused, citing lack of need.

[Jamoussi, Bilel ] This is simply not true.  

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one.
[John Drake] 

This is an assertion.  Some of the co-authors of the LMP WDM draft work for
WDM vendors and  they're happy with

the peer relationship between the two devices   

[Jamoussi, Bilel ] This is an assertion ;-)

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far: 

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted 
(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is 
>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

------_=_NextPart_001_01C1193E.EE2EDD40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=180102321-30072001><FONT face=Arial color=#0000ff 
size=2>John,</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2>2. I do not 
  think IETF uses company affiliation when measuring consensus. If it did, then 
  the fact that 3 from Nortel are supporting NTIP, is an indication that there 
  is an immediate need for NTIP given Nortel is a key player in this 
  space.<BR><FONT face=Arial color=#0000ff><SPAN class=393220120-30072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <P><FONT size=2><SPAN class=393220120-30072001><FONT face=Arial 
    color=#0000ff>The fact that you perceive yourself to be a key player 
    shouldn't a priori give your opinion any additional weight&nbsp;<BR><SPAN 
    class=180102321-30072001>&nbsp;</SPAN><BR></FONT></SPAN><SPAN 
    class=180102321-30072001><FONT face=Arial color=#0000ff>[Jamoussi, Bilel 
    ]&nbsp;&nbsp;I am speaking of a market reality and stating facts not 
    perceptions. My point is clear, IETF does not use company affiliations and I 
    am not advocating more or less weight.&nbsp;</FONT></SPAN></FONT></P>
    <P><FONT size=2>. WDM-LMP assumes that LMP is a priority, people will 
    implement LMP, hence WDM-LMP is a natural extension. The issues here 
    are:</FONT></P>
    <P><FONT size=2>(a) this assumption is not accurate, the functions of NTIP 
    (or WDM-LMP) are more urgent than LMP<BR><FONT face=Arial 
    color=#0000ff><SPAN class=393220120-30072001>[John 
    Drake]&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
    class=393220120-30072001>What is the basis for this assertion?&nbsp;&nbsp; 
    When we started the LMP-WDM work we asked you to work on it with 
    us</SPAN></FONT></FONT></P>
    <P><SPAN class=393220120-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
    size=2>and you refused, citing lack of need.<BR><BR><SPAN 
    class=180102321-30072001>[Jamoussi, Bilel ] This is simply not 
    true.&nbsp;&nbsp;</SPAN></FONT></FONT></FONT></SPAN></P>
    <P><FONT size=2>2. WDM-LMP assumes a peer model between the OXC and the WDM 
    system. The issue: </FONT></P>
    <P><FONT size=2>- this model doesn't reflect the reality that OXC and WDM 
    are two different devices - the OXC-WDM relationship is client-server 
    one.<BR><FONT face=Arial color=#0000ff><SPAN class=393220120-30072001>[John 
    Drake]&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
    class=393220120-30072001>This is an assertion.&nbsp; Some of the co-authors 
    of the LMP&nbsp;WDM draft work for WDM vendors and&nbsp; they're happy 
    with</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
    class=393220120-30072001>the peer relationship between the two 
    devices&nbsp;&nbsp;</SPAN></FONT></FONT><FONT size=2><FONT face=Arial 
    color=#0000ff><SPAN 
    class=393220120-30072001>&nbsp;</SPAN></FONT></FONT><BR><FONT size=2><SPAN 
    class=180102321-30072001><FONT face=Arial 
    color=#0000ff></FONT></SPAN></FONT></P>
    <P><FONT size=2><SPAN class=180102321-30072001><FONT face=Arial 
    color=#0000ff>[Jamoussi, Bilel ]&nbsp;This is an assertion 
    ;-)</FONT></SPAN></FONT></P>
    <P><FONT size=2>Bilel.</FONT> </P>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Andre Fredette [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <BR><FONT size=2>Sent: Thursday, July 26, 2001 2:52 PM</FONT> <BR><FONT 
    size=2>To: [email-masked]</FONT> <BR><FONT size=2>Subject: RE: Optical 
    Link Interface</FONT> </P><BR>
    <P><FONT size=2>&nbsp;From my count on the mailing list we have the 
    following results so far:</FONT> </P>
    <P><FONT size=2>LMP-WDM:&nbsp; 8</FONT> <BR><FONT size=2>NTIP: 3 (All from 
    Nortel)</FONT> <BR><FONT size=2>Agnostic: 1</FONT> </P>
    <P><FONT size=2>And then there are the other 16 co-authors of LMP-WDM who 
    haven't posted </FONT><BR><FONT size=2>(perhaps because they don't think 
    they have any new points to add).</FONT> </P>
    <P><FONT size=2>Andre</FONT> </P>
    <P><FONT size=2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</FONT> 
    <BR><FONT size=2>&gt;Kireeti,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;I have been following this thread with great interest. I agree 
    with your</FONT> <BR><FONT size=2>&gt;conclusion that we should pick one 
    protocol and move forward.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;You are talking about WG reaching a consensus. I cannot see how 
    this is</FONT> <BR><FONT size=2>&gt;possible given the two very different 
    views I see in the latest email</FONT> <BR><FONT 
    size=2>&gt;exchanges.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;How can we resolve the current dispute? What forum should we use 
    to make</FONT> <BR><FONT size=2>&gt;a final decision on this?</FONT> 
    <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Martin</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;-----Original Message-----</FONT> 
    <BR><FONT size=2>&gt;From: Kireeti Kompella [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <BR><FONT size=2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> <BR><FONT 
    size=2>&gt;To: [email-masked]; [email-masked];</FONT> 
    <BR><FONT size=2>&gt;[email-masked]</FONT> <BR><FONT 
    size=2>&gt;Cc: [email-masked]; [email-masked];</FONT> <BR><FONT 
    size=2>&gt;[email-masked]</FONT> <BR><FONT size=2>&gt;Subject: 
    RE: Optical Link Interface</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;Hi Osama,</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; Even though I don't think 
    reviving CR-LDP and RSVP-TE history will get</FONT> <BR><FONT 
    size=2>&gt;us</FONT> <BR><FONT size=2>&gt; &gt; anywhere</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;"Those who forget (ignore) history 
    are doomed to repeat it."</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;Yes, it makes for painful recollections.&nbsp; We're living with 
    the</FONT> <BR><FONT size=2>&gt;consequences now, though, and I don't want 
    to again.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; the 
    existence of two protocols here have proven to be useful.</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;That's not what I'm hearing, either 
    from customers, or from the</FONT> <BR><FONT size=2>&gt;WG (admittedly, the 
    sample is small).</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving 
    forward.</FONT> <BR><FONT size=2>&gt;Just NTIP (or NTIP and LMP) is OKAY if 
    that is what the WG</FONT> <BR><FONT size=2>&gt;consensus is.&nbsp; LMP-WDM 
    and LMP works too.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</FONT> 
    <BR><FONT size=2>&gt;and TA (speak up if I'm misrepresenting you), and 
    customers</FONT> <BR><FONT size=2>&gt;saying, Pick one protocol and move 
    forward.&nbsp; Let's do that.</FONT> <BR><FONT size=2>&gt;And, please, as 
    Vijay says, let's resolve this already.</FONT> <BR><FONT size=2>&gt;</FONT> 
    <BR><FONT size=2>&gt;Kireeti.</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1193E.EE2EDD40--

Delivery-date: Mon, 30 Jul 2001 14:22:00 -0700
From: Andre Fredette <[email-masked]>
To: 'Bala Rajagopalan ' <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Jul 2001 17:20:48 -0400
Subject: RE: Optical Link Interface - LMP-WDM comments

This remains the question of the day. (Or is it the past 6 months?)

What in LMP is not required for OLI?

 From my analysis, the only thing I can determine is that the notion of 
bundles is not needed on the OLS.  However, this LMP feature can be treated 
as an arbitrary "administrative grouping" of links which may prove 
useful.  If not, just use a single "bundle" on the OLS and effectively 
ignore this LMP feature.  Given this analysis, I think it is better to 
reuse an existing protocol than create a new one.

I have a number of issues with the content of NTIP, but I don't think it is 
worth debating them because I don't think we should create a new protocol 
to start with.  Furthermore, any of the content issues can be addressed in 
the context of either protocol.

Andre

At 01:47 PM 7/30/2001 -0700, Jonathan Lang wrote:
> >-----Original Message-----
> >From: Bala Rajagopalan
> >2. Rather than tailoring the procedures for the particular requirements
> >(OLI), the draft seems to be written with the goal of maximal reuse of
> >LMP. This sometimes adds to the complexity of the proposal.
>LMP-WDM was written to satisfy the OLI requirements and reuse the LMP
>protocol.  This is similar to the approach taken for GMPLS RSVP-TE and
>CR-LDP.
>
> >Specifically, LMP-WDM has many "extensions" to LMP, giving the impression
> >that LMP-WDM is a superset of LMP. I think there are differences in the
> >situations where LMP is applied as compared to LMP-WDM and these aspects
> >are not discussed sufficiently. I think a meticulous examination of the
> >OLI requirements and LMP procedures is necessary to just carve out a set
> >of procedures for OLI, rather than the superset approach. The maximal
> >"re-use" argument doesn't make any sense on the WDM side where there is
> >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is
> >where NTIP makes a good point).
>Which LMP-WDM procedures are not required for OLI?

Delivery-date: Mon, 30 Jul 2001 13:54:59 -0700
From: Jonathan Lang <[email-masked]>
To: 'Bala Rajagopalan ' <[email-masked]>, 'Andre Fredette ' <[email-masked]>
Cc: "[email-masked]' '" <[email-masked]>
Subject: RE: Optical Link Interface - LMP-WDM comments
Date: Mon, 30 Jul 2001 13:47:59 -0700

 Bala,
  Please see inline.

Thanks,
Jonathan 

>-----Original Message-----
>From: Bala Rajagopalan
>To: Andre Fredette
>Cc: [email-masked]'
>Sent: 7/30/2001 7:38 AM
>Subject: Optical Link Interface - LMP-WDM comments
>
>Andre:
>
>I'm attaching specific comments on LMP-WDM. Top level issues are
>as follows:
>
>1. Layer mix-up: In some places, the WDM system is required to
>send information which is not native to OLS to the OXCs. In fact, 
>this is very strange, because this information must originate from
>the OXC domain, get configured in WDM, and then go back to OXCs. This
>is a problem with OLI definition, not LMP-WDM itself. This requires
>some discussion and clean up. 
What specific information are you talking about here?  As you say, this is
an issue with OLI definition itself and the parameters were discussed at
quite length among both LMP-WDM authors and NTIP authors.  (I do notice that
you are also listed as an OLI author...).  Certainly we can revisit these
issues if they need to be addressed...

>2. Rather than tailoring the procedures for the particular requirements
>(OLI), the draft seems to be written with the goal of maximal reuse of
>LMP. This sometimes adds to the complexity of the proposal.  
LMP-WDM was written to satisfy the OLI requirements and reuse the LMP
protocol.  This is similar to the approach taken for GMPLS RSVP-TE and
CR-LDP.

>Specifically, LMP-WDM has many "extensions" to LMP, giving the impression
>that LMP-WDM is a superset of LMP. I think there are differences in the
>situations where LMP is applied as compared to LMP-WDM and these aspects
>are not discussed sufficiently. I think a meticulous examination of the
>OLI requirements and LMP procedures is necessary to just carve out a set 
>of procedures for OLI, rather than the superset approach. The maximal
>"re-use" argument doesn't make any sense on the WDM side where there is
>no LMP. Or, for that matter, where OXCs don't implement LMP. (This is
>where NTIP makes a good point).
Which LMP-WDM procedures are not required for OLI?

>3. I'm afraid the current LMP link verification definition (and as a
>corollary, LMP-WDM link verification) has only a marginal value
>considering the investment on hardware and protocol implementation. This 
>is an area that requires more work.
If you believe link verification has marginal value, you don't have to
implement it (remember it's optional).  We have heard otherwise from
customers.

>4. Some of the procedures in the draft must be more explicitly described
>rather than saying that they are same as LMP's.
Please clarify which procedures you are referring to.

>As you noted, a more careful examination of LMP itself is in order.
This is greatly encouraged.

I also think it would be useful for you to do a similar analysis of NTIP.

Thanks,
Jonathan

>Regards,
>
>Bala
>
>Bala Rajagopalan
>Tellium, Inc.
>2 Crescent Place
>P.O. Box 901
>Oceanport, NJ 07757-0901
>Tel: (732) 923-4237
>Fax: (732) 923-9804
>Email: [email-masked] 

Delivery-date: Mon, 30 Jul 2001 13:54:53 -0700
From: Andre Fredette <[email-masked]>
To: Bilel Jamoussi <[email-masked]>
Cc: John Drake <[email-masked]>, [email-masked]
Date: Mon, 30 Jul 2001 16:51:03 -0400
Subject: RE: Optical Link Interface

--=====================_26705370==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bilel,

I might not have worded my response exactly as John did (being the nice
guy that I am), but I agree with his answers.

In particular, you continue to talk about "unnecessary LMP baggage", or
"complexity", but cannot describe what it is. 

Andre

At 01:24 PM 7/30/2001 -0700, John Drake wrote:

  

-----Original Message----- 

From: Bilel Jamoussi [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Monday, July 30, 2001 8:14 AM 

To: 'Andre Fredette'; [email-masked]' 

Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest. 

[John Drake] 

This is silly.  Who else would you like to hear from? 

2. I do not think IETF uses company affiliation when measuring
consensus. If it did, then the fact that 3 from Nortel are supporting
NTIP, is an indication that there is an immediate need for NTIP given
Nortel is a key player in this space. 

[John Drake] 

The fact that you perceive yourself to be a key player shouldn't a
priori give your opinion any additional weight 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM,
or a merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP,
hence WDM-LMP is a natural extension. The issues here are: 

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP)
are more urgent than LMP 

[John Drake] 

What is the basis for this assertion?   When we started the LMP-WDM work
we asked you to work on it with us 

and you refused, citing lack of need. 

(b) there is significant baggage to be carried from LMP down to the
WDM-LMP 

[John Drake] 

You've made this assertion inumerable times, and have been asked
inumerable times to enumerate what this 

excess baggage is.  You have yet to do so. 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two
different devices - the OXC-WDM relationship is client-server one. 

[John Drake] 

This is an assertion.  Some of the co-authors of the LMP WDM draft work
for WDM vendors and  they're happy with 

the peer relationship between the two devices   

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 

[John Drake] 

Once again, this would be what? 

- adopt a client-server model 

[John Drake] 

No 

- allow for TCP as the transport 

[John Drake] 

No one but you and your co-authors think that this is either necessary
or desirable 

- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 

From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Thursday, July 26, 2001 2:52 PM 

To: [email-masked] 

Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8 

NTIP: 3 (All from Nortel) 

Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 

>Kireeti, 

> 

>I have been following this thread with great interest. I agree with
your 

>conclusion that we should pick one protocol and move forward. 

> 

>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email 

>exchanges. 

> 

>How can we resolve the current dispute? What forum should we use to
make 

>a final decision on this? 

> 

>Martin 

> 

>-----Original Message----- 

>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 

>Sent: Wednesday, July 25, 2001 9:57 PM 

>To: [email-masked]; [email-masked]; 

>[email-masked] 

>Cc: [email-masked]; [email-masked]; 

>[email-masked] 

>Subject: RE: Optical Link Interface 

> 

> 

>Hi Osama, 

> 

> > Even though I don't think reviving CR-LDP and RSVP-TE history will
get 

>us 

> > anywhere 

> 

>"Those who forget (ignore) history are doomed to repeat it." 

> 

>Yes, it makes for painful recollections.  We're living with the 

>consequences now, though, and I don't want to again. 

> 

> > the existence of two protocols here have proven to be useful. 

> 

>That's not what I'm hearing, either from customers, or from the 

>WG (admittedly, the sample is small). 

> 

>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 

>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 

>consensus is.  LMP-WDM and LMP works too. 

> 

>So: you've got the WG chairs (scarred and grumpy), the ADs 

>and TA (speak up if I'm misrepresenting you), and customers 

>saying, Pick one protocol and move forward.  Let's do that. 

>And, please, as Vijay says, let's resolve this already. 

> 

>Kireeti. 

--=====================_26705370==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Bilel,<br><br>
I might not have worded my response exactly as John did (being the nice
guy that I am), but I agree with his answers.<br><br>
In particular, you continue to talk about &quot;<font size=2>unnecessary
LMP baggage</font>&quot;, or &quot;complexity&quot;, but cannot describe
what it is. <br><br>
Andre<br><br>
At 01:24 PM 7/30/2001 -0700, John Drake wrote:<br>
<blockquote type=cite class=cite cite>&nbsp;
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Bilel Jamoussi
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Monday, July 30, 2001 8:14 AM
<dd>To:</b> 'Andre Fredette'; [email-masked]'
<dd>Subject:</b> RE: Optical Link Interface<br><br>
</font>
<dd>Andre, <font size=2>
<dd>2 comments on you statistics, then a proposal to progress:</font>
<br><br>
<font size=2>
<dd>1. The stats are not that significant, since there was no &quot;last call&quot; period announced in advance to gauge community interest.</font><font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>This is silly.&nbsp; Who else would you like to hear from? </font><font size=2>
<dd>2. I do not think IETF uses company affiliation when measuring consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is an indication that there is an immediate need for NTIP given Nortel is a key player in this space.</font><font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>The fact that you perceive yourself to be a key player shouldn't a priori give your opinion any additional weight </font><font size=2>
<dd>------</font> <br><br>
<font size=2>
<dd>All,</font> <br><br>
<font size=2>
<dd>Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a merged version),</font> <br><br>
<font size=2>
<dd>- There is consensus on a single protocol which I respect.</font> <br><br>
<font size=2>
<dd>- Key distinctions between NTIP and WDM-LMP:</font> <br><br>
<font size=2>
<dd>1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence WDM-LMP is a natural extension. The issues here are:</font><font size=2>
<dd>(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are more urgent than LMP</font><font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>What is the basis for this assertion?&nbsp;&nbsp; When we started the LMP-WDM work we asked you to work on it with us</font><font face="arial" size=2 color="#0000FF">
<dd>and you refused, citing lack of need.</font>
<dd>&nbsp;<font size=2>
<dd>(b) there is significant baggage to be carried from LMP down to the WDM-LMP </font><font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>You've made this assertion inumerable times, and have been asked inumerable times to enumerate what this</font><font face="arial" size=2 color="#0000FF">
<dd>excess baggage is.&nbsp; You have yet to do so. </font><font size=2>
<dd>2. WDM-LMP assumes a peer model between the OXC and the WDM system. The issue: </font><font size=2>
<dd>- this model doesn't reflect the reality that OXC and WDM are two different devices - the OXC-WDM relationship is client-server one.</font><font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>This is an assertion.&nbsp; Some of the co-authors of the LMP WDM draft work for WDM vendors and&nbsp; they're happy with</font><font face="arial" size=2 color="#0000FF">
<dd>the peer relationship between the two devices&nbsp;&nbsp; </font><font size=2>
<dd>I suggest merging the two proposals as follows:</font> <br><br>
<font size=2>
<dd>- remove unnecessary LMP baggage</font> <font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>Once again, this would be what?</font> 
<dd>- adopt a client-server model <font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>No</font> 
<dd>- allow for TCP as the transport <font face="arial" size=2 color="#0000FF">
<dd>[John Drake] </font><font face="arial" size=2 color="#0000FF">
<dd>No one but you and your co-authors think that this is either necessary or desirable</font><font size=2>
<dd>&nbsp;
<dd>- clarify a simplified autodiscovery mechanism</font> <br><br>
<font size=2>
<dd>Bilel.</font> <br><br>
<font size=2>
<dd>-----Original Message-----</font> <font size=2>
<dd>From: Andre Fredette [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font> <font size=2>
<dd>Sent: Thursday, July 26, 2001 2:52 PM</font> <font size=2>
<dd>To: [email-masked]</font> <font size=2>
<dd>Subject: RE: Optical Link Interface</font> <br><br>
<font size=2>
<dd>&nbsp;From my count on the mailing list we have the following results so far:</font> <br><br>
<font size=2>
<dd>LMP-WDM:&nbsp; 8</font> <font size=2>
<dd>NTIP: 3 (All from Nortel)</font> <font size=2>
<dd>Agnostic: 1</font> <br><br>
<font size=2>
<dd>And then there are the other 16 co-authors of LMP-WDM who haven't posted </font><font size=2>
<dd>(perhaps because they don't think they have any new points to add).</font> <br><br>
<font size=2>
<dd>Andre</font> <br><br>
<font size=2>
<dd>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</font> <font size=2>
<dd>&gt;Kireeti,</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;I have been following this thread with great interest. I agree with your</font> <font size=2>
<dd>&gt;conclusion that we should pick one protocol and move forward.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;You are talking about WG reaching a consensus. I cannot see how this is</font> <font size=2>
<dd>&gt;possible given the two very different views I see in the latest email</font> <font size=2>
<dd>&gt;exchanges.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;How can we resolve the current dispute? What forum should we use to make</font> <font size=2>
<dd>&gt;a final decision on this?</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Martin</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;-----Original Message-----</font> <font size=2>
<dd>&gt;From: Kireeti Kompella [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font> <font size=2>
<dd>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</font> <font size=2>
<dd>&gt;To: [email-masked]; [email-masked];</font> <font size=2>
<dd>&gt;[email-masked]</font> <font size=2>
<dd>&gt;Cc: [email-masked]; [email-masked];</font> <font size=2>
<dd>&gt;[email-masked]</font> <font size=2>
<dd>&gt;Subject: RE: Optical Link Interface</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Hi Osama,</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt; &gt; Even though I don't think reviving CR-LDP and RSVP-TE history will get</font> <font size=2>
<dd>&gt;us</font> <font size=2>
<dd>&gt; &gt; anywhere</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;&quot;Those who forget (ignore) history are doomed to repeat it.&quot;</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Yes, it makes for painful recollections.&nbsp; We're living with the</font> <font size=2>
<dd>&gt;consequences now, though, and I don't want to again.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt; &gt; the existence of two protocols here have proven to be useful.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;That's not what I'm hearing, either from customers, or from the</font> <font size=2>
<dd>&gt;WG (admittedly, the sample is small).</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving forward.</font> <font size=2>
<dd>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is what the WG</font> <font size=2>
<dd>&gt;consensus is.&nbsp; LMP-WDM and LMP works too.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</font> <font size=2>
<dd>&gt;and TA (speak up if I'm misrepresenting you), and customers</font> <font size=2>
<dd>&gt;saying, Pick one protocol and move forward.&nbsp; Let's do that.</font> <font size=2>
<dd>&gt;And, please, as Vijay says, let's resolve this already.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Kireeti.</font> 
</dl></blockquote></html>

--=====================_26705370==_.ALT--

Delivery-date: Mon, 30 Jul 2001 13:51:14 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-00.txt
Date: Mon, 30 Jul 2001 09:59:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol (LMP)
	Author(s)	: J. Lang et al.
	Filename	: draft-ietf-ccamp-lmp-00.txt
	Pages		: 57
	Date		: 27-Jul-01
	
Future networks will consist of photonic switches, optical 
crossconnects, and routers that may be configured with control 
channels, links, and bundled links.  This draft specifies a link 
management protocol (LMP) that runs between neighboring nodes and is 
used to manage traffic engineering (TE) links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lmp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 30 Jul 2001 13:27:12 -0700
From: John Drake <[email-masked]>
To: Bilel Jamoussi <[email-masked]>, 'Andre Fredette' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Mon, 30 Jul 2001 13:24:39 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11935.A86866E0
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; [email-masked]'
Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" period
announced in advance to gauge community interest.
[John Drake] 

This is silly.  Who else would you like to hear from? 

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space.
[John Drake] 

The fact that you perceive yourself to be a key player shouldn't a priori
give your opinion any additional weight 

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a
merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP
[John Drake] 

What is the basis for this assertion?   When we started the LMP-WDM work we
asked you to work on it with us

and you refused, citing lack of need.

(b) there is significant baggage to be carried from LMP down to the WDM-LMP 
[John Drake] 

You've made this assertion inumerable times, and have been asked inumerable
times to enumerate what this

excess baggage is.  You have yet to do so. 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one.
[John Drake] 

This is an assertion.  Some of the co-authors of the LMP WDM draft work for
WDM vendors and  they're happy with

the peer relationship between the two devices   

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
[John Drake] 

Once again, this would be what? 
- adopt a client-server model 
[John Drake] 

No 
- allow for TCP as the transport 
[John Drake] 

No one but you and your co-authors think that this is either necessary or
desirable

- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far: 

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted 
(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is 
>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

------_=_NextPart_001_01C11935.A86866E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 30, 2001 
  8:14 AM<BR><B>To:</B> 'Andre Fredette'; 
  [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></DIV></FONT>
  <P><FONT size=2>Andre, </FONT></P>
  <P><FONT size=2>2 comments on you statistics, then a proposal to 
  progress:</FONT> </P>
  <P><FONT size=2>1. The stats are not that significant, since there was no 
  "last call" period announced in advance to gauge community interest.<BR><FONT 
  color=#0000ff face=Arial><SPAN class=393220120-30072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>This is silly.&nbsp; Who else would you like to hear 
  from?&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>2. I do not think IETF uses company affiliation when measuring 
  consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is 
  an indication that there is an immediate need for NTIP given Nortel is a key 
  player in this space.<BR><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>[John Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>The fact that you perceive yourself to be a key 
  player shouldn't a priori give your opinion any additional 
  weight&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>------</FONT> </P>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>Now to focus the discussion back on the OLI solutions (NTIP or 
  LMP-WDM, or a merged version),</FONT> </P>
  <P><FONT size=2>- There is consensus on a single protocol which I 
  respect.</FONT> </P>
  <P><FONT size=2>- Key distinctions between NTIP and WDM-LMP:</FONT> </P>
  <P><FONT size=2>1. WDM-LMP assumes that LMP is a priority, people will 
  implement LMP, hence WDM-LMP is a natural extension. The issues here 
  are:</FONT></P>
  <P><FONT size=2>(a) this assumption is not accurate, the functions of NTIP (or 
  WDM-LMP) are more urgent than LMP<BR><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>[John Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>What is the basis for this assertion?&nbsp;&nbsp; 
  When we started the LMP-WDM work we asked you to work on it with 
  us</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>and you refused, citing lack of 
  need.</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001></SPAN></FONT></FONT>&nbsp;<BR><FONT size=2>(b) there 
  is significant baggage to be carried from LMP down to the WDM-LMP <BR><FONT 
  color=#0000ff face=Arial><SPAN class=393220120-30072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>You've made this assertion inumerable times, and have 
  been asked inumerable times to enumerate what</SPAN></FONT></FONT><FONT 
  size=2><FONT color=#0000ff face=Arial><SPAN class=393220120-30072001> 
  this</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>excess baggage is.&nbsp; You have yet to do 
  so.&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>2. WDM-LMP assumes a peer model between the OXC and the WDM 
  system. The issue: </FONT></P>
  <P><FONT size=2>- this model doesn't reflect the reality that OXC and WDM are 
  two different devices - the OXC-WDM relationship is client-server 
  one.<BR><FONT color=#0000ff face=Arial><SPAN class=393220120-30072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>This is an assertion.&nbsp; Some of the co-authors of 
  the LMP&nbsp;WDM draft work for WDM vendors and&nbsp; they're happy 
  with</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=393220120-30072001>the peer relationship between the two 
  devices&nbsp;&nbsp;</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff 
  face=Arial><SPAN class=393220120-30072001>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>I suggest merging the two proposals as follows:</FONT> </P>
  <P><FONT size=2>- remove unnecessary LMP baggage</FONT> <BR><FONT size=2><SPAN 
  class=393220120-30072001><FONT color=#0000ff face=Arial>[John 
  Drake]&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=393220120-30072001><FONT color=#0000ff 
  face=Arial>Once again, this would be what?</FONT>&nbsp;</SPAN><BR>- adopt a 
  client-server model <BR><SPAN class=393220120-30072001><FONT color=#0000ff 
  face=Arial>[John Drake]&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=393220120-30072001><FONT color=#0000ff 
  face=Arial>No</FONT>&nbsp;</SPAN><BR>- allow for TCP as the transport</FONT> 
  <BR><FONT size=2><SPAN class=393220120-30072001><FONT color=#0000ff 
  face=Arial>[John Drake]&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=393220120-30072001><FONT color=#0000ff 
  face=Arial>No one but you and your co-authors think that this is either 
  necessary or desirable</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=393220120-30072001>&nbsp;</SPAN><BR>- clarify a 
  simplified autodiscovery mechanism</FONT> </P>
  <P><FONT size=2>Bilel.</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Andre 
  Fredette [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, July 26, 2001 2:52 PM</FONT> <BR><FONT 
  size=2>To: [email-masked]</FONT> <BR><FONT size=2>Subject: RE: Optical 
  Link Interface</FONT> </P><BR>
  <P><FONT size=2>&nbsp;From my count on the mailing list we have the following 
  results so far:</FONT> </P>
  <P><FONT size=2>LMP-WDM:&nbsp; 8</FONT> <BR><FONT size=2>NTIP: 3 (All from 
  Nortel)</FONT> <BR><FONT size=2>Agnostic: 1</FONT> </P>
  <P><FONT size=2>And then there are the other 16 co-authors of LMP-WDM who 
  haven't posted </FONT><BR><FONT size=2>(perhaps because they don't think they 
  have any new points to add).</FONT> </P>
  <P><FONT size=2>Andre</FONT> </P>
  <P><FONT size=2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</FONT> 
  <BR><FONT size=2>&gt;Kireeti,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;I have been following this thread with great interest. I agree with 
  your</FONT> <BR><FONT size=2>&gt;conclusion that we should pick one protocol 
  and move forward.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;You 
  are talking about WG reaching a consensus. I cannot see how this is</FONT> 
  <BR><FONT size=2>&gt;possible given the two very different views I see in the 
  latest email</FONT> <BR><FONT size=2>&gt;exchanges.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;How can we resolve the current 
  dispute? What forum should we use to make</FONT> <BR><FONT size=2>&gt;a final 
  decision on this?</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Martin</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;-----Original Message-----</FONT> <BR><FONT size=2>&gt;From: 
  Kireeti Kompella [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
  <BR><FONT size=2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> <BR><FONT 
  size=2>&gt;To: [email-masked]; [email-masked];</FONT> 
  <BR><FONT size=2>&gt;[email-masked]</FONT> <BR><FONT size=2>&gt;Cc: 
  [email-masked]; [email-masked];</FONT> <BR><FONT 
  size=2>&gt;[email-masked]</FONT> <BR><FONT size=2>&gt;Subject: RE: 
  Optical Link Interface</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Hi Osama,</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; Even though I don't think 
  reviving CR-LDP and RSVP-TE history will get</FONT> <BR><FONT 
  size=2>&gt;us</FONT> <BR><FONT size=2>&gt; &gt; anywhere</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;"Those who forget (ignore) history are 
  doomed to repeat it."</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Yes, it makes for painful recollections.&nbsp; We're living with 
  the</FONT> <BR><FONT size=2>&gt;consequences now, though, and I don't want to 
  again.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; the 
  existence of two protocols here have proven to be useful.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;That's not what I'm hearing, either 
  from customers, or from the</FONT> <BR><FONT size=2>&gt;WG (admittedly, the 
  sample is small).</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving 
  forward.</FONT> <BR><FONT size=2>&gt;Just NTIP (or NTIP and LMP) is OKAY if 
  that is what the WG</FONT> <BR><FONT size=2>&gt;consensus is.&nbsp; LMP-WDM 
  and LMP works too.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</FONT> 
  <BR><FONT size=2>&gt;and TA (speak up if I'm misrepresenting you), and 
  customers</FONT> <BR><FONT size=2>&gt;saying, Pick one protocol and move 
  forward.&nbsp; Let's do that.</FONT> <BR><FONT size=2>&gt;And, please, as 
  Vijay says, let's resolve this already.</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt;Kireeti.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11935.A86866E0--

Delivery-date: Mon, 30 Jul 2001 11:41:11 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt
Date: Mon, 30 Jul 2001 11:37:34 -0700

Hi All,
         I have following doubt in 
"draft-ietf-mpls-generalized-signalling-05.txt" draft.
This draft has introduced new field switching type in Generalized
Label Request Object. After looking at the structure of switching type
field in latest OSPF document (GMPLS extensions to OSPF, Field Name :
Interface switching capability descriptor), I could not make out why
this is present in per LSP establishment request ? This field
advertises the bandwidth (both min. and max.) for various priority
levels (p = 0 -> 7). Furthermore, this field also contain Encoding
(I assume LSP encoding type) field which is already there in
Generalized Label Reqest object.
I am not able to understand why this type of information is required
in Per Connection Establishment Request ? Is the "switching type" field only 
applicable when FA (forwarding adjacency) need to be established ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Mon, 30 Jul 2001 11:36:51 -0700
Date: Mon, 30 Jul 2001 14:39:19 -0400
From: Guangzhi Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Drafts update

> Kireeti,
>
> My "votes" :
>
>  1. draft-dubuc-lmp-mib-02.txt - YES
>  2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure
>  3. draft-kompella-ospf-gmpls-extensions-02.txt - YES
>  4. draft-many-ccamp-gmpls-framework-00.txt - YES
>  5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure
>  6. draft-many-ccamp-gmpls-routing-00.txt - YES

Could 3 and 6 combine together ?

Thanks,

Guangzhi

Envelope-to: [email-masked]
Delivery-date: Mon, 30 Jul 2001 10:53:14 -0700
Date: Mon, 30 Jul 2001 10:48:13 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP agenda

Hi,

Here's the final agenda.

Thanks,
Kireeti & Vijay.
---------------

Administrivia/Blue Sheets/
Minutes takers			 5 min
Charter	& drafts update		10 min
Update from the Design Teams	10 min

GMPLS update (Lou Berger)	10 min
SONET/SDH (Eric Mannie)		15 min
G709 (Dimitri?)			10 min
GMPLS MIBs			 5 min

Architecture (Eric Mannie)	10 min
Framework (Yangguang Xu)	 5 min
SONET/SDH framework (Greg B.)	 5 min

LMP (Jonathan Lang)		 5 min
LMP MIB	(Martin Dubuc)		 5 min

OLI Reqts (Andre+Osama)		 5 min
NTIP (Osama Aboul-Magd)		10 min
LMP-WDM	(Andre Fredette)	10 min
resolution			 5 min

Tunnel Trace (Ron Bonica)	10 min

RSVP for Mesh (Kalmanek/Li)	 5 min	| subject to time
RSVP for OAPS (Dan Guo)		 5 min	| availability

-------------------------------

CCAMP WG documents

(Joint with MPLS)
draft-ietf-mpls-generalized-cr-ldp-04.txt
draft-ietf-mpls-generalized-rsvp-te-04.txt
draft-ietf-mpls-generalized-signaling-05.txt

draft-ietf-ccamp-gmpls-architecture-00.txt
draft-ietf-ccamp-gmpls-sonet-sdh-01.txt
draft-ietf-ccamp-lmp-00.txt

Under consideration:

1. draft-dubuc-lmp-mib-02.txt
2. draft-fontana-ccamp-gmpls-g709-00.txt
3. draft-kompella-ospf-gmpls-extensions-02.txt
4. draft-many-ccamp-gmpls-framework-00.txt
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
6. draft-many-ccamp-gmpls-routing-00.txt

Delivery-date: Mon, 30 Jul 2001 10:15:32 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "'ccamp'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Mon, 30 Jul 2001 13:08:53 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1191A.4F920BE0
Content-Type: text/plain;
	charset="iso-8859-1"

Martin, 
 
Please see inline:

Bilel,
 
I don't see evidence that there is more than one vendor implementing NTIP. 
[Jamoussi, Bilel ] so what? why is this relevant at this point?
 
I don't see any reasons to standardize it at this point. 
[Jamoussi, Bilel ] both NTIP and WDM-LMP??? what about the OLI requirements?
are you proposing we ignore them?
 
On the other hand, I have seen support for LMP-WDM from several vendors in
the past few days.
[Jamoussi, Bilel ] vendors of what?
 
Martin

[Jamoussi, Bilel ] Do you have any comments on my proposal to progress the
work? 
Bilel.

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Monday, July 30, 2001 11:14 AM
To: 'Andre Fredette'; [email-masked]'
Subject: RE: Optical Link Interface

Andre, 

2 comments on you statistics, then a proposal to progress: 

1. The stats are not that significant, since there was no "last call" period
announced in advance to gauge community interest.

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space.

------ 

All, 

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a
merged version), 

- There is consensus on a single protocol which I respect. 

- Key distinctions between NTIP and WDM-LMP: 

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP 
(b) there is significant baggage to be carried from LMP down to the WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one.

I suggest merging the two proposals as follows: 

- remove unnecessary LMP baggage 
- adopt a client-server model 
- allow for TCP as the transport 
- clarify a simplified autodiscovery mechanism 

Bilel. 

-----Original Message----- 
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 26, 2001 2:52 PM 
To: [email-masked] 
Subject: RE: Optical Link Interface 

 From my count on the mailing list we have the following results so far: 

LMP-WDM:  8 
NTIP: 3 (All from Nortel) 
Agnostic: 1 

And then there are the other 16 co-authors of LMP-WDM who haven't posted 
(perhaps because they don't think they have any new points to add). 

Andre 

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote: 
>Kireeti, 
> 
>I have been following this thread with great interest. I agree with your 
>conclusion that we should pick one protocol and move forward. 
> 
>You are talking about WG reaching a consensus. I cannot see how this is 
>possible given the two very different views I see in the latest email 
>exchanges. 
> 
>How can we resolve the current dispute? What forum should we use to make 
>a final decision on this? 
> 
>Martin 
> 
>-----Original Message----- 
>From: Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 9:57 PM 
>To: [email-masked]; [email-masked]; 
>[email-masked] 
>Cc: [email-masked]; [email-masked]; 
>[email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Hi Osama, 
> 
> > Even though I don't think reviving CR-LDP and RSVP-TE history will get 
>us 
> > anywhere 
> 
>"Those who forget (ignore) history are doomed to repeat it." 
> 
>Yes, it makes for painful recollections.  We're living with the 
>consequences now, though, and I don't want to again. 
> 
> > the existence of two protocols here have proven to be useful. 
> 
>That's not what I'm hearing, either from customers, or from the 
>WG (admittedly, the sample is small). 
> 
>Listen carefully: I don't want LMP-WDM and NTIP moving forward. 
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG 
>consensus is.  LMP-WDM and LMP works too. 
> 
>So: you've got the WG chairs (scarred and grumpy), the ADs 
>and TA (speak up if I'm misrepresenting you), and customers 
>saying, Pick one protocol and move forward.  Let's do that. 
>And, please, as Vijay says, let's resolve this already. 
> 
>Kireeti. 

------_=_NextPart_001_01C1191A.4F920BE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=950380117-30072001><FONT face=Arial color=#0000ff 
size=2>Martin, </FONT></SPAN></DIV>
<DIV><SPAN class=950380117-30072001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=950380117-30072001><FONT face=Arial color=#0000ff size=2>Please 
see inline:</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
  class=703290016-30072001><FONT face=Arial color=#0000ff 
  size=2>Bilel,</FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>I don't see evidence that there is&nbsp;more than one vendor 
  implementing&nbsp;NTIP. <BR><SPAN class=950380117-30072001>[Jamoussi, Bilel ] 
  so what? why is this relevant at this 
  point?</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial color=#0000ff 
  size=2><SPAN class=950380117-30072001></SPAN></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>I don't see any reasons to standardize it at this point. <BR><SPAN 
  class=950380117-30072001>[Jamoussi, Bilel ] both NTIP and WDM-LMP??? what 
  about the OLI requirements? are you proposing we ignore 
  them?</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2><SPAN 
  class=950380117-30072001></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>On the other hand, I have seen&nbsp;support for LMP-WDM from several 
  vendors in the past few days.<BR><SPAN class=950380117-30072001>[Jamoussi, 
  Bilel ] vendors of what?</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2>Martin<BR><SPAN 
  class=950380117-30072001></SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2><SPAN class=950380117-30072001>[Jamoussi, Bilel ]&nbsp;<SPAN 
  class=950380117-30072001>Do you have any comments on my proposal to progress 
  the work?</SPAN>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=703290016-30072001><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2><SPAN 
  class=950380117-30072001>Bilel.</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
    [mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 30, 2001 
    11:14 AM<BR><B>To:</B> 'Andre Fredette'; 
    [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
    Interface<BR><BR></FONT></DIV>
    <P><FONT size=2>Andre, </FONT></P>
    <P><FONT size=2>2 comments on you statistics, then a proposal to 
    progress:</FONT> </P>
    <P><FONT size=2>1. The stats are not that significant, since there was no 
    "last call" period announced in advance to gauge community 
    interest.</FONT></P>
    <P><FONT size=2>2. I do not think IETF uses company affiliation when 
    measuring consensus. If it did, then the fact that 3 from Nortel are 
    supporting NTIP, is an indication that there is an immediate need for NTIP 
    given Nortel is a key player in this space.</FONT></P>
    <P><FONT size=2>------</FONT> </P>
    <P><FONT size=2>All,</FONT> </P>
    <P><FONT size=2>Now to focus the discussion back on the OLI solutions (NTIP 
    or LMP-WDM, or a merged version),</FONT> </P>
    <P><FONT size=2>- There is consensus on a single protocol which I 
    respect.</FONT> </P>
    <P><FONT size=2>- Key distinctions between NTIP and WDM-LMP:</FONT> </P>
    <P><FONT size=2>1. WDM-LMP assumes that LMP is a priority, people will 
    implement LMP, hence WDM-LMP is a natural extension. The issues here 
    are:</FONT></P>
    <P><FONT size=2>(a) this assumption is not accurate, the functions of NTIP 
    (or WDM-LMP) are more urgent than LMP</FONT> <BR><FONT size=2>(b) there is 
    significant baggage to be carried from LMP down to the WDM-LMP </FONT></P>
    <P><FONT size=2>2. WDM-LMP assumes a peer model between the OXC and the WDM 
    system. The issue: </FONT></P>
    <P><FONT size=2>- this model doesn't reflect the reality that OXC and WDM 
    are two different devices - the OXC-WDM relationship is client-server 
    one.</FONT></P>
    <P><FONT size=2>I suggest merging the two proposals as follows:</FONT> </P>
    <P><FONT size=2>- remove unnecessary LMP baggage</FONT> <BR><FONT size=2>- 
    adopt a client-server model </FONT><BR><FONT size=2>- allow for TCP as the 
    transport</FONT> <BR><FONT size=2>- clarify a simplified autodiscovery 
    mechanism</FONT> </P>
    <P><FONT size=2>Bilel.</FONT> </P>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Andre Fredette [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <BR><FONT size=2>Sent: Thursday, July 26, 2001 2:52 PM</FONT> <BR><FONT 
    size=2>To: [email-masked]</FONT> <BR><FONT size=2>Subject: RE: Optical 
    Link Interface</FONT> </P><BR>
    <P><FONT size=2>&nbsp;From my count on the mailing list we have the 
    following results so far:</FONT> </P>
    <P><FONT size=2>LMP-WDM:&nbsp; 8</FONT> <BR><FONT size=2>NTIP: 3 (All from 
    Nortel)</FONT> <BR><FONT size=2>Agnostic: 1</FONT> </P>
    <P><FONT size=2>And then there are the other 16 co-authors of LMP-WDM who 
    haven't posted </FONT><BR><FONT size=2>(perhaps because they don't think 
    they have any new points to add).</FONT> </P>
    <P><FONT size=2>Andre</FONT> </P>
    <P><FONT size=2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:</FONT> 
    <BR><FONT size=2>&gt;Kireeti,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;I have been following this thread with great interest. I agree 
    with your</FONT> <BR><FONT size=2>&gt;conclusion that we should pick one 
    protocol and move forward.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;You are talking about WG reaching a consensus. I cannot see how 
    this is</FONT> <BR><FONT size=2>&gt;possible given the two very different 
    views I see in the latest email</FONT> <BR><FONT 
    size=2>&gt;exchanges.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;How can we resolve the current dispute? What forum should we use 
    to make</FONT> <BR><FONT size=2>&gt;a final decision on this?</FONT> 
    <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Martin</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;-----Original Message-----</FONT> 
    <BR><FONT size=2>&gt;From: Kireeti Kompella [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <BR><FONT size=2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> <BR><FONT 
    size=2>&gt;To: [email-masked]; [email-masked];</FONT> 
    <BR><FONT size=2>&gt;[email-masked]</FONT> <BR><FONT 
    size=2>&gt;Cc: [email-masked]; [email-masked];</FONT> <BR><FONT 
    size=2>&gt;[email-masked]</FONT> <BR><FONT size=2>&gt;Subject: 
    RE: Optical Link Interface</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;Hi Osama,</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; Even though I don't think 
    reviving CR-LDP and RSVP-TE history will get</FONT> <BR><FONT 
    size=2>&gt;us</FONT> <BR><FONT size=2>&gt; &gt; anywhere</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;"Those who forget (ignore) history 
    are doomed to repeat it."</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;Yes, it makes for painful recollections.&nbsp; We're living with 
    the</FONT> <BR><FONT size=2>&gt;consequences now, though, and I don't want 
    to again.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt; &gt; the 
    existence of two protocols here have proven to be useful.</FONT> <BR><FONT 
    size=2>&gt;</FONT> <BR><FONT size=2>&gt;That's not what I'm hearing, either 
    from customers, or from the</FONT> <BR><FONT size=2>&gt;WG (admittedly, the 
    sample is small).</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving 
    forward.</FONT> <BR><FONT size=2>&gt;Just NTIP (or NTIP and LMP) is OKAY if 
    that is what the WG</FONT> <BR><FONT size=2>&gt;consensus is.&nbsp; LMP-WDM 
    and LMP works too.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
    size=2>&gt;So: you've got the WG chairs (scarred and grumpy), the ADs</FONT> 
    <BR><FONT size=2>&gt;and TA (speak up if I'm misrepresenting you), and 
    customers</FONT> <BR><FONT size=2>&gt;saying, Pick one protocol and move 
    forward.&nbsp; Let's do that.</FONT> <BR><FONT size=2>&gt;And, please, as 
    Vijay says, let's resolve this already.</FONT> <BR><FONT size=2>&gt;</FONT> 
    <BR><FONT size=2>&gt;Kireeti.</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1191A.4F920BE0--

Delivery-date: Mon, 30 Jul 2001 10:05:28 -0700
Date: Mon, 30 Jul 2001 13:04:30 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: Drafts update

Kireeti,

My "votes" :
 
 1. draft-dubuc-lmp-mib-02.txt - YES
 2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure
 3. draft-kompella-ospf-gmpls-extensions-02.txt - if 6 is in, should this belong
to OSPF WG?
 4. draft-many-ccamp-gmpls-framework-00.txt - YES
 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure
 6. draft-many-ccamp-gmpls-routing-00.txt - YES
 
Thanks,

Yangguang

> -----Original Message-----
> From: kireeti [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 3:37 PM
> To: ccamp
> Cc: kireeti
> Subject: Drafts update
> 
> Hi Folks,
> 
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
> 
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
> 
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
> 
> Thanks,
> Kireeti.

Envelope-to: [email-masked]
Delivery-date: Mon, 30 Jul 2001 09:08:39 -0700
Date: Mon, 30 Jul 2001 09:06:05 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Drafts update
Cc: [email-masked]

Hi Yangguang,

> May I ask why draft-xu-bgp-gmpls-01.txt is not in the list?

You certainly may.

It is not in CCAMP's scope/charter.  We'll have a discussion on the
charter at this IETF, but a) a discussion doesn't mean that everything
discussed gets on the charter; b) even if on the charter, it's way too
early to even begin deliberations on whether this should be a WG doc.

Kireeti.

Delivery-date: Mon, 30 Jul 2001 09:08:33 -0700
content-class: urn:content-classes:message
Subject: RE: Optical Link Interface
Date:  Mon, 30 Jul 2001 12:06:25 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Bilel Jamoussi" <[email-masked]>, "Andre Fredette" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C11911.952C0287
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bilel,
=20
I don't see evidence that there is more than one vendor implementing
NTIP. I don't see any reasons to standardize it at this point. On the
other hand, I have seen support for LMP-WDM from several vendors in the
past few days.
=20
Martin

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Monday, July 30, 2001 11:14 AM
To: 'Andre Fredette'; [email-masked]'
Subject: RE: Optical Link Interface

Andre,=20

2 comments on you statistics, then a proposal to progress:=20

1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.

2. I do not think IETF uses company affiliation when measuring
consensus. If it did, then the fact that 3 from Nortel are supporting
NTIP, is an indication that there is an immediate need for NTIP given
Nortel is a key player in this space.

------=20

All,=20

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM,
or a merged version),=20

- There is consensus on a single protocol which I respect.=20

- Key distinctions between NTIP and WDM-LMP:=20

1. WDM-LMP assumes that LMP is a priority, people will implement LMP,
hence WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP)
are more urgent than LMP=20
(b) there is significant baggage to be carried from LMP down to the
WDM-LMP=20

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue:=20

- this model doesn't reflect the reality that OXC and WDM are two
different devices - the OXC-WDM relationship is client-server one.

I suggest merging the two proposals as follows:=20

- remove unnecessary LMP baggage=20
- adopt a client-server model=20
- allow for TCP as the transport=20
- clarify a simplified autodiscovery mechanism=20

Bilel.=20

-----Original Message-----=20
From: Andre Fredette [ mailto:[email-masked]]=20
Sent: Thursday, July 26, 2001 2:52 PM=20
To: [email-masked]=20
Subject: RE: Optical Link Interface=20

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8=20
NTIP: 3 (All from Nortel)=20
Agnostic: 1=20

And then there are the other 16 co-authors of LMP-WDM who haven't posted

(perhaps because they don't think they have any new points to add).=20

Andre=20

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:=20
>Kireeti,=20
>=20
>I have been following this thread with great interest. I agree with
your=20
>conclusion that we should pick one protocol and move forward.=20
>=20
>You are talking about WG reaching a consensus. I cannot see how this is

>possible given the two very different views I see in the latest email=20
>exchanges.=20
>=20
>How can we resolve the current dispute? What forum should we use to
make=20
>a final decision on this?=20
>=20
>Martin=20
>=20
>-----Original Message-----=20
>From: Kireeti Kompella [ mailto:[email-masked]]=20
>Sent: Wednesday, July 25, 2001 9:57 PM=20
>To: [email-masked]; [email-masked];=20
>[email-masked]=20
>Cc: [email-masked]; [email-masked];=20
>[email-masked]=20
>Subject: RE: Optical Link Interface=20
>=20
>=20
>Hi Osama,=20
>=20
> > Even though I don't think reviving CR-LDP and RSVP-TE history will
get=20
>us=20
> > anywhere=20
>=20
>"Those who forget (ignore) history are doomed to repeat it."=20
>=20
>Yes, it makes for painful recollections.  We're living with the=20
>consequences now, though, and I don't want to again.=20
>=20
> > the existence of two protocols here have proven to be useful.=20
>=20
>That's not what I'm hearing, either from customers, or from the=20
>WG (admittedly, the sample is small).=20
>=20
>Listen carefully: I don't want LMP-WDM and NTIP moving forward.=20
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG=20
>consensus is.  LMP-WDM and LMP works too.=20
>=20
>So: you've got the WG chairs (scarred and grumpy), the ADs=20
>and TA (speak up if I'm misrepresenting you), and customers=20
>saying, Pick one protocol and move forward.  Let's do that.=20
>And, please, as Vijay says, let's resolve this already.=20
>=20
>Kireeti.=20

------_=_NextPart_001_01C11911.952C0287
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content=3D"MSHTML 5.50.4522.1801" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D703290016-30072001><FONT face=3DArial color=3D#0000ff =

size=3D2>Bilel,</FONT></SPAN></DIV>
<DIV><SPAN class=3D703290016-30072001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D703290016-30072001><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't see evidence that there is&nbsp;more than one vendor=20
implementing&nbsp;NTIP. I don't see any reasons to standardize it at =
this point.=20
On the other hand, I have seen&nbsp;support for LMP-WDM from several =
vendors in=20
the past few days.</FONT></SPAN></DIV>
<DIV><SPAN class=3D703290016-30072001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D703290016-30072001><FONT face=3DArial color=3D#0000ff =

size=3D2>Martin</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 30, =
2001=20
  11:14 AM<BR><B>To:</B> 'Andre Fredette';=20
  [email-masked]'<BR><B>Subject:</B> RE: Optical Link=20
  Interface<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Andre, </FONT></P>
  <P><FONT size=3D2>2 comments on you statistics, then a proposal to=20
  progress:</FONT> </P>
  <P><FONT size=3D2>1. The stats are not that significant, since there =
was no=20
  "last call" period announced in advance to gauge community=20
interest.</FONT></P>
  <P><FONT size=3D2>2. I do not think IETF uses company affiliation when =
measuring=20
  consensus. If it did, then the fact that 3 from Nortel are supporting =
NTIP, is=20
  an indication that there is an immediate need for NTIP given Nortel is =
a key=20
  player in this space.</FONT></P>
  <P><FONT size=3D2>------</FONT> </P>
  <P><FONT size=3D2>All,</FONT> </P>
  <P><FONT size=3D2>Now to focus the discussion back on the OLI =
solutions (NTIP or=20
  LMP-WDM, or a merged version),</FONT> </P>
  <P><FONT size=3D2>- There is consensus on a single protocol which I=20
  respect.</FONT> </P>
  <P><FONT size=3D2>- Key distinctions between NTIP and WDM-LMP:</FONT> =
</P>
  <P><FONT size=3D2>1. WDM-LMP assumes that LMP is a priority, people =
will=20
  implement LMP, hence WDM-LMP is a natural extension. The issues here=20
  are:</FONT></P>
  <P><FONT size=3D2>(a) this assumption is not accurate, the functions =
of NTIP (or=20
  WDM-LMP) are more urgent than LMP</FONT> <BR><FONT size=3D2>(b) there =
is=20
  significant baggage to be carried from LMP down to the WDM-LMP =
</FONT></P>
  <P><FONT size=3D2>2. WDM-LMP assumes a peer model between the OXC and =
the WDM=20
  system. The issue: </FONT></P>
  <P><FONT size=3D2>- this model doesn't reflect the reality that OXC =
and WDM are=20
  two different devices - the OXC-WDM relationship is client-server=20
  one.</FONT></P>
  <P><FONT size=3D2>I suggest merging the two proposals as =
follows:</FONT> </P>
  <P><FONT size=3D2>- remove unnecessary LMP baggage</FONT> <BR><FONT =
size=3D2>-=20
  adopt a client-server model </FONT><BR><FONT size=3D2>- allow for TCP =
as the=20
  transport</FONT> <BR><FONT size=3D2>- clarify a simplified =
autodiscovery=20
  mechanism</FONT> </P>
  <P><FONT size=3D2>Bilel.</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Andre=20
  Fredette [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</=
FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, July 26, 2001 2:52 PM</FONT> =
<BR><FONT=20
  size=3D2>To: [email-masked]</FONT> <BR><FONT size=3D2>Subject: RE: =
Optical=20
  Link Interface</FONT> </P><BR>
  <P><FONT size=3D2>&nbsp;From my count on the mailing list we have the =
following=20
  results so far:</FONT> </P>
  <P><FONT size=3D2>LMP-WDM:&nbsp; 8</FONT> <BR><FONT size=3D2>NTIP: 3 =
(All from=20
  Nortel)</FONT> <BR><FONT size=3D2>Agnostic: 1</FONT> </P>
  <P><FONT size=3D2>And then there are the other 16 co-authors of =
LMP-WDM who=20
  haven't posted </FONT><BR><FONT size=3D2>(perhaps because they don't =
think they=20
  have any new points to add).</FONT> </P>
  <P><FONT size=3D2>Andre</FONT> </P>
  <P><FONT size=3D2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt;Kireeti,</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;I have been following this thread with great interest. I =
agree with=20
  your</FONT> <BR><FONT size=3D2>&gt;conclusion that we should pick one =
protocol=20
  and move forward.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;You=20
  are talking about WG reaching a consensus. I cannot see how this =
is</FONT>=20
  <BR><FONT size=3D2>&gt;possible given the two very different views I =
see in the=20
  latest email</FONT> <BR><FONT size=3D2>&gt;exchanges.</FONT> <BR><FONT =

  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;How can we resolve the =
current=20
  dispute? What forum should we use to make</FONT> <BR><FONT =
size=3D2>&gt;a final=20
  decision on this?</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;Martin</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;-----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;From:=20
  Kireeti Kompella [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT=
>=20
  <BR><FONT size=3D2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT> =
<BR><FONT=20
  size=3D2>&gt;To: [email-masked]; =
[email-masked];</FONT>=20
  <BR><FONT size=3D2>&gt;[email-masked]</FONT> <BR><FONT =
size=3D2>&gt;Cc:=20
  [email-masked]; [email-masked];</FONT> <BR><FONT=20
  size=3D2>&gt;[email-masked]</FONT> <BR><FONT =
size=3D2>&gt;Subject: RE:=20
  Optical Link Interface</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =

  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;Hi Osama,</FONT> <BR><FONT =

  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Even though I don't =
think=20
  reviving CR-LDP and RSVP-TE history will get</FONT> <BR><FONT=20
  size=3D2>&gt;us</FONT> <BR><FONT size=3D2>&gt; &gt; anywhere</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;"Those who forget (ignore) =
history are=20
  doomed to repeat it."</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;Yes, it makes for painful recollections.&nbsp; We're =
living with=20
  the</FONT> <BR><FONT size=3D2>&gt;consequences now, though, and I =
don't want to=20
  again.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; the=20
  existence of two protocols here have proven to be useful.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;That's not what I'm =
hearing, either=20
  from customers, or from the</FONT> <BR><FONT size=3D2>&gt;WG =
(admittedly, the=20
  sample is small).</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;Listen carefully: I don't want LMP-WDM and NTIP moving=20
  forward.</FONT> <BR><FONT size=3D2>&gt;Just NTIP (or NTIP and LMP) is =
OKAY if=20
  that is what the WG</FONT> <BR><FONT size=3D2>&gt;consensus is.&nbsp; =
LMP-WDM=20
  and LMP works too.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;So: you've got the WG chairs (scarred and grumpy), the =
ADs</FONT>=20
  <BR><FONT size=3D2>&gt;and TA (speak up if I'm misrepresenting you), =
and=20
  customers</FONT> <BR><FONT size=3D2>&gt;saying, Pick one protocol and =
move=20
  forward.&nbsp; Let's do that.</FONT> <BR><FONT size=3D2>&gt;And, =
please, as=20
  Vijay says, let's resolve this already.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;Kireeti.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11911.952C0287--

Delivery-date: Mon, 30 Jul 2001 09:01:58 -0700
content-class: urn:content-classes:message
Subject: RE: Drafts update
Date:  Mon, 30 Jul 2001 11:59:12 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>

Response below.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, July 27, 2001 4:37 PM
To: [email-masked]
Subject: Drafts update

Hi Folks,

Can we get a sense of the consensus whether the following drafts
should be made CCAMP WG documents?  Please respond with
(a) yes
(b) no
(c) wait

1. draft-dubuc-lmp-mib-02.txt [YES]
2. draft-fontana-ccamp-gmpls-g709-00.txt [NO OPINION]
3. draft-kompella-ospf-gmpls-extensions-02.txt [YES]
4. draft-many-ccamp-gmpls-framework-00.txt [YES]
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [NO OPINION]
6. draft-many-ccamp-gmpls-routing-00.txt [YES]

(Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
 be a WG document, either in MPLS or CCAMP.)

Thanks,
Kireeti.

Delivery-date: Mon, 30 Jul 2001 08:50:53 -0700
From: [email-masked]
Date: Mon, 30 Jul 2001 10:49:09 -0500
Subject: RE: Drafts update
TO: [email-masked], [email-masked]

Kireeti,

My "votes" :

1. draft-dubuc-lmp-mib-02.txt - YES 
2. draft-fontana-ccamp-gmpls-g709-00.txt - YES
3. draft-kompella-ospf-gmpls-extensions-02.txt - YES
4. draft-many-ccamp-gmpls-framework-00.txt - YES - as a co-author :-)
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - Wait and 
see
6. draft-many-ccamp-gmpls-routing-00.txt - YES

Thanks,
Ananth

-----Original Message-----
From: kireeti [mailto:[email-masked]]
Sent: Friday, July 27, 2001 3:37 PM
To: ccamp
Cc: kireeti
Subject: Drafts update

Hi Folks,

Can we get a sense of the consensus whether the following drafts
should be made CCAMP WG documents?  Please respond with
(a) yes
(b) no
(c) wait

1. draft-dubuc-lmp-mib-02.txt
2. draft-fontana-ccamp-gmpls-g709-00.txt
3. draft-kompella-ospf-gmpls-extensions-02.txt
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
6. draft-many-ccamp-gmpls-routing-00.txt

(Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
 be a WG document, either in MPLS or CCAMP.)

Thanks,
Kireeti.

Delivery-date: Mon, 30 Jul 2001 08:17:18 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Mon, 30 Jul 2001 11:14:21 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1190A.4F6D1200
Content-Type: text/plain;
	charset="iso-8859-1"

Andre, 

2 comments on you statistics, then a proposal to progress:

1. The stats are not that significant, since there was no "last call" period
announced in advance to gauge community interest.

2. I do not think IETF uses company affiliation when measuring consensus. If
it did, then the fact that 3 from Nortel are supporting NTIP, is an
indication that there is an immediate need for NTIP given Nortel is a key
player in this space.

------

All,

Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a
merged version),

- There is consensus on a single protocol which I respect.

- Key distinctions between NTIP and WDM-LMP:

1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence
WDM-LMP is a natural extension. The issues here are:

(a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are
more urgent than LMP
(b) there is significant baggage to be carried from LMP down to the WDM-LMP 

2. WDM-LMP assumes a peer model between the OXC and the WDM system. The
issue: 

- this model doesn't reflect the reality that OXC and WDM are two different
devices - the OXC-WDM relationship is client-server one.

I suggest merging the two proposals as follows:

- remove unnecessary LMP baggage
- adopt a client-server model 
- allow for TCP as the transport
- clarify a simplified autodiscovery mechanism

Bilel.

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 2:52 PM
To: [email-masked]
Subject: RE: Optical Link Interface

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8
NTIP: 3 (All from Nortel)
Agnostic: 1

And then there are the other 16 co-authors of LMP-WDM who haven't posted 
(perhaps because they don't think they have any new points to add).

Andre

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
>Kireeti,
>
>I have been following this thread with great interest. I agree with your
>conclusion that we should pick one protocol and move forward.
>
>You are talking about WG reaching a consensus. I cannot see how this is
>possible given the two very different views I see in the latest email
>exchanges.
>
>How can we resolve the current dispute? What forum should we use to make
>a final decision on this?
>
>Martin
>
>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: Optical Link Interface
>
>
>Hi Osama,
>
> > Even though I don't think reviving CR-LDP and RSVP-TE history will get
>us
> > anywhere
>
>"Those who forget (ignore) history are doomed to repeat it."
>
>Yes, it makes for painful recollections.  We're living with the
>consequences now, though, and I don't want to again.
>
> > the existence of two protocols here have proven to be useful.
>
>That's not what I'm hearing, either from customers, or from the
>WG (admittedly, the sample is small).
>
>Listen carefully: I don't want LMP-WDM and NTIP moving forward.
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
>consensus is.  LMP-WDM and LMP works too.
>
>So: you've got the WG chairs (scarred and grumpy), the ADs
>and TA (speak up if I'm misrepresenting you), and customers
>saying, Pick one protocol and move forward.  Let's do that.
>And, please, as Vijay says, let's resolve this already.
>
>Kireeti.

------_=_NextPart_001_01C1190A.4F6D1200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Andre, </FONT>
</P>

<P><FONT SIZE=3D2>2 comments on you statistics, then a proposal to =
progress:</FONT>
</P>

<P><FONT SIZE=3D2>1. The stats are not that significant, since there =
was no &quot;last call&quot; period announced in advance to gauge =
community interest.</FONT></P>

<P><FONT SIZE=3D2>2. I do not think IETF uses company affiliation when =
measuring consensus. If it did, then the fact that 3 from Nortel are =
supporting NTIP, is an indication that there is an immediate need for =
NTIP given Nortel is a key player in this space.</FONT></P>

<P><FONT SIZE=3D2>------</FONT>
</P>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>Now to focus the discussion back on the OLI solutions =
(NTIP or LMP-WDM, or a merged version),</FONT>
</P>

<P><FONT SIZE=3D2>- There is consensus on a single protocol which I =
respect.</FONT>
</P>

<P><FONT SIZE=3D2>- Key distinctions between NTIP and WDM-LMP:</FONT>
</P>

<P><FONT SIZE=3D2>1. WDM-LMP assumes that LMP is a priority, people =
will implement LMP, hence WDM-LMP is a natural extension. The issues =
here are:</FONT></P>

<P><FONT SIZE=3D2>(a) this assumption is not accurate, the functions of =
NTIP (or WDM-LMP) are more urgent than LMP</FONT>
<BR><FONT SIZE=3D2>(b) there is significant baggage to be carried from =
LMP down to the WDM-LMP </FONT>
</P>

<P><FONT SIZE=3D2>2. WDM-LMP assumes a peer model between the OXC and =
the WDM system. The issue: </FONT>
</P>

<P><FONT SIZE=3D2>- this model doesn't reflect the reality that OXC and =
WDM are two different devices - the OXC-WDM relationship is =
client-server one.</FONT></P>

<P><FONT SIZE=3D2>I suggest merging the two proposals as =
follows:</FONT>
</P>

<P><FONT SIZE=3D2>- remove unnecessary LMP baggage</FONT>
<BR><FONT SIZE=3D2>- adopt a client-server model </FONT>
<BR><FONT SIZE=3D2>- allow for TCP as the transport</FONT>
<BR><FONT SIZE=3D2>- clarify a simplified autodiscovery =
mechanism</FONT>
</P>

<P><FONT SIZE=3D2>Bilel.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Andre Fredette [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 26, 2001 2:52 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Optical Link Interface</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;From my count on the mailing list we have the =
following results so far:</FONT>
</P>

<P><FONT SIZE=3D2>LMP-WDM:&nbsp; 8</FONT>
<BR><FONT SIZE=3D2>NTIP: 3 (All from Nortel)</FONT>
<BR><FONT SIZE=3D2>Agnostic: 1</FONT>
</P>

<P><FONT SIZE=3D2>And then there are the other 16 co-authors of LMP-WDM =
who haven't posted </FONT>
<BR><FONT SIZE=3D2>(perhaps because they don't think they have any new =
points to add).</FONT>
</P>

<P><FONT SIZE=3D2>Andre</FONT>
</P>

<P><FONT SIZE=3D2>At 02:00 PM 7/26/2001 -0400, Martin Dubuc =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I have been following this thread with great =
interest. I agree with your</FONT>
<BR><FONT SIZE=3D2>&gt;conclusion that we should pick one protocol and =
move forward.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;You are talking about WG reaching a consensus. I =
cannot see how this is</FONT>
<BR><FONT SIZE=3D2>&gt;possible given the two very different views I =
see in the latest email</FONT>
<BR><FONT SIZE=3D2>&gt;exchanges.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;How can we resolve the current dispute? What =
forum should we use to make</FONT>
<BR><FONT SIZE=3D2>&gt;a final decision on this?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Martin</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt;Sent: Wednesday, July 25, 2001 9:57 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: Optical Link Interface</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Hi Osama,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Even though I don't think reviving CR-LDP =
and RSVP-TE history will get</FONT>
<BR><FONT SIZE=3D2>&gt;us</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; anywhere</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;Those who forget (ignore) history are =
doomed to repeat it.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Yes, it makes for painful recollections.&nbsp; =
We're living with the</FONT>
<BR><FONT SIZE=3D2>&gt;consequences now, though, and I don't want to =
again.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the existence of two protocols here have =
proven to be useful.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;That's not what I'm hearing, either from =
customers, or from the</FONT>
<BR><FONT SIZE=3D2>&gt;WG (admittedly, the sample is small).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Listen carefully: I don't want LMP-WDM and NTIP =
moving forward.</FONT>
<BR><FONT SIZE=3D2>&gt;Just NTIP (or NTIP and LMP) is OKAY if that is =
what the WG</FONT>
<BR><FONT SIZE=3D2>&gt;consensus is.&nbsp; LMP-WDM and LMP works =
too.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;So: you've got the WG chairs (scarred and =
grumpy), the ADs</FONT>
<BR><FONT SIZE=3D2>&gt;and TA (speak up if I'm misrepresenting you), =
and customers</FONT>
<BR><FONT SIZE=3D2>&gt;saying, Pick one protocol and move =
forward.&nbsp; Let's do that.</FONT>
<BR><FONT SIZE=3D2>&gt;And, please, as Vijay says, let's resolve this =
already.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1190A.4F6D1200--

Delivery-date: Mon, 30 Jul 2001 07:41:28 -0700
From: Bala Rajagopalan <[email-masked]>
To: Andre Fredette <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject:  Optical Link Interface - LMP-WDM comments
Date: Mon, 30 Jul 2001 10:38:33 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C11905.4F0CA366
Content-Type: text/plain;
	charset="iso-8859-1"

Andre:

I'm attaching specific comments on LMP-WDM. Top level issues are
as follows:

1. Layer mix-up: In some places, the WDM system is required to
send information which is not native to OLS to the OXCs. In fact, 
this is very strange, because this information must originate from
the OXC domain, get configured in WDM, and then go back to OXCs. This
is a problem with OLI definition, not LMP-WDM itself. This requires
some discussion and clean up. 

2. Rather than tailoring the procedures for the particular requirements
(OLI), the draft seems to be written with the goal of maximal reuse of
LMP. This sometimes adds to the complexity of the proposal. Specifically,
LMP-WDM has many "extensions" to LMP, giving the impression that LMP-WDM is
a superset of LMP. I think there are differences in the situations where LMP
is applied as compared to LMP-WDM and these aspects are not discussed
sufficiently. I think a meticulous examination of the OLI requirements and
LMP procedures is necessary to just carve out a set of procedures for OLI,
rather than the superset approach. The maximal "re-use" argument doesn't
make any sense on the WDM side where there is no LMP. Or, for that matter,
where OXCs don't implement LMP. (This is where NTIP
makes a good point).

3. I'm afraid the current LMP link verification definition (and as a
corollary, LMP-WDM link
verification) has only a marginal value considering the investment
on hardware and protocol implementation. This is an area that requires more
work.

4. Some of the procedures in the draft must be more explicitly described
rather than saying that they are same as LMP's.

As you noted, a more careful examination of LMP itself is in order.

Regards,

Bala

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Andre Fredette [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 11:02 AM
> To: Bala Rajagopalan
> Cc: [email-masked]'
> Subject: RE: Optical Link Interface - Correction
> 
> 
> Bala,
> 
> Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP 
> debate, though I 
> do know that you think the OLI is important and you care that 
> the solution 
> is a good one.  I also agree (as I've stated before) that 
> either LMP-WDM or 
> NTIP could be made to work.  I just believe that having the 
> group focus on 
> one protocol rather than two will have a better end result 
> and aid in wider 
> deployment.
> 
> I'd also be glad to work on streamlining LMP-WDM.
> 
> As I see it, the basic requirements are the same for both LMP 
> and OLI for 
> the following:
> 1. Control Channel Maintenance (A.K.A. a light weight hello protocol).
> 2. The ability to exchange information on links (link 
> summary, perhaps with 
> a few different TLVs)
> 3. Discovery/Test.  (Note: The main purpose here is for two 
> devices to agree
>      on ID's for each link so information exchange regarding 
> the links is
>      possible.  The only reasonable way it is possible to 
> automate this, is to
>      send some type of test messages on the physical links).  
> To do this, 
> you need to be able
>      to terminate the links.
> 4. Fault Notification (By the way, I think the ChannelStatus Message 
> defined in LMP-WDM
>      could replace the current ChannelFail Message in LMP)
> 5. Notification whether a link is in use (ChannelActive Message).
> 
> Because of this we have proposed basing the OLI on LMP.
> 
> If these features need streamlining for LMP-WDM, they 
> probably also need 
> streamlining for LMP, so let's fix them once.
> 
> If there are other LMP-WDM-specific procedures that need to 
> be streamlined, 
> I'm all ears.
> 
> The major difference I see is that LMP needs is the ability 
> to manage link 
> bundles for the purpose of routing advertisements, but the 
> OLI doesn't.  In 
> the LMP-WDM case, I was expecting we'd usually have a single 
> link bundle 
> (effectively ignoring this feature of LMP).
> 
> Regarding the discovery portion of LMP (i.e., "link connectivity 
> verification"), from a protocol standpoint, it should work.  It does 
> require that the PXC be able to terminate each port with an 
> appropriate 
> interface (from LMP: "For the LMP Test procedure, the free 
> (unallocated) 
> data-bearing links MUST be opaque (i.e., able to be 
> terminated)").  The PXC 
> would need to support termination of the various types of 
> ports that could 
> be used (e.g., SONET, SDH).  But, this is more of a hardware 
> requirement 
> than a protocol requirement.
> 
> Andre
> 
> At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote:
> 
> >Forgot to attach the new NTIP draft.
> >Also, I meant "working on (4)", not (3).
> >
> >
> >Bala Rajagopalan
> >Tellium, Inc.
> >2 Crescent Place
> >P.O. Box 901
> >Oceanport, NJ 07757-0901
> >Tel: (732) 923-4237
> >Fax: (732) 923-9804
> >Email: [email-masked]
> >
> > > -----Original Message-----
> > > From: Bala Rajagopalan
> > > Sent: Friday, July 27, 2001 9:28 AM
> > > To: 'Andre Fredette'; [email-masked]
> > > Subject: RE: Optical Link Interface
> > >
> > >
> > > Andre:
> > >
> > > I believe you're counting me in the "agnostic" category.
> > > I hope this is not taken as "don't care", since I
> > > do have an interest in making a choice quickly.
> > >
> > > I have looked at the LMP-WDM draft (again) and the new
> > > NTIP draft sent by Osama (attached). I see the following:
> > >
> > > 1. Both these solutions gloss over the details of
> > >    auto-discovery between OXCs and WDM. (Note: the
> > >    issues are the same regardless of the protocol used
> > >    and neither provides full details. Furthermore,
> > >    the hardware requirements and actions under both
> > >    are the same).
> > >
> > > 2. If we leave out (1), then the other functions are
> > >    based on messaging over the control channel
> > >    between the OXC and the WDM. This messaging
> > >    can be done one way or the other.
> > >
> > > 3. Both require control channel maintenance using
> > >    (simple) keepalive.
> > >
> > > 4. It seems LMP-WDM can be streamlined to make it
> > >    more lean and mean.
> > >
> > > Unless there is a significant technical issue
> > > of one choice over the other, we have to consider
> > > the fact that LMP-WDM has the first mover advantage.
> > > Is it possible for
> > > the NTIP proponents to seriously consider working on
> > > (3)? Specifically, focus LMP-WDM on OLI requirements
> > > only and not carry any unrelated LMP concepts into
> > > LMP-WDM. Would this satisfy the design motivation for NTIP?
> > >
> > > Regards,
> > >
> > > Bala
> > >
> > >
> > > Bala Rajagopalan
> > > Tellium, Inc.
> > > 2 Crescent Place
> > > P.O. Box 901
> > > Oceanport, NJ 07757-0901
> > > Tel: (732) 923-4237
> > > Fax: (732) 923-9804
> > > Email: [email-masked]
> > >
> > > > -----Original Message-----
> > > > From: Andre Fredette [mailto:[email-masked]]
> > > > Sent: Thursday, July 26, 2001 2:52 PM
> > > > To: [email-masked]
> > > > Subject: RE: Optical Link Interface
> > > >
> > > >
> > > >  From my count on the mailing list we have the following
> > > > results so far:
> > > >
> > > > LMP-WDM:  8
> > > > NTIP: 3 (All from Nortel)
> > > > Agnostic: 1
> > > >
> > > > And then there are the other 16 co-authors of LMP-WDM who
> > > > haven't posted
> > > > (perhaps because they don't think they have any new 
> points to add).
> > > >
> > > > Andre
> > > >
> > > > At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> > > > >Kireeti,
> > > > >
> > > > >I have been following this thread with great interest. I
> > > > agree with your
> > > > >conclusion that we should pick one protocol and move forward.
> > > > >
> > > > >You are talking about WG reaching a consensus. I cannot see
> > > > how this is
> > > > >possible given the two very different views I see in the
> > > latest email
> > > > >exchanges.
> > > > >
> > > > >How can we resolve the current dispute? What forum should we
> > > > use to make
> > > > >a final decision on this?
> > > > >
> > > > >Martin
> > > > >
> > > > >-----Original Message-----
> > > > >From: Kireeti Kompella [mailto:[email-masked]]
> > > > >Sent: Wednesday, July 25, 2001 9:57 PM
> > > > >To: [email-masked]; [email-masked];
> > > > >[email-masked]
> > > > >Cc: [email-masked]; [email-masked];
> > > > >[email-masked]
> > > > >Subject: RE: Optical Link Interface
> > > > >
> > > > >
> > > > >Hi Osama,
> > > > >
> > > > > > Even though I don't think reviving CR-LDP and RSVP-TE
> > > > history will get
> > > > >us
> > > > > > anywhere
> > > > >
> > > > >"Those who forget (ignore) history are doomed to repeat it."
> > > > >
> > > > >Yes, it makes for painful recollections.  We're living with the
> > > > >consequences now, though, and I don't want to again.
> > > > >
> > > > > > the existence of two protocols here have proven to 
> be useful.
> > > > >
> > > > >That's not what I'm hearing, either from customers, or from the
> > > > >WG (admittedly, the sample is small).
> > > > >
> > > > >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> > > > >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> > > > >consensus is.  LMP-WDM and LMP works too.
> > > > >
> > > > >So: you've got the WG chairs (scarred and grumpy), the ADs
> > > > >and TA (speak up if I'm misrepresenting you), and customers
> > > > >saying, Pick one protocol and move forward.  Let's do that.
> > > > >And, please, as Vijay says, let's resolve this already.
> > > > >
> > > > >Kireeti.
> > > >
> > >
> >
> >
> 

------_=_NextPart_000_01C11905.4F0CA366
Content-Type: application/msword;
	name="draft-fredette-lmp-wdm-01-comments.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="draft-fredette-lmp-wdm-01-comments.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAHgEAAAAAAAAA
EAAAIAEAAAEAAAD+////AAAAABsBAAAcAQAAHQEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C11905.4F0CA366--

Delivery-date: Mon, 30 Jul 2001 07:04:18 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-00.txt
Date: Mon, 30 Jul 2001 09:59:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol (LMP)
	Author(s)	: J. Lang et al.
	Filename	: draft-ietf-ccamp-lmp-00.txt
	Pages		: 57
	Date		: 27-Jul-01
	
Future networks will consist of photonic switches, optical 
crossconnects, and routers that may be configured with control 
channels, links, and bundled links.  This draft specifies a link 
management protocol (LMP) that runs between neighboring nodes and is 
used to manage traffic engineering (TE) links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lmp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 30 Jul 2001 06:58:03 -0700
Date: Mon, 30 Jul 2001 09:54:42 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Drafts update

Kireeti,

May I ask why draft-xu-bgp-gmpls-01.txt is not in the list?

Thanks,

Yangguang

Kireeti Kompella wrote:
> 
> Hi Folks,
> 
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
> 
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
> 
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
> 
> Thanks,
> Kireeti.

Delivery-date: Fri, 27 Jul 2001 18:57:51 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Drafts update
Date: Fri, 27 Jul 2001 18:56:32 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11708.864CEC90
Content-Type: text/plain;
	charset="iso-8859-1"

I would second Eric except putting "YES" to #2. My point is that the
"common" control plane must tackle "specific" issues to be "common" - we so
far have gmpls framework in place and several "thinner" docs on the top for
gmpls to support sonet/sdh,wdm,... G709 might be legitimate/special enough
to warrant study. just my 2c. 
-Dan Guo

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
SSubject: Re: Drafts update
Kireeti,
    My revised answer:
    1. Yes, CCAMP
    2. Wait to hear why this is a 'common control and management plane'
            issue as opposed to an optical networking specific issue.
    3. Yes
    4. Wait until after London meeting to gauge its acceptance there
    5. Wait until after London meeting to gauge its acceptance there
    6. Yes

------_=_NextPart_001_01C11708.864CEC90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Drafts update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would second Eric except putting &quot;YES&quot; to =
#2. My point is that the &quot;common&quot; control plane must tackle =
&quot;specific&quot; issues to be &quot;common&quot; - we so far have =
gmpls framework in place and several &quot;thinner&quot; docs on the =
top for gmpls to support sonet/sdh,wdm,... G709 might be =
legitimate/special enough to warrant study. just my 2c. </FONT></P>

<P><FONT SIZE=3D2>-Dan Guo</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Eric Gray [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>SSubject: Re: Drafts update</FONT>
<BR><FONT SIZE=3D2>Kireeti,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; My revised answer:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 1. Yes, CCAMP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 2. Wait to hear why this is a =
'common control and management plane'</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; issue as opposed to an optical networking specific issue.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 3. Yes</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 4. Wait until after London =
meeting to gauge its acceptance there</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 5. Wait until after London =
meeting to gauge its acceptance there</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 6. Yes</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11708.864CEC90--

Delivery-date: Fri, 27 Jul 2001 18:28:59 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt
Date: Fri, 27 Jul 2001 18:24:18 -0700

Hi Dean,
         I think the routing module should be aware of only the data
channel interfaces and not the control channels/interfaces (at least not for 
routing of GMPLS messages). There may be 2 cases where either there will be 
one-to-one mapping between the control channel and data channel or multiple 
data channel interfaces will be served by 1 common control channel. Once I 
get the information from routing module that which specific outgoing data 
channel/interface is used for resource
allocation then I can very well get the control channel where to send
the control traffic.
Initially when I configure my data channel/interfaces, I can configure
the information that which control channel/interface this data
channel/interface has to use.

Regards,
manoj.

>From: "Cheng, Dean" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, [email-masked]
>CC: [email-masked]
>Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt
>Date: Fri, 27 Jul 2001 18:04:34 -0700
>
>Manoj,
>
>   The routing module certainly needs to be aware of
>   control channel network for reasons including the
>   following:
>
>      1) To route/forward control protocol packets
>         including OSPF/ISIS/RSVP/CR-LDP.
>
>      2) To route/forward management traffic if
>         chosen to do so.
>
>Dean
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Friday, July 27, 2001 5:20 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt
>
>
>Hi All,
>         I have gone through draft-many-ccamp-gmpls-routing-00.txt and
>draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers 
>to
>
>the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned
>that control channels are advertised into routing as normal
>links. But the IInd draft (ospf-gmpls) has not mentioned anything about
>it. Should the routing module be aware of control channel network ? I
>feel it should not.
>
>After reading the IInd draft it seems that routing module should not be
>aware of control channel (network) but I got this doubt as the IInd
>draft makes reference to the Ist one.
>
>Please clarify.
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 27 Jul 2001 18:12:38 -0700
From: "Cheng, Dean" <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt
Date: Fri, 27 Jul 2001 18:04:34 -0700

Manoj,

  The routing module certainly needs to be aware of 
  control channel network for reasons including the
  following:

     1) To route/forward control protocol packets
        including OSPF/ISIS/RSVP/CR-LDP.

     2) To route/forward management traffic if 
        chosen to do so. 

Dean

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Friday, July 27, 2001 5:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt

Hi All,
        I have gone through draft-many-ccamp-gmpls-routing-00.txt and
draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers to

the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned 
that control channels are advertised into routing as normal
links. But the IInd draft (ospf-gmpls) has not mentioned anything about
it. Should the routing module be aware of control channel network ? I
feel it should not.

After reading the IInd draft it seems that routing module should not be
aware of control channel (network) but I got this doubt as the IInd
draft makes reference to the Ist one.

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 27 Jul 2001 17:22:16 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt
Date: Fri, 27 Jul 2001 17:19:31 -0700

Hi All,
        I have gone through draft-many-ccamp-gmpls-routing-00.txt and
draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers to 
the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned 
that control channels are advertised into routing as normal
links. But the IInd draft (ospf-gmpls) has not mentioned anything about
it. Should the routing module be aware of control channel network ? I
feel it should not.
After reading the IInd draft it seems that routing module should not be
aware of control channel (network) but I got this doubt as the IInd
draft makes reference to the Ist one.

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 27 Jul 2001 17:09:47 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Doubt in draft  draft-ietf-mpls-generalized-signalling-05.txt
Date: Fri, 27 Jul 2001 17:08:41 -0700

Hi All,
         I have following doubt in "draft-ietf-mpls-generalized
-signalling-05.txt" draft.
This draft has introduced new field switching type in Generalized Label
Request Object. After looking at the structure of switching type field
in latest OSPF document (GMPLS extensions to OSPF, Field Name :
Interface switching capability descriptor), I could not make out why
this is present in per LSP establishment request ? This field
advertises the bandwidth (both min. and max.) for various priority
levels (p = 0 -> 7). Furthermore, this field also contain Encoding (I
assume LSP encoding type) field which is already there in Generalized
Label Reqest object.
I am not able to understand why this type of information is required in
Per Connection Establishment Request ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 27 Jul 2001 15:03:01 -0700
Date: Fri, 27 Jul 2001 18:02:16 -0400
From: Eric Gray <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: Drafts update

Kireeti,

    My revised answer:

    1. Yes, CCAMP
    2. Wait to hear why this is a 'common control and management plane'
            issue as opposed to an optical networking specific issue.
    3. Yes
    4. Wait until after London meeting to gauge its acceptance there
    5. Wait until after London meeting to gauge its acceptance there
    6. Yes

You wrote:

>
> 4. draft-many-ccamp-gmpls-framework-00.txt

>

Envelope-to: [email-masked]
Delivery-date: Fri, 27 Jul 2001 14:48:22 -0700
Date: Fri, 27 Jul 2001 14:45:47 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Drafts update
Cc: [email-masked]

Hi Eric,

> Is there any reason why you skipped number 4?

Is "I failed kindergarten" a valid excuse?

Thanks, Eric: I missed one, through the excessive use of cut
and insufficient use of paste:

4. draft-many-ccamp-gmpls-framework-00.txt

Kireeti.

Delivery-date: Fri, 27 Jul 2001 14:32:59 -0700
Date: Fri, 27 Jul 2001 17:31:55 -0400
From: Eric Gray <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: Drafts update

Kireeti,

    Is there any reason why you skipped number 4?  Here's my answers
to 1-3 and 5-6...

    1. Yes, CCAMP
    2. Wait to hear why this is a 'common control and management plane'
            issue as opposed to an optical networking specific issue.
    3. Yes
    5. Wait until after London meeting to gauge its acceptance there
    6. Yes

You wrote:

> Hi Folks,
>
> Can we get a sense of the consensus whether the following drafts
> should be made CCAMP WG documents?  Please respond with
> (a) yes
> (b) no
> (c) wait
>
> 1. draft-dubuc-lmp-mib-02.txt
> 2. draft-fontana-ccamp-gmpls-g709-00.txt
> 3. draft-kompella-ospf-gmpls-extensions-02.txt
> 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> 6. draft-many-ccamp-gmpls-routing-00.txt
>
> (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
>  be a WG document, either in MPLS or CCAMP.)
>
> Thanks,
> Kireeti.

Delivery-date: Fri, 27 Jul 2001 14:18:39 -0700
From: Ayan Banerjee <[email-masked]>
To: [email-masked]
Subject: RE: Drafts update
Date: Fri, 27 Jul 2001 14:17:25 -0700

Response attached. 

Thanks,
Ayan

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, July 27, 2001 1:37 PM
To: [email-masked]
Subject: Drafts update

Hi Folks,

Can we get a sense of the consensus whether the following drafts
should be made CCAMP WG documents?  Please respond with
(a) yes
(b) no
(c) wait

1. draft-dubuc-lmp-mib-02.txt [YES]
2. draft-fontana-ccamp-gmpls-g709-00.txt
3. draft-kompella-ospf-gmpls-extensions-02.txt [YES]
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
6. draft-many-ccamp-gmpls-routing-00.txt [YES]

(Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
 be a WG document, either in MPLS or CCAMP.)

Thanks,
Kireeti.

Envelope-to: [email-masked]
Delivery-date: Fri, 27 Jul 2001 13:38:34 -0700
Date: Fri, 27 Jul 2001 13:37:16 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Drafts update

Hi Folks,

Can we get a sense of the consensus whether the following drafts
should be made CCAMP WG documents?  Please respond with
(a) yes
(b) no
(c) wait

1. draft-dubuc-lmp-mib-02.txt
2. draft-fontana-ccamp-gmpls-g709-00.txt
3. draft-kompella-ospf-gmpls-extensions-02.txt
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
6. draft-many-ccamp-gmpls-routing-00.txt

(Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this
 be a WG document, either in MPLS or CCAMP.)

Thanks,
Kireeti.

Envelope-to: [email-masked]
Delivery-date: Fri, 27 Jul 2001 13:23:17 -0700
Date: Fri, 27 Jul 2001 13:21:24 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP agenda

Hi,

Here is the CCAMP agenda.

If we've missed you, or you'd like a slot, send mail to us (the WG
chairs, *not* the list), and we'll see if we can accommodate you.

Kireeti & Vijay.
---------------

Administrivia/Blue Sheets/
Minutes takers			 5 min
Charter	& drafts update		10 min
Update from the Design Teams	10 min

GMPLS update (Lou Berger)	10 min
SONET/SDH (Eric Mannie)		15 min
G709 (Dimitri?)			10 min

Architecture (Eric Mannie)	10 min
Framework (Yangguang Xu)	 5 min
SONET/SDH framework (Greg B.)	 5 min

LMP (Jonathan Lang)		 5 min

OLI Reqts (Andre+Osama)		 5 min
NTIP (Osama Aboul-Magd)		10 min
LMP-WDM	(Andre Fredette)	10 min
resolution			 5 min

Tunnel Trace (Ron Bonica)	10 min
RSVP for Mesh (Kalmanek/Li)	 5 min	| subject to time
RSVP for OAPS (Dan Guo)		 5 min	| availability

-------------------------------

CCAMP WG documents

(Joint with MPLS)
draft-ietf-mpls-generalized-cr-ldp-04.txt
draft-ietf-mpls-generalized-rsvp-te-04.txt
draft-ietf-mpls-generalized-signaling-05.txt
draft-ietf-mpls-lmp-02.txt

draft-ietf-ccamp-gmpls-architecture-00.txt
draft-ietf-ccamp-gmpls-sonet-sdh-01.txt

Delivery-date: Fri, 27 Jul 2001 08:51:07 -0700
Date: Fri, 27 Jul 2001 17:49:31 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG-NA
To: Andre Fredette <[email-masked]>
CC: Bala Rajagopalan <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Optical Link Interface - Correction

This is a multi-part message in MIME format.
--------------B6C820374E870FA8F34E3C3C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andre, 

If in the following statement:
> 4. Fault Notification (By the way, I think the ChannelStatus 
> Message defined in LMP-WDM could replace the current ChannelFail 
> Message in LMP)

You refer to the added value of the "Condition" field then i agree 
with your proposal.

In order to re-inforce my previous statement i am strongly convinced 
that the proposed LMP (extended to WDM) approach is the best one. It 
allows to have a complete solution for the IP-based distributed control 
plane relying on 3 protocols (and not 4). My vote is clearly for
LMP-WDM.

Regards,
Dimitri.

Andre Fredette wrote:
> 
> Bala,
> 
> Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP debate, though I
> do know that you think the OLI is important and you care that the solution
> is a good one.  I also agree (as I've stated before) that either LMP-WDM or
> NTIP could be made to work.  I just believe that having the group focus on
> one protocol rather than two will have a better end result and aid in wider
> deployment.
> 
> I'd also be glad to work on streamlining LMP-WDM.
> 
> As I see it, the basic requirements are the same for both LMP and OLI for
> the following:
> 1. Control Channel Maintenance (A.K.A. a light weight hello protocol).
> 2. The ability to exchange information on links (link summary, perhaps with
> a few different TLVs)
> 3. Discovery/Test.  (Note: The main purpose here is for two devices to agree
>      on ID's for each link so information exchange regarding the links is
>      possible.  The only reasonable way it is possible to automate this, is to
>      send some type of test messages on the physical links).  To do this,
> you need to be able
>      to terminate the links.
> 4. Fault Notification (By the way, I think the ChannelStatus Message
> defined in LMP-WDM
>      could replace the current ChannelFail Message in LMP)
> 5. Notification whether a link is in use (ChannelActive Message).
> 
> Because of this we have proposed basing the OLI on LMP.
> 
> If these features need streamlining for LMP-WDM, they probably also need
> streamlining for LMP, so let's fix them once.
> 
> If there are other LMP-WDM-specific procedures that need to be streamlined,
> I'm all ears.
> 
> The major difference I see is that LMP needs is the ability to manage link
> bundles for the purpose of routing advertisements, but the OLI doesn't.  In
> the LMP-WDM case, I was expecting we'd usually have a single link bundle
> (effectively ignoring this feature of LMP).
> 
> Regarding the discovery portion of LMP (i.e., "link connectivity
> verification"), from a protocol standpoint, it should work.  It does
> require that the PXC be able to terminate each port with an appropriate
> interface (from LMP: "For the LMP Test procedure, the free (unallocated)
> data-bearing links MUST be opaque (i.e., able to be terminated)").  The PXC
> would need to support termination of the various types of ports that could
> be used (e.g., SONET, SDH).  But, this is more of a hardware requirement
> than a protocol requirement.
> 
> Andre
> 
> At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote:
> 
> >Forgot to attach the new NTIP draft.
> >Also, I meant "working on (4)", not (3).
> >
> >
> >Bala Rajagopalan
> >Tellium, Inc.
> >2 Crescent Place
> >P.O. Box 901
> >Oceanport, NJ 07757-0901
> >Tel: (732) 923-4237
> >Fax: (732) 923-9804
> >Email: [email-masked]
> >
> > > -----Original Message-----
> > > From: Bala Rajagopalan
> > > Sent: Friday, July 27, 2001 9:28 AM
> > > To: 'Andre Fredette'; [email-masked]
> > > Subject: RE: Optical Link Interface
> > >
> > >
> > > Andre:
> > >
> > > I believe you're counting me in the "agnostic" category.
> > > I hope this is not taken as "don't care", since I
> > > do have an interest in making a choice quickly.
> > >
> > > I have looked at the LMP-WDM draft (again) and the new
> > > NTIP draft sent by Osama (attached). I see the following:
> > >
> > > 1. Both these solutions gloss over the details of
> > >    auto-discovery between OXCs and WDM. (Note: the
> > >    issues are the same regardless of the protocol used
> > >    and neither provides full details. Furthermore,
> > >    the hardware requirements and actions under both
> > >    are the same).
> > >
> > > 2. If we leave out (1), then the other functions are
> > >    based on messaging over the control channel
> > >    between the OXC and the WDM. This messaging
> > >    can be done one way or the other.
> > >
> > > 3. Both require control channel maintenance using
> > >    (simple) keepalive.
> > >
> > > 4. It seems LMP-WDM can be streamlined to make it
> > >    more lean and mean.
> > >
> > > Unless there is a significant technical issue
> > > of one choice over the other, we have to consider
> > > the fact that LMP-WDM has the first mover advantage.
> > > Is it possible for
> > > the NTIP proponents to seriously consider working on
> > > (3)? Specifically, focus LMP-WDM on OLI requirements
> > > only and not carry any unrelated LMP concepts into
> > > LMP-WDM. Would this satisfy the design motivation for NTIP?
> > >
> > > Regards,
> > >
> > > Bala
> > >
> > >
> > > Bala Rajagopalan
> > > Tellium, Inc.
> > > 2 Crescent Place
> > > P.O. Box 901
> > > Oceanport, NJ 07757-0901
> > > Tel: (732) 923-4237
> > > Fax: (732) 923-9804
> > > Email: [email-masked]
> > >
> > > > -----Original Message-----
> > > > From: Andre Fredette [mailto:[email-masked]]
> > > > Sent: Thursday, July 26, 2001 2:52 PM
> > > > To: [email-masked]
> > > > Subject: RE: Optical Link Interface
> > > >
> > > >
> > > >  From my count on the mailing list we have the following
> > > > results so far:
> > > >
> > > > LMP-WDM:  8
> > > > NTIP: 3 (All from Nortel)
> > > > Agnostic: 1
> > > >
> > > > And then there are the other 16 co-authors of LMP-WDM who
> > > > haven't posted
> > > > (perhaps because they don't think they have any new points to add).
> > > >
> > > > Andre
> > > >
> > > > At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> > > > >Kireeti,
> > > > >
> > > > >I have been following this thread with great interest. I
> > > > agree with your
> > > > >conclusion that we should pick one protocol and move forward.
> > > > >
> > > > >You are talking about WG reaching a consensus. I cannot see
> > > > how this is
> > > > >possible given the two very different views I see in the
> > > latest email
> > > > >exchanges.
> > > > >
> > > > >How can we resolve the current dispute? What forum should we
> > > > use to make
> > > > >a final decision on this?
> > > > >
> > > > >Martin
> > > > >
> > > > >-----Original Message-----
> > > > >From: Kireeti Kompella [mailto:[email-masked]]
> > > > >Sent: Wednesday, July 25, 2001 9:57 PM
> > > > >To: [email-masked]; [email-masked];
> > > > >[email-masked]
> > > > >Cc: [email-masked]; [email-masked];
> > > > >[email-masked]
> > > > >Subject: RE: Optical Link Interface
> > > > >
> > > > >
> > > > >Hi Osama,
> > > > >
> > > > > > Even though I don't think reviving CR-LDP and RSVP-TE
> > > > history will get
> > > > >us
> > > > > > anywhere
> > > > >
> > > > >"Those who forget (ignore) history are doomed to repeat it."
> > > > >
> > > > >Yes, it makes for painful recollections.  We're living with the
> > > > >consequences now, though, and I don't want to again.
> > > > >
> > > > > > the existence of two protocols here have proven to be useful.
> > > > >
> > > > >That's not what I'm hearing, either from customers, or from the
> > > > >WG (admittedly, the sample is small).
> > > > >
> > > > >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> > > > >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> > > > >consensus is.  LMP-WDM and LMP works too.
> > > > >
> > > > >So: you've got the WG chairs (scarred and grumpy), the ADs
> > > > >and TA (speak up if I'm misrepresenting you), and customers
> > > > >saying, Pick one protocol and move forward.  Let's do that.
> > > > >And, please, as Vijay says, let's resolve this already.
> > > > >
> > > > >Kireeti.
> > > >
> > >
> >
> >
--------------B6C820374E870FA8F34E3C3C
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------B6C820374E870FA8F34E3C3C--

Envelope-to: [email-masked]
Delivery-date: Fri, 27 Jul 2001 08:27:56 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Optical Link Interface
Date: Fri, 27 Jul 2001 11:11:57 -0400

Just a brief $0.02 (perhaps only $0.015).

>From an implementation point of view it seems preferable to extend a protocol
that one might already have implemented thereby re-using code and reaching
stability more quickly.

>From a standardization point of view there seems no sense in having two
protocols that can provide the same function.  We should be looking towards ease
of interoperation - why shouldn't the OLI be an interface between components
manufactured by different OEMs?

To say that LMP-WDM as an extension of LMP is of no help because you don't
necessarily have LMP only puts LMP-WDM on the same footing as NTIP, not behind
it.

It seems to me that issues of function level in the two protocols are a
diversion since it is well within the capabilities of all concerned to enhance
either protocol to provide the function required.  So it should be possible to
make LMP-WDM or NTIP satisfy the OLI requirements.

This leaves us with Kireeti's list which I paraphrase as

1. One protocol or two?
1a. IETF should (will!) only allow one of LMP-WDM and NTIP to go forward, as
Kireeti has said.
1b. People implementing LMP will surely prefer LMP-WDM.
2. Peer or master-slave relationship. Of some interest, but it is always
possible to make a peer-based protocol behave in a master-slave way and vice
versa.
3. Underlying transport.  Does a protocol's dependency on certain
characteristics of the underlying transport constrain the implementation and
introduce issues?

My vote is for LMP-WDM (but I am an author).
I sympathize with the inventors of NTIP and urge them to bring what they have
learned to the LMP-WDM draft to make the finished protocol even more successful.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Fri, 27 Jul 2001 08:27:51 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Explicit Label Control
Date: Fri, 27 Jul 2001 10:51:55 -0400

Manoj,

Your reading of the drafts is correct, explicit label control is intended to
allow an ERO to include labels for any hop as well as an ultimate label for
egress control.

That O-UNI (currently?) only uses ERO labels for egress control is fine.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]
----- Original Message -----
From: "manoj juneja" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 26, 2001 3:15 PM
Subject: Explicit Label Control

> Hi All,
>
> In GMPLS and O-UNI drafts, the concept of Egress/explicit Label control is
> described. Is this valid only at egress or intermediate nodes also ? I have
> gone through both the GMPLS and O-UNI drafts. The O-UNI draft clearly
> describes it as Egress Label i.e. label to be used at destination UNI. But
> GMPLS describes the term Explicit Label object. The GMPLS draft mentions
> that the explicit label subobject can be present anywhere (as per my
> understanding) in ERO provided that this sub-object should follow a
> subobject containing the IP address or interface identifier (strict object).
> I mean to say whether the Explicit Label object will only be at the
> end of ERO or it can appear in between in case of GMPLS ?
>
> Please clarify.
>
> Regards,
> manoj.
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>

Delivery-date: Fri, 27 Jul 2001 08:08:20 -0700
From: Andre Fredette <[email-masked]>
To: Bala Rajagopalan <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 27 Jul 2001 11:01:37 -0400
Subject: RE: Optical Link Interface - Correction

Bala,

Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP debate, though I 
do know that you think the OLI is important and you care that the solution 
is a good one.  I also agree (as I've stated before) that either LMP-WDM or 
NTIP could be made to work.  I just believe that having the group focus on 
one protocol rather than two will have a better end result and aid in wider 
deployment.

I'd also be glad to work on streamlining LMP-WDM.

As I see it, the basic requirements are the same for both LMP and OLI for 
the following:
1. Control Channel Maintenance (A.K.A. a light weight hello protocol).
2. The ability to exchange information on links (link summary, perhaps with 
a few different TLVs)
3. Discovery/Test.  (Note: The main purpose here is for two devices to agree
     on ID's for each link so information exchange regarding the links is
     possible.  The only reasonable way it is possible to automate this, is to
     send some type of test messages on the physical links).  To do this, 
you need to be able
     to terminate the links.
4. Fault Notification (By the way, I think the ChannelStatus Message 
defined in LMP-WDM
     could replace the current ChannelFail Message in LMP)
5. Notification whether a link is in use (ChannelActive Message).

Because of this we have proposed basing the OLI on LMP.

If these features need streamlining for LMP-WDM, they probably also need 
streamlining for LMP, so let's fix them once.

If there are other LMP-WDM-specific procedures that need to be streamlined, 
I'm all ears.

The major difference I see is that LMP needs is the ability to manage link 
bundles for the purpose of routing advertisements, but the OLI doesn't.  In 
the LMP-WDM case, I was expecting we'd usually have a single link bundle 
(effectively ignoring this feature of LMP).

Regarding the discovery portion of LMP (i.e., "link connectivity 
verification"), from a protocol standpoint, it should work.  It does 
require that the PXC be able to terminate each port with an appropriate 
interface (from LMP: "For the LMP Test procedure, the free (unallocated) 
data-bearing links MUST be opaque (i.e., able to be terminated)").  The PXC 
would need to support termination of the various types of ports that could 
be used (e.g., SONET, SDH).  But, this is more of a hardware requirement 
than a protocol requirement.

Andre

At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote:

>Forgot to attach the new NTIP draft.
>Also, I meant "working on (4)", not (3).
>
>
>Bala Rajagopalan
>Tellium, Inc.
>2 Crescent Place
>P.O. Box 901
>Oceanport, NJ 07757-0901
>Tel: (732) 923-4237
>Fax: (732) 923-9804
>Email: [email-masked]
>
> > -----Original Message-----
> > From: Bala Rajagopalan
> > Sent: Friday, July 27, 2001 9:28 AM
> > To: 'Andre Fredette'; [email-masked]
> > Subject: RE: Optical Link Interface
> >
> >
> > Andre:
> >
> > I believe you're counting me in the "agnostic" category.
> > I hope this is not taken as "don't care", since I
> > do have an interest in making a choice quickly.
> >
> > I have looked at the LMP-WDM draft (again) and the new
> > NTIP draft sent by Osama (attached). I see the following:
> >
> > 1. Both these solutions gloss over the details of
> >    auto-discovery between OXCs and WDM. (Note: the
> >    issues are the same regardless of the protocol used
> >    and neither provides full details. Furthermore,
> >    the hardware requirements and actions under both
> >    are the same).
> >
> > 2. If we leave out (1), then the other functions are
> >    based on messaging over the control channel
> >    between the OXC and the WDM. This messaging
> >    can be done one way or the other.
> >
> > 3. Both require control channel maintenance using
> >    (simple) keepalive.
> >
> > 4. It seems LMP-WDM can be streamlined to make it
> >    more lean and mean.
> >
> > Unless there is a significant technical issue
> > of one choice over the other, we have to consider
> > the fact that LMP-WDM has the first mover advantage.
> > Is it possible for
> > the NTIP proponents to seriously consider working on
> > (3)? Specifically, focus LMP-WDM on OLI requirements
> > only and not carry any unrelated LMP concepts into
> > LMP-WDM. Would this satisfy the design motivation for NTIP?
> >
> > Regards,
> >
> > Bala
> >
> >
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> >
> > > -----Original Message-----
> > > From: Andre Fredette [mailto:[email-masked]]
> > > Sent: Thursday, July 26, 2001 2:52 PM
> > > To: [email-masked]
> > > Subject: RE: Optical Link Interface
> > >
> > >
> > >  From my count on the mailing list we have the following
> > > results so far:
> > >
> > > LMP-WDM:  8
> > > NTIP: 3 (All from Nortel)
> > > Agnostic: 1
> > >
> > > And then there are the other 16 co-authors of LMP-WDM who
> > > haven't posted
> > > (perhaps because they don't think they have any new points to add).
> > >
> > > Andre
> > >
> > > At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> > > >Kireeti,
> > > >
> > > >I have been following this thread with great interest. I
> > > agree with your
> > > >conclusion that we should pick one protocol and move forward.
> > > >
> > > >You are talking about WG reaching a consensus. I cannot see
> > > how this is
> > > >possible given the two very different views I see in the
> > latest email
> > > >exchanges.
> > > >
> > > >How can we resolve the current dispute? What forum should we
> > > use to make
> > > >a final decision on this?
> > > >
> > > >Martin
> > > >
> > > >-----Original Message-----
> > > >From: Kireeti Kompella [mailto:[email-masked]]
> > > >Sent: Wednesday, July 25, 2001 9:57 PM
> > > >To: [email-masked]; [email-masked];
> > > >[email-masked]
> > > >Cc: [email-masked]; [email-masked];
> > > >[email-masked]
> > > >Subject: RE: Optical Link Interface
> > > >
> > > >
> > > >Hi Osama,
> > > >
> > > > > Even though I don't think reviving CR-LDP and RSVP-TE
> > > history will get
> > > >us
> > > > > anywhere
> > > >
> > > >"Those who forget (ignore) history are doomed to repeat it."
> > > >
> > > >Yes, it makes for painful recollections.  We're living with the
> > > >consequences now, though, and I don't want to again.
> > > >
> > > > > the existence of two protocols here have proven to be useful.
> > > >
> > > >That's not what I'm hearing, either from customers, or from the
> > > >WG (admittedly, the sample is small).
> > > >
> > > >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> > > >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> > > >consensus is.  LMP-WDM and LMP works too.
> > > >
> > > >So: you've got the WG chairs (scarred and grumpy), the ADs
> > > >and TA (speak up if I'm misrepresenting you), and customers
> > > >saying, Pick one protocol and move forward.  Let's do that.
> > > >And, please, as Vijay says, let's resolve this already.
> > > >
> > > >Kireeti.
> > >
> >
>
>

Delivery-date: Fri, 27 Jul 2001 08:03:25 -0700
Date: Fri, 27 Jul 2001 10:57:01 -0400
From: Eric Gray <[email-masked]>
To: Lou Berger <[email-masked]>
Cc: [email-masked]
Subject: Re: new gmpls signaling drafts

Lou,

    Just to nag on a bit, weren't these supposed to be in CCAMP?

    Why did they not get submitted as

            draft-ietf-ccamp-generalized-signaling-00.txt
            draft-ietf-ccamp-generalized-rsvp-te-00.txt
            draft-ietf-ccamp-generalized-cr-ldp-00.txt

You wrote:

> FYI -
>
> New versions of the GMPLS signaling drafts have been submitted.  We
> attempted to cover the major last call issues.  For those who don't want to
> wait, the drafts are available at:
>
> http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt

Delivery-date: Fri, 27 Jul 2001 07:41:12 -0700
Date: Fri, 27 Jul 2001 10:35:06 -0400
From: Matt Squire <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Optical Link Interface

You can bump the LMP-WDM count up to 9.  I just don't see any techical
advantages to NTIP and the implementation path (based on the assumption
that many folks will implement LMP) is easier with the LMP-WDM solution.

And to echo everyone else's sentiment: Two protocols be bad.  

Andre Fredette wrote:
> 
>  From my count on the mailing list we have the following results so far:
> 
> LMP-WDM:  8
> NTIP: 3 (All from Nortel)
> Agnostic: 1
> 
> And then there are the other 16 co-authors of LMP-WDM who haven't posted
> (perhaps because they don't think they have any new points to add).
> 
> Andre
>

Delivery-date: Fri, 27 Jul 2001 06:36:47 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface - Correction
Date: Fri, 27 Jul 2001 09:36:10 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C116A1.18EB861E
Content-Type: text/plain;
	charset="iso-8859-1"

Forgot to attach the new NTIP draft.
Also, I meant "working on (4)", not (3).

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Bala Rajagopalan 
> Sent: Friday, July 27, 2001 9:28 AM
> To: 'Andre Fredette'; [email-masked]
> Subject: RE: Optical Link Interface
> 
> 
> Andre:
> 
> I believe you're counting me in the "agnostic" category.
> I hope this is not taken as "don't care", since I
> do have an interest in making a choice quickly.
> 
> I have looked at the LMP-WDM draft (again) and the new
> NTIP draft sent by Osama (attached). I see the following:
> 
> 1. Both these solutions gloss over the details of
>    auto-discovery between OXCs and WDM. (Note: the
>    issues are the same regardless of the protocol used
>    and neither provides full details. Furthermore,
>    the hardware requirements and actions under both 
>    are the same).
> 
> 2. If we leave out (1), then the other functions are
>    based on messaging over the control channel
>    between the OXC and the WDM. This messaging
>    can be done one way or the other. 
> 
> 3. Both require control channel maintenance using
>    (simple) keepalive.
> 
> 4. It seems LMP-WDM can be streamlined to make it
>    more lean and mean. 
> 
> Unless there is a significant technical issue
> of one choice over the other, we have to consider
> the fact that LMP-WDM has the first mover advantage.
> Is it possible for
> the NTIP proponents to seriously consider working on
> (3)? Specifically, focus LMP-WDM on OLI requirements
> only and not carry any unrelated LMP concepts into
> LMP-WDM. Would this satisfy the design motivation for NTIP?
> 
> Regards,
> 
> Bala
> 
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: Andre Fredette [mailto:[email-masked]]
> > Sent: Thursday, July 26, 2001 2:52 PM
> > To: [email-masked]
> > Subject: RE: Optical Link Interface
> > 
> > 
> >  From my count on the mailing list we have the following 
> > results so far:
> > 
> > LMP-WDM:  8
> > NTIP: 3 (All from Nortel)
> > Agnostic: 1
> > 
> > And then there are the other 16 co-authors of LMP-WDM who 
> > haven't posted 
> > (perhaps because they don't think they have any new points to add).
> > 
> > Andre
> > 
> > At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> > >Kireeti,
> > >
> > >I have been following this thread with great interest. I 
> > agree with your
> > >conclusion that we should pick one protocol and move forward.
> > >
> > >You are talking about WG reaching a consensus. I cannot see 
> > how this is
> > >possible given the two very different views I see in the 
> latest email
> > >exchanges.
> > >
> > >How can we resolve the current dispute? What forum should we 
> > use to make
> > >a final decision on this?
> > >
> > >Martin
> > >
> > >-----Original Message-----
> > >From: Kireeti Kompella [mailto:[email-masked]]
> > >Sent: Wednesday, July 25, 2001 9:57 PM
> > >To: [email-masked]; [email-masked];
> > >[email-masked]
> > >Cc: [email-masked]; [email-masked];
> > >[email-masked]
> > >Subject: RE: Optical Link Interface
> > >
> > >
> > >Hi Osama,
> > >
> > > > Even though I don't think reviving CR-LDP and RSVP-TE 
> > history will get
> > >us
> > > > anywhere
> > >
> > >"Those who forget (ignore) history are doomed to repeat it."
> > >
> > >Yes, it makes for painful recollections.  We're living with the
> > >consequences now, though, and I don't want to again.
> > >
> > > > the existence of two protocols here have proven to be useful.
> > >
> > >That's not what I'm hearing, either from customers, or from the
> > >WG (admittedly, the sample is small).
> > >
> > >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> > >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> > >consensus is.  LMP-WDM and LMP works too.
> > >
> > >So: you've got the WG chairs (scarred and grumpy), the ADs
> > >and TA (speak up if I'm misrepresenting you), and customers
> > >saying, Pick one protocol and move forward.  Let's do that.
> > >And, please, as Vijay says, let's resolve this already.
> > >
> > >Kireeti.
> > 
> 

------_=_NextPart_000_01C116A1.18EB861E
Content-Type: text/plain;
	name="draft-sahay-ccamp-ntip-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-sahay-ccamp-ntip-01.txt"

CCAMP WG                                                       V. Sahay =

                                                           B. Narayanan =

Internet Draft                                             R. Ramaswami =

Document: draft-sahay-ccamp-ntip-01.txt                   O. Aboul-Magd =

                                                            B. Jamoussi =

                                                        Nortel Networks =

                                                                        =

                                                                R. Jain =

                                                         S. Dharanikota =

                                                         Nayna Networks =

                                                                        =

                                                             R. Hartani =

                                                       Caspian Networks =

                                                                        =

                                                              July 2001 =

=20
=20
        Network Transport Interface Protocol (NTIP) for Photonic =20
                          Cross Connects (PXC)=20
=20
=20
Status of this Memo=20
=20
   This document is an Internet-Draft and is in full conformance with=20
   all provisions of Section 10 of RFC2026 [1]. =20
=20
   Internet-Drafts are working documents of the Internet Engineering=20
   Task Force (IETF), its areas, and its working groups. Note that=20
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of=20
   six months and may be updated, replaced, or obsoleted by other=20
   documents at any time. It is inappropriate to use Internet- Drafts=20
   as reference material or to cite them other than as "work in=20
   progress." =20
   =20
   The list of current Internet-Drafts can be accessed at=20
   http://www.ietf.org/ietf/1id-abstracts.txt =20
   The list of Internet-Draft Shadow Directories can be accessed at=20
   http://www.ietf.org/shadow.html.=20
   =20
   =20
1. Abstract=20
   =20
   This draft describes the transport network interface protocol (NTIP) =

   for photonic cross connects (PXC). NTIP is implemented between a PXC =

   and transport network element (TNEs), also known as line systems.=20
   NTIP is a protocol that uses TCP/IP for the transport of information =

   related to defect notification, trace monitoring, adjacency=20
   discovery, and diagnostic messages between directly attached PXC and =

   TNE. The use of TCP as the transport protocol ensures reliable and=20
   in-sequence delivery of NTIP messages.=20
=20
2. Conventions used in this document=20
=20
 =20
Sahay                    Expires January 2002                        1=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in=20
   this document are to be interpreted as described in RFC-2119 [2].=20
   =20
   =20
3. Introduction=20
   =20
   Fast restoration of failed light paths is critical for PXCs and it=20
   requires support for fast and accurate failure detection. Most PXCs=20
   do not look into the optical signals that flow through them. Some=20
   can detect presence or loss of light on a port. However presence of=20
   light does not necessarily mean that the light path is fine. For=20
   example when a link fails, generators between the point of failure=20
   and the PXC may inject an alarm indication signal (AIS) on a light=20
   signal. Unless the PXC decodes the framing of the light signal=20
   (possibly using some electrical circuitry), AIS will appear as=20
   presence of light. Also, some of the DWDM equipment (also called=20
   Transport Network Elements in this document) can control the=20
   switching ON and OFF of the AIS by configuration (or on demand). =
This=20
   feature can be leveraged to the advantage of the faster fault=20
   detection and hence the recovery times.=20
   =20
   Unlike the PXC, the transport network elements (TNE) attached to it=20
   are aware of their equipment failure as well as the quality and=20
   framing of the light paths passing through them. Failure information =

   can be dynamically conveyed from the TNE to the PXC using out of=20
   band IP messaging.=20
   =20
   The transport network interface protocol (NTIP) defines the set of=20
   messages and the transport mechanism used for the exchange of=20
   failure conditions. NTIP is implemented between the PXC and the TNE. =

   NTIP is an IP message handshake transported over an IP network. The=20
   implementation of NTIP between TNE and PXC achieves the following=20
   goals:=20
   =20
   - Defect Notification: NTIP is used by the TNE to relay failure=20
     conditions and precise link, fiber, and equipment status=20
     notification to PXC. Defect reporting can be both event-driven=20
     (e.g., link failures), polling-driven (e.g., regular link sanity=20
     checks) or time-driven (e.g., periodic).=20
   =20
   - Trace Monitoring: A PXC can use NTIP to request a TNE to monitor a =

     certain pattern in the overhead of a light path. This capability=20
     could be used by PXC for validating light path identity.=20
   =20
   - Diagnostics: NTIP could be used by OXC to request a TNE to perform =

     diagnostics on any port or channel.=20
   =20
   - Adjacency Discovery: NTIP could be used by both PXC and TNE to=20
     send and receive in band signals for automatic discovery of their=20
     optical connectivity.=20
=20

 =20
Sahay                    Expires January 2002                        2=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   This draft describes NTIP procedures and messages to achieve its=20
   design goals.=20
   =20
4. Reference Model=20
   =20
   The current generation of PXCs will interoperate with opaque line=20
   systems such as SONET regenerators, wavelength translators, etc.=20
   Eventually when enough transparent line systems are deployed, PXCs=20
   will interwork with them leading to an all optical network (AON).=20
   The need for NTIP exists in both cases. The following reference=20
   model focuses on interoperation of PXCs with opaque line systems.=20
   =20
   A reference model is shown in Figure 1. TNE are used to connect PXC=20
   ports to the transport system. TNE could be a set of OEO devices=20
   followed by a DWDM mux as shown in Figure 1. A TNE regenerates the=20
   signal coming from the PXC and might be capable of translating the=20
   wavelength. The key features of a TNE in the reference model are its =

   ability to detect defects on its ports and to communicate defect=20
   information back to the PXC using NTIP.=20
   =20
                Drop    Line=20
                Side    side=20
                 |      |=20
                 |      |=20
      +---------+|  TNE | |\                /|   TNE   +---------+=20
      |     +---|V +---+V | \              / |  +---+  |---+     |=20
      |     |Por|->|   |->|  \            /  |<-|   |<-|Por|     |=20
      |     |  t|  |---|  |   \          /   |  |---|  |  t|     |=20
      |     |   |<-|   |<-|    \        /    |->|   |->|   |     | =20
      |     +---|  +---+  |     \=3D=3D=3D=3D=3D>/     |  +---+  |---+  =
   |=20
      |         |         |     /<=3D=3D=3D=3D=3D\     |         |     =
PXC |=20
      | PXC +---|  +---+  |    /        \    |  +---+  |---+     |=20
      |     |Por|->|   |->|   /          \   |<-|   |<-|Por|     |=20
      |     |  t|  |---|  |  /            \  |  |---|  |  t|     |=20
      |     |   |<-|   |<-| /  DWDM MUX    \ |->|   |->|   |     |=20
      |     +---|  +---+  |/                \|  +---+  |---+     |=20
      |=3D=3D=3D=3D=3D=3D=3D=3D=3D|                                     =
 |=3D=3D=3D=3D=3D=3D=3D=3D=3D|=20
      |controlle|  +=3D=3D=3D+                        +=3D=3D=3D+  =
|controlle|=20
      | r       |<>|   |                        |   |<>| r       |=20
      +---------+^ +=3D=3D=3D+                        +=3D=3D=3D+ =
^+---------+=20
                 |  TNE                          TNE  |=20
                 | controller             controller  |=20
               NTIP                                   NTIP=20
   =20
   PXC =3D Photonic CrossConnect        TNE =3D Transport Network =
Element=20
   TX =3D Transmit                      RX =3D Receive=20
   =20
               FIGURE 1: PXC to TNE Reference Configuration=20
   =20
   Each PXC port consists of two unidirectional fibers, one for input=20
   (RX) and one for output (TX). Four TNE ports are associated with=20
   each PXC port (RX and TX). The TNE port that is connected to PXC is=20
   referred to as drop-side port, and the one that is connected to the=20
 =20
Sahay                    Expires January 2002                        3=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   line is called the line-side port. Figure 1 shows that a PXC will=20
   communicate with several TNEs. On the other hand, a TNE only=20
   communicates with a single PXC.=20
   =20
   A TNE can detect failures on signals it receives. Additionally some=20
   TNEs may be able to detect certain failures on their output ports=20
   such as laser failure. =20
   =20
5. NTIP Overview=20
   =20
5.1 Configuration=20
   =20
   Whenever automatic discovery is not available, a PXC is provisioned=20
   with information on how its ports are connected to TNE. It is also=20
   provisioned with the primary and the secondary IP addresses of each=20
   TNE connected to it.=20
   =20
   NTIP defines a set of configurable parameters such as protocol=20
   timers, retry counts, etc. Those parameters could be assigned=20
   default values or allowed to be set as needed or negotiated.=20
   =20
5.2 Registration=20
   =20
   As a TNE starts up, it registers with the PXC whose address is=20
   configured in it. A TNE registers by opening a TCP session with the=20
   PXC, and sending a registration request message. TNE registration=20
   allows PXC to create its internal context structure for this=20
   particular TNE.=20
   =20
5.3 Keep Alive=20
   =20
   NTIP utilizes keep alive messages. Keep alive messages are exchanged =

   periodically between TNE and PXC to verify the sanity of the=20
   connection. The keep alive message interval is a configurable=20
   parameter.=20
   =20
5.4 Automatic Discovery=20
   =20
   A PXC might have hundreds or even thousands of ports. Manual entries =

   of port adjacency between PXC and TNEs connected to it is tedious=20
   and error prone. Furthermore manual entry has to be repeated every=20
   time there is change in adjacency due to, for instance, re-cabling.=20
   =20
   One application of the NTIP interface is for use in automatic=20
   adjacency discovery between PXC and TNEs. For that purpose it is=20
   assumed that the TNE is aware of its ports mapping, i.e. the mapping =

   between its drop side TX and RX ports, and its line side ports. This =

   mapping is mad available using NTIP to the auto discovery process=20
   (ADP). =20
   =20
   The TNE drop side port is supposed to operate in one of two modes,=20
   Pass-through and Insert. In the Insert mode the drop side TX inserts =

   an identity pattern into the signal overhead, e.g. J0. The PXC is=20
 =20
Sahay                    Expires January 2002                        4=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   made aware of the TNE port identity patterns over the NTIP interface =

   using a MappingTable message. In the Pass-through mode, the TNE drop =

   side TX passes the signal without modification.=20
   =20
   The auto discovery process starts with the PXC port establishing a=20
   cross connect to a well-known Test RX as shown in Figure 2. The PXC=20
   then sends a ModeSwitch message to the TNE to switch the TNE drop=20
   side TX mode to the Insert mode. The TNE starts inserting its=20
   identity pattern (could be a system wide unique id or a trail trace=20
   id). =20
   =20
                 +-------------+     +----+----+=20
                 |             |---->| RX | TX |--->=20
                 |             |     +----+----+=20
                 |    PXC      |=20
                 |             |     +----+----+=20
                 |             |<----| TX | RX |<---=20
                 |             |     +----+----+=20
                 +-------------+=20
                   |       ^    <--  NTIP-->=20
                   |       |=20
                   V       |=20
                 +---+   +---+=20
                 |   |   |   |=20
                 +---+   +---+=20
   =20
                  Test    Test=20
                   RX      TX=20
   =20
                  Figure 2: Auto Discovery Configuration=20
   =20
   The Test RX is requested to report the Identity message it sees. The =

   ADP maps the identity message to the drop side TX port id and the=20
   PXC port id. To verify mapping, the Test TX is requested to send the =

   same identity pattern to the TNE drop side RX over NTIP using the=20
   discovered PXC port. The TNE drop side RX verify the received=20
   identity pattern and reports match pr mismatch.=20
   =20
   The Test TX/RX could be internal or external to the PXC. In the case =

   of external Test TX/RX, communication would be done over NTIP=20
   interface.=20
   =20
   The procedure for auto-discovery is also applicable for link=20
   verification.=20
=20
5.5 Defect Monitoring=20
   =20
   Defect monitoring is initiated by the PXC by telling the TNE which=20
   ports to monitor for defects (signal degradation, loss of light,=20
   etc.). Defect monitoring will be initiated by the PXC after setting=20
   a light path through a TNE port. PXC terminates defect monitoring on =

   a port before it disconnects the light path on that port.=20
   =20
 =20
Sahay                    Expires January 2002                        5=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
5.6 Trace Monitoring=20
   =20
   Trace monitoring ensures that a light path is connected to the=20
   correct client. A trace (light path Id) is injected by the client in =

   the light path. After setting up a light path, PXC will request TNE=20
   to match the supplied trace id with that in the light path. The TNE=20
   informs the PXC in case of a mismatch. =20
   =20
   Trace Id is a pattern that can be injected and monitored in a light=20
   path without affecting its payload. A few different alternative ways =

   of implementing it are possible. Trace Id may be injected in wrapper =

   or as a pilot tone. NTIP supports all of them.=20
   =20
   The PXC discontinue the trace monitoring process for a particular=20
   light path before deleting it.=20
   =20
5.7 Status Request/Response=20
   =20
   Status request is initiated by the PXC and is triggered by an NTIP=20
   user application, e.g. NMS. Status response contains the status of=20
   the requested to TNE ports. It is sent by the TNE in response to=20
   status request.=20
   =20
5.8 Batching of Messages=20
   =20
   To reduce message traffic, TNE can pack several defect notification=20
   messages into a single message. Latency could be experienced as a=20
   result of batching since TNE has to hold off sending defects for an=20
   amount of time necessary to collect enough defects.=20
   =20
5.9 Resynchronization=20
   =20
   Resynchronization is needed every time an NTIP session restarts. An=20
   NTIP session could restart due to TCP connection failure, PXC=20
   restart due to internal reasons, e.g. control plan restart or PXC=20
   restart, TNE restart, or as a result of a deletion of the NTIP=20
   session due to time out.=20
   =20
   Each TNE keeps track of its NTIP session. If the session is deleted, =

   it attempts to create another session over TCP/IP periodically. The=20
   time it waits before initiating a second attempt is a configurable=20
   parameter.=20
   =20
   Once TNE succeeds in creating a TCP connection with PXC, it repeats=20
   the registration procedure as mentioned in section 5.2. Upon=20
   receiving the registration request, the PXC goes into a=20
   resynchronization phase requesting an update on the port status of=20
   all TNE ports that it is interested in. The PXC confirms the end of=20
   the synchronization phase to the TNE when it receives the status of=20
   all the requested ports.=20
   =20
   Resynchronization helps the reporting of failure events that would=20
   have been missed by the PXC due to the NTIP session being down. It=20
 =20
Sahay                    Expires January 2002                        6=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   also allows the TNE not to remember the defects monitoring commands=20
   given before resynchronization.=20
   =20
5.10 TNE to PXC Transport=20
   =20
   A single high availability router/switch is recommended for=20
   connecting TNE to PXC. This transport arrangement is referred to as=20
   NTIP transport network. TNE defect messages are required to reach=20
   the PXC with little delays. It is recommended that the NTIP network=20
   supports the priority handling of packets, e.g. differentiated=20
   services. Messages related to defect reporting are transported with=20
   high priority. All other messages, that are not time critical, are=20
   transported using a lower priority.=20
   =20
   NTIP messages are transported reliably using TCP as the transport=20
   protocol. The use of TCP also ensures in-sequence delivery of NTIP=20
   messages, hence relieving the protocol developer from creating an=20
   additional layer for reliable delivery.=20
   =20
   Figure 3 shows the logical connectivity between PXC and TNE.=20
   =20
                     +-----+                             +-----+=20
                     |     |   +--------------+          +----+   |=20
                     |     |   |             |-------+----+ |--+=20
                     | PXC |---|  IP Network |-------|    |-+=20
                     |     |   |             |       +----+=20
                     |     |   +-------------+         TNEs=20
                     +-----+  =20
                        |<---------------------------->|=20
                               TCP Session                       =20
   =20
                  FIGURE 3: PXC-TNE Logical Connectivity=20
                                     =20
   Figure 3 emphasizes the fact that a PXC communicates with several=20
   TNEs while a TNE only communicates with a single PXC.=20
   =20
5.11 Defect Types=20
=20
   A TNE will report the following defects to PXC. =20
   =20
   - Signal Degrade (SD): TNE reports this type of failure when the=20
     light signal on one of its ports degrades below a configured=20
     threshold.=20
   =20
   - Signal Fails (SF): TNE reports SF to PXC when the incoming signal=20
     fails on one of its ports.=20
   =20
   - AIS: TNE reports AIS to PXC when it detects AIS-LINE on one of its =

     ports.=20
   =20
   - Trace Mismatch: TNE reports Trace Mismatch when it mismatch is=20
     detected by one of its ports between an injected pattern and the=20
     expected pattern.=20
 =20
Sahay                    Expires January 2002                        7=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   =20
   - Equipment Failure: TNE will notify PXC of equipment failure (e.g.=20
     OEO card or laser failure on the transport side) and the port=20
     number that suffered the failure.=20
   =20
6.0 NTIP and OLI Requirements=20
   =20
   The requirements for the interface between PXC and the line system,=20
   denoted as OLI (Optical Link Interface), have been discusses in [3]. =

   Most of those requirements have been taken from the earlier version=20
   of this draft that was presented back in March during the IETF 50=20
   meeting. In this section we discuss how far NTIP satisfies those=20
   requirements.=20
   =20
6.1 General OLI Characteristics=20
=20
   General OLI requirements are reliabile, secure, and simple. NTIP=20
   meets the reliability and security requirements by employing TCP as=20
   its transport mechanism. TCP provide reliable and orderly=20
   transmission of NTIP messages. Furthermore it provides a flow=20
   control mechanism that allows for bulk transmission of NTIP=20
   messages. The TCP window mechanism paces messages for cases where=20
   the traffic volume increase for instance due to, for instance, re-
   synchronization.=20
   =20
   Line systems (TNEs) do not usually have much memory, and can only=20
   keep a limited amount of state. NTIP achieves simplicity by=20
   establishing a master-slave, as opposed to peer, relationship=20
   between the PXC and TNEs. This minimizes the amount of states kept=20
   at the TNE and makes efficient used of the limited memory available. =

   =20
6.2 OLI Functionality=20
   =20
   OLI basic functionality as defined in [3] are: neighbor discovery,=20
   control channel maintenance, re-synchronization, connectivity=20
   discovery, fault management, and link property information.=20
   =20
   Neighbor discovery and control channel maintenance are achieved in=20
   NTIP by means of a simple registration and keep alive procedures. =20
   =20
   Connectivity discovery has been discussed in section 5.4. It allows=20
   for the automatic discovery and mapping between PXC ports and TNE=20
   ports.=20
   =20
   Fault management and re-synchronization have always been the main=20
   focus of NTIP as discussed in a previous revision of this draft.=20
   Fault management includes fault notification and trace monitoring,=20
   both have originally been introduced in a previous revision of this=20
   draft. NTIP introduced the notion of priority handing of fault=20
   notification messages to expedite light path recovery and=20
   restoration in the order of few tens ms.=20
   =20

 =20
Sahay                    Expires January 2002                        8=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   Trace monitoring has ingeniously been introduced by NTIP and has=20
   been adopted as one of the main requirements of OLI. =20
   =20
   Most of the link property information, e.g. SRLG and span length can =

   be configured. If necessary they can be added to NTIP with minor=20
   modifications.=20
   =20
7.0 NTIP Messages and Procedures=20
   =20
   All NTIP messages start with the following two fields:=20
   =20
   NTIP Vers: =20
      2-byte field that contains the NTIP protocol version number.=20
   =20
   Type:=20
      2-byte field that contains the message type=20
   =20
   The version number provides the features supported by the other side =

   of the NTIP communication. It is only verified at the establishment=20
   of NTIP session, and is used during registration and=20
   resynchronization states. =20
   =20
7.1 Registration Message=20
   =20
   The format of the Registration Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      +                                                               + =

      |                                                               | =

      +                TNE Model Number                               + =

      |                                                               | =

      +                                                               + =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

=20

   Type:=20
     Type =3D REG-REQ =20
=20
   TNE Model Number:=20
     16-byte filed that specifies the TNE model number=20
   =20
   Procedure:=20
     Registration Message is sent by the TNE to the PXC at start up. If =

     a PXC receives a Registration Message with a different NTIP Vers=20
     than expected it may take one of the following actions:=20
   =20
     - Reject the registration request=20
     =20

 =20
Sahay                    Expires January 2002                        9=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
     - Reject the registration request if the received NTIP Vers =
differs=20
       by more than an allowed difference. If the difference is=20
       acceptable, then the message set common to the two versions will =

       be supported.=20
   =20
7.2 Registration Complete Message=20
   =20
   The format of the Registration Complete Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   Type:=20
     Type =3D REG-COMPLETE =20
=20
   Procedure:=20
     The Registration Complete Message is sent by PXC to TNE indicating =

     a successful completion of the registration. The message is sent=20
     only during the initial synchronization phase.=20
   =20
7.3 KeepAlive Message=20
   =20
   The format of the KeepAlive Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   Type: =20
     Type =3D KEEP-ALIVE-REQ =20
   =20
   Procedure:=20
   The KeepAlive Message is sent by the TNE to PXC every T-keep-alive-
   interval seconds (the default is 60 seconds). If PXC does not =
receive=20
   a KeepAlive Message every T-keep-alive-timeout (t-keep-alive-timeout =

   =3D 3*T-keep-alive-interval), it takes down the NTIP session.=20
   =20
7.4 KeepAlive Response Message=20
   =20
   The format of the KeepAlive Response Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   Type:=20
 =20
Sahay                    Expires January 2002                       10=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
     Type =3D KEEP-ALIVE_RES=20
   =20
   Procedure:=20
     The KeepAlive Response Message is sent by PXC to TNE in response =
to=20
     a KeepAlive Message.=20
   =20
7.5 Monitor Request Message=20
   =20
   The format of the Monitor Request Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |            Length             |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |        No. of Ports           |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |AR |DM | TType |MT | Tr Len    |       Reserved                | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                           Trace ID                            ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                                                               ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |AR |DM | TType |MT | Tr Len    |       Reserved                | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                           Trace ID                            ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
     =20
=20

   Type:=20
     Type =3D MON-REQ =20
   =20
   No. of Ports: =20
     2-byte field that contains the number of ports reported in this=20
     message.=20
   =20
   Port Address:=20
     4-byte field that is formatted as:=20
   =20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

 =20
Sahay                    Expires January 2002                       11=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
      |    shelf      |      slot     |    Sub Slot   |    port       | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   =20
   Alarm Reporting, AR:=20
     2-bit field that indicates start, stop, or no change to alarm=20
     reporting.=20
   =20
   Defect Monitoring, DM:=20
     2-bit field that indicates start, stop, or no change to failure=20
     monitoring.=20
   =20
   Trace Type, TType:=20
     4-bit used to indicate the trace type. Possible types are, pilot=20
     tone, wrapper, J0 bytes.=20
   =20
   Monitor of Trace, MT:=20
     2-bit field that indicates start, stop, or no change to trace=20
     monitoring=20
   =20
   Trace Length, Tr Len:=20
     6-bit field that indicates the length of the monitored trace.=20
   =20
   Trace ID:=20
     Up to 63 bytes. It defines the trace to be monitored. User could=20
     treat the Trace ID as ASCII or binary=20
   =20
   Procedure:=20
     The Monitor Request Message is sent by PXC to TNE. After setting a =

     light path through TNE, PXC will send Monitor Request Message=20
     indicating the start of defect monitoring and the list of =
monitored=20
     ports. Before disconnecting a light path, PXC sends Monitor =
Request=20
     Message with DM set to stop indicating the end of the defect=20
     monitoring process.=20
   =20
     The Monitor Request Message is also used for the start and the =
stop=20
     of alarm reporting and trace monitoring. Upon the start of trace=20
     monitoring, the PXC supplies the Trace ID to be compared to that =
in=20
     the light path (say, in SONET J0 bytes, or in wrapper, or pilot=20
     tone). Trace ID is not included in the Monitor Request Message =
when=20
     MT is set to stop or no change.=20
   =20
7.6 Defect Notification=20
   =20
   The format for the Defect Notification Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |            Length             |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

 =20
Sahay                    Expires January 2002                       12=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
      |        No. of Ports           |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  FS   |       FT      |       Reserved                        | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                                                               ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  FS   |       FT      |       Reserved                        | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   =20
   Type: =20
     Type =3D DEFECT-NOTIFICATION =20
   =20
   Failure Status, FS:=20
     2-bit field that indicates fail or clear.=20
   =20
   Failure Type, FT:=20
     1-byte filed that indicates the failure (defect) type as discussed =

     in section 5.10.=20
   =20
   Procedure:=20
     The Defect Notification Message is sent by the TNE in response to =
a=20
     PXC Monitor Request Message. The Defect Notification Message is=20
     sent with the highest possible priority to reach the destination=20
     PXC in a timely fashion.=20
   =20
7.7 Status Request Message=20
   =20
    The format of the Status Request Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |            Length             |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |        No. of Ports           |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | Tag   |                    Reserved                           | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                                                               ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

 =20
Sahay                    Expires January 2002                       13=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | Tag   |                    Reserved                           | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

=20
   =20
   Type:=20
     Type =3D STATUS-REQ =20
   =20
   Tag:=20
     A 4-bit field that is used for message identification=20
   =20
   Procedure:=20
     The Status Request Message is sent by PXC to TNE to solicit the=20
     status of some or all of the TNE ports. Status Request Message=20
     could also be sent to query the status of a previously issued=20
     Monitor Request Message.=20
   =20
7.8 Status Response Message=20
   =20
   The format of the Status Response Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |            Length             |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |        No. of Ports           |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | Tag   | CStat |    Dyn Stat   |   Reserved                    | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                                                               ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | Tag   | CStat |    Dyn Stat   |   Reserved                    | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

=20

   =20
   Type:=20
     Type =3D STATUS-RESP =20
   =20
   Configuration Status, CStat:=20
     4-bit field that indicates the provisioned state of a TNE port. It =

     indicates whether the port is enabled or disabled.=20
   =20
   Dynamic State, Dyn Stat:=20

 =20
Sahay                    Expires January 2002                       14=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
     1-byte field that indicates the failure type experience by a TNE=20
     port.=20
   =20
   Procedure:=20
     The Status Response Message is sent from TNE to PXC. A TNE sends a =

     Status Response Message in response to a Status Request Message.=20
     For each port requested, the Status Response Message includes a=20
     configuration status (enabled or disabled), and a dynamic port=20
     defect status that specify the failure type as discussed in=20
     section 5.10.=20
   =20
7.9 Configuration Update=20
   =20
   The format of the Configuration Update Message is:=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |     NTIP Vers                 |      Type                     | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |            Length             |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |        No. of Ports           |      Reserved                 | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |   CStat       |    Dyn Stat   |   Reserved                    | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                                                               | =

      ~                                                               ~ =

      |                                                               | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |                         Port Address                          | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |   CStat       |    Dyn Stat   |   Reserved                    | =

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   =20
   Type: =20
     Type =3D CONFIG-UPDATE =20
   =20
   Procedure:=20
     The Configuration Update Message is sent unsolicited by TNE to=20
     PXC. It is used for dynamically modifying the configuration while=20
     in operation. =20
   =20
8. Security Considerations=20
=20
   This draft does not introduce any new security issues.=20
   =20
   =20
9. References=20
   =20

 =20
Sahay                    Expires January 2002                       15=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
=20
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20
      9, RFC 2026, October 1996.=20
   =20
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement=20
      Levels", BCP 14, RFC 2119, March 1997=20
   =20
   3  A. Fredette, Editor, =93 Optical Link Interface Requirements=94,=20
      draft-many-oli-reqts-00.txt, work in progress, June 2001=20
   =20
=20
   =20
   =20
=20
   =20
10. Author's Addresses=20
   =20
   Vasant Sahay=20
   Nortel Networks=20
   2305 Mission College Blvd=20
   Santa Clara, CA 95054, USA=20
   Phone: 408-565-4601=20
   E.mail: [email-masked]=20
   =20
   Rajiv Ramaswami=20
   Nortel Networks=20
   2305 Mission College Blvd=20
   Santa Clara, CA 95054, USA=20
   Phone: 408-565-4621=20
   Email: [email-masked]=20
   =20
   Babu Narayanan=20
   Nortel Networks=20
   2305 Mission College Blvd=20
   Santa Clara, CA 95054, USA=20
   Phone: 408-565-4537=20
   Email: [email-masked]=20
   =20
   =20
   Osama S. Aboul-Magd=20
   Nortel Networks=20
   P.O. Box 3511, Station C=20
   Ottawa, Ontario, Canada=20
   K1Y 4H7=20
   Phone: 613-763-5827=20
   Email: [email-masked]=20
   =20
   Bilel Jamoussi=20
   Nortel Networks=20
   600 Technology Park Drive=20
   Billerica, MA 01821, USA=20
   Phone: 978-288-4506=20
   Email: [email-masked]=20
 =20
Sahay                    Expires January 2002                       16=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   =20
   Raj Jain=20
   Nayna Networks, Inc.=20
   157 Topaz St=20
   Milpitas, CA 95035, USA=20
   Phone: 408-956-8000 Ext 309=20
   Email: [email-masked]=20
   =20
   Sudheer Dharanikota=20
   Nayna Networks, Inc.=20
   157 Topaz St=20
   Milpitas, CA 95035, USA=20
   Phone: 408-956-8000 Ext 357=20
   Email: [email-masked]=20
   =20
   Riad Hartani=20
   Caspian Networks=20
   170 Bytech Drive=20
   San Jose, CA 95134, USA=20
   Phone: 408-382-5216=20
   Email: [email-masked]=20
   =20
   =20
   =20

 =20
Sahay                    Expires January 2002                       17=20
=0C
Draft-sahay-ccamp-ntip-01.txt                                July 2001=20
=20
=20
   =20
Full Copyright Statement=20
=20

   "Copyright (C) The Internet Society (date). All Rights Reserved.=20
   This document and translations of it may be copied and furnished to=20
   others, and derivative works that comment on or otherwise explain it =

   or assist in its implmentation may be prepared, copied, published=20
   and distributed, in whole or in part, without restriction of any=20
   kind, provided that the above copyright notice and this paragraph=20
   are included on all such copies and derivative works. However, this=20
   document itself may not be modified in any way, such as by removing=20
   the copyright notice or references to the Internet Society or other=20
   Internet organizations, except as needed for the purpose of=20
   developing Internet standards in which case the procedures for=20
   copyrights defined in the Internet Standards process must be=20
   followed, or as required to translate it into=20

 =20
Sahay                    Expires January 2002                       18=20
=0C
------_=_NextPart_000_01C116A1.18EB861E--

Delivery-date: Fri, 27 Jul 2001 06:28:40 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Andre Fredette'" <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Fri, 27 Jul 2001 09:27:59 -0400

Andre:

I believe you're counting me in the "agnostic" category.
I hope this is not taken as "don't care", since I
do have an interest in making a choice quickly.

I have looked at the LMP-WDM draft (again) and the new
NTIP draft sent by Osama (attached). I see the following:

1. Both these solutions gloss over the details of
   auto-discovery between OXCs and WDM. (Note: the
   issues are the same regardless of the protocol used
   and neither provides full details. Furthermore,
   the hardware requirements and actions under both 
   are the same).

2. If we leave out (1), then the other functions are
   based on messaging over the control channel
   between the OXC and the WDM. This messaging
   can be done one way or the other. 

3. Both require control channel maintenance using
   (simple) keepalive.

4. It seems LMP-WDM can be streamlined to make it
   more lean and mean. 

Unless there is a significant technical issue
of one choice over the other, we have to consider
the fact that LMP-WDM has the first mover advantage.
Is it possible for
the NTIP proponents to seriously consider working on
(3)? Specifically, focus LMP-WDM on OLI requirements
only and not carry any unrelated LMP concepts into
LMP-WDM. Would this satisfy the design motivation for NTIP?

Regards,

Bala

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Andre Fredette [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 2:52 PM
> To: [email-masked]
> Subject: RE: Optical Link Interface
> 
> 
>  From my count on the mailing list we have the following 
> results so far:
> 
> LMP-WDM:  8
> NTIP: 3 (All from Nortel)
> Agnostic: 1
> 
> And then there are the other 16 co-authors of LMP-WDM who 
> haven't posted 
> (perhaps because they don't think they have any new points to add).
> 
> Andre
> 
> At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
> >Kireeti,
> >
> >I have been following this thread with great interest. I 
> agree with your
> >conclusion that we should pick one protocol and move forward.
> >
> >You are talking about WG reaching a consensus. I cannot see 
> how this is
> >possible given the two very different views I see in the latest email
> >exchanges.
> >
> >How can we resolve the current dispute? What forum should we 
> use to make
> >a final decision on this?
> >
> >Martin
> >
> >-----Original Message-----
> >From: Kireeti Kompella [mailto:[email-masked]]
> >Sent: Wednesday, July 25, 2001 9:57 PM
> >To: [email-masked]; [email-masked];
> >[email-masked]
> >Cc: [email-masked]; [email-masked];
> >[email-masked]
> >Subject: RE: Optical Link Interface
> >
> >
> >Hi Osama,
> >
> > > Even though I don't think reviving CR-LDP and RSVP-TE 
> history will get
> >us
> > > anywhere
> >
> >"Those who forget (ignore) history are doomed to repeat it."
> >
> >Yes, it makes for painful recollections.  We're living with the
> >consequences now, though, and I don't want to again.
> >
> > > the existence of two protocols here have proven to be useful.
> >
> >That's not what I'm hearing, either from customers, or from the
> >WG (admittedly, the sample is small).
> >
> >Listen carefully: I don't want LMP-WDM and NTIP moving forward.
> >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
> >consensus is.  LMP-WDM and LMP works too.
> >
> >So: you've got the WG chairs (scarred and grumpy), the ADs
> >and TA (speak up if I'm misrepresenting you), and customers
> >saying, Pick one protocol and move forward.  Let's do that.
> >And, please, as Vijay says, let's resolve this already.
> >
> >Kireeti.
> 

Delivery-date: Fri, 27 Jul 2001 02:32:19 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: "'Lou Berger'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: new gmpls signaling drafts
Date: Fri, 27 Jul 2001 11:18:38 +0200

Lou,

You wrote:

> New versions of the GMPLS signaling drafts have been submitted. We 
> attempted to cover the major last call issues. For those who don't want to wait, 
> the drafts are available at: 

> http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt 
> http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt 
> http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt 

Would it be possible to somehow summarize the issues that were considered 
when writing these new drafts and how these issues have been dealt with?   
That would be very helpful.

Thanks a lot.

Leen Mak.

Delivery-date: Thu, 26 Jul 2001 14:02:21 -0700
Date: Thu, 26 Jul 2001 22:59:57 +0200
From: Loa Andersson <[email-masked]>
To: Martin Dubuc <[email-masked]>
CC: Andre Fredette <[email-masked]>, [email-masked]
Subject: Re: Optical Link Interface

All,

second (or maybe third) in motion. I think Andre's proposal has a
very solid foundation. As I understand it even the people proposing
NTIP,
do so based on the argument that two protocols are better than one.
Somestimes even quoting "(I)SP's" wanting this.

Speaking as an operator I can't find any reason to complicate our
network
with two protocols (even though marginally different) that give me the 
same thing. For the very same reason that we won't deploy CR-LDP, we 
won't deploy a second optical link interface protocol. The only chance
that we will deploy NTIP is that it will be the one and only pick by
CCAMP, and I can't see that happen. 

Let's go for LMP-WDM and let's stop the standardization process for 
alternatives.

/Loa

Martin Dubuc wrote:
> 
> I support your proposal.
> 
> Martin
> 
> -----Original Message-----
> From: Andre Fredette [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 10:01 PM
> To: [email-masked]
> Subject: Optical Link Interface
> 
> Last month, the "Optical Link Interface (OLI) Requirements" document
> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
> was discussed on the ccamp mailing list and achieved "rough consensus"
> according to our working group co-chairs.  Given this, we'd like to make
> some progress on the protocol specification.  I'd like to generate some
> discussion on this mailing list before the IETF meeting in London
> because
> meaningful technical discussion cannot occur in the time allocated
> during
> the meeting.
> 
> There have been two proposals in the IETF to satisfy the OLI
> requirements:
> 
> 1. [LMP-WDM]:
> "Link Management Protocol (LMP) for DWDM Optical Line Systems"
> http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
> (note, this updated document was submitted Friday, so it should show up
> on the official website soon).
> 
> and
> 
> 2. [NTIP]:
> "Network Transport Interface Protocol (NTIP) for Photonic Cross
> Connects"
> (PXC)
> http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
> 
> LMP-WDM proposes extensions to LMP to satisfy the OLI requirements,
> while
> NTIP proposes a new protocol.  We believe that the LMP approach is best
> because:
> 
> 1. [LMP-WDM] satisfies the OLI Requirements.
> 
> 2. The extensions to LMP are quite natural and fit within the spirit of
> the
> LMP protocol.
> 
> 3. LMP is a reasonably mature IETF protocol specification:
>      - It has been in the works for well over a year.
>      - It is an official working group document.
> 
> 4. It is better to have one protocol, than two for a given function
> (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)
> 
> 5. Using the same protocol simplifies both implementation and management
> on
> devices, such as optical cross-connects and routers, that may need to
> use
> both simultaneously.
> 
> While there is no doubt in my mind that NTIP could be made to satisfy
> the
> OLI requirements, It is my strong opinion that LMP should be the
> solution
> chosen by the CCAMP working group due to the reasons outlined above.
> 
> Comments please!
> 
> Regards,
> Andre

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Thu, 26 Jul 2001 12:18:22 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Explicit Label Control
Date: Thu, 26 Jul 2001 12:15:15 -0700

Hi All,

In GMPLS and O-UNI drafts, the concept of Egress/explicit Label control is 
described. Is this valid only at egress or intermediate nodes also ? I have 
gone through both the GMPLS and O-UNI drafts. The O-UNI draft clearly 
describes it as Egress Label i.e. label to be used at destination UNI. But 
GMPLS describes the term Explicit Label object. The GMPLS draft mentions 
that the explicit label subobject can be present anywhere (as per my 
understanding) in ERO provided that this sub-object should follow a 
subobject containing the IP address or interface identifier (strict object).
I mean to say whether the Explicit Label object will only be at the
end of ERO or it can appear in between in case of GMPLS ?

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 26 Jul 2001 11:53:34 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Date: Thu, 26 Jul 2001 14:52:23 -0400
Subject: RE: Optical Link Interface

 From my count on the mailing list we have the following results so far:

LMP-WDM:  8
NTIP: 3 (All from Nortel)
Agnostic: 1

And then there are the other 16 co-authors of LMP-WDM who haven't posted 
(perhaps because they don't think they have any new points to add).

Andre

At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
>Kireeti,
>
>I have been following this thread with great interest. I agree with your
>conclusion that we should pick one protocol and move forward.
>
>You are talking about WG reaching a consensus. I cannot see how this is
>possible given the two very different views I see in the latest email
>exchanges.
>
>How can we resolve the current dispute? What forum should we use to make
>a final decision on this?
>
>Martin
>
>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: Optical Link Interface
>
>
>Hi Osama,
>
> > Even though I don't think reviving CR-LDP and RSVP-TE history will get
>us
> > anywhere
>
>"Those who forget (ignore) history are doomed to repeat it."
>
>Yes, it makes for painful recollections.  We're living with the
>consequences now, though, and I don't want to again.
>
> > the existence of two protocols here have proven to be useful.
>
>That's not what I'm hearing, either from customers, or from the
>WG (admittedly, the sample is small).
>
>Listen carefully: I don't want LMP-WDM and NTIP moving forward.
>Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
>consensus is.  LMP-WDM and LMP works too.
>
>So: you've got the WG chairs (scarred and grumpy), the ADs
>and TA (speak up if I'm misrepresenting you), and customers
>saying, Pick one protocol and move forward.  Let's do that.
>And, please, as Vijay says, let's resolve this already.
>
>Kireeti.

Delivery-date: Thu, 26 Jul 2001 11:48:35 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Subject: RE: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt
Date: Thu, 26 Jul 2001 11:47:48 -0700

Manoj,

As stated in my previous email,
please check the latest version of the OSPF routing enhancements
draft (which should show up on the IETF drafts directory sometime
this week, or early next week) titled
draft-kompella-ospf-gmpls-extensions-02.txt 

This is the latest version of the draft you are looking at, and
is more complete than the one you are reading.

-Vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of manoj juneja
Sent: Thursday, July 26, 2001 11:34 AM
To: [email-masked]
Subject: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt

Hi All,
        I have a doubt regarding draft-kompella-ospf-gmpls-extensions
-01.txt. Section 4.1 of this document states that "control channels
are advertised into OSPF as normal IS links as mentioned in the
previous section".
First, What is the need for advertising control channel information in
OSPF ? I can very well find the control channel once I get the
information about the data channel/interface. There may be one-to-one
mapping of control channel and data channel/interface or multiple data
interfaces share the same control channel.

Second, in the above quoted sentence, I could not find the previous
section (prior to section 4.1) in the draft where the information
regarding control channels is described.

Is this the latest draft ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 26 Jul 2001 11:46:43 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: RE: {SUKLM} numbering scheme
Date: Thu, 26 Jul 2001 11:45:46 -0700

Manoj,

Please check the latest version of the OSPF routing enhancements
draft (which should show up on the IETF drafts directory sometime
this week, or early next week) titled
draft-kompella-ospf-gmpls-extensions-02.txt

and check the "Interface Switching Capability Descriptor"

-Vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of manoj juneja
Sent: Thursday, July 26, 2001 11:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Fwd: RE: {SUKLM} numbering scheme

Hi Lou,
        In the latest GMPLS draft(draft-ietf-mpls-generalized
-signalling-05.txt), Generalized Label Request object has been
modified. Now, It consists of fields LSP encoding type, G-PID and
switching type (newly added field). The reference to draft-kompella
-ospf-gmpls-extensions-02.txt has been made for the description of
switching type field. The latest document that I can found regarding
GMPLS extensions to ospf is draft-kompella-ospf-gmpls-extensions-01.txt
and this document doesn't mention about switching type. Please clarify
where to look for the description of this field.

Regards,
manoj.

>From: Lou Berger <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: [email-masked],[email-masked],[email-masked]
>Subject: Re: Fwd: RE: {SUKLM} numbering scheme
>Date: Thu, 26 Jul 2001 10:22:28 -0400
>
>Thank you for catching this.
>
>Lou
>
>At 09:26 PM 7/25/01, manoj juneja wrote:
>>Hi Eric and Lou,
>>                   The new GMPLS signalling drafts still distinguish
>>between different SDH and SONET version of specifications (like 2000,
>>1995 etc.). Eric, As u said earlier that we will be having only one
>>value for SDH and one for SONET LSP encoding type. please see the mail
>>below for further information. I want to know that whether this has been
>>done intentionally or it is just a bug that still need to be removed.
>>
>>Please clarify.
>>
>>Regards,
>>manoj.
>>>
>>>
>>>
>>>
>>>>From: "Mannie, Eric" <[email-masked]>
>>>>To: 'manoj juneja' <[email-masked]>, [email-masked]
>>>>CC: "[email-masked]'" <[email-masked]>
>>>>Subject: RE: {SUKLM} numbering scheme
>>>>Date: Thu, 28 Jun 2001 21:38:10 +0200
>>>>
>>>>Hello Manoj,
>>>>
>>>>The label is the same of course.
>>>>
>>>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is
>>>>a
>>>>small bug coming from an old version. That should be removed by Lou. We
>>>>should have only one SDH LSP encoding type value for SDH (same for
>>>>SONET).
>>>>
>>>>Lou: thanks to correct it.
>>>>
>>>>For the conversion table, Maarten should still have it.
>>>>
>>>>Kind regards,
>>>>
>>>>Eric
>>>>
>>>>-----Original Message-----
>>>>From: manoj juneja [mailto:[email-masked]]
>>>>Sent: Thursday, June 28, 2001 8:28 PM
>>>>To: [email-masked]
>>>>Subject: {SUKLM} numbering scheme
>>>>
>>>>
>>>>Hi All,
>>>>           I have a doubt regarding {SUKLM} numbering scheme. If I
>>>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
>>>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
>>>>ITU-T G.707 2000 ?
>>>>
>>>>Eric, on the ipo u and marteen once exchanged the conversion table for
>>>>EDCBA and SU, If that table is correct, can u please tell me the
>>>>formula from which u derived that table ?
>>>>
>>>>Regards,
>>>>manoj.
>>>>
>>>>
>>>>_________________________________________________________________
>>>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>>>>
>>>
>>>
>>>_________________________________________________________________
>>>Get your FREE download of MSN Explorer at
>>>http://explorer.msn.com/intl.asp
>>>
>>
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 26 Jul 2001 11:35:17 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt
Date: Thu, 26 Jul 2001 11:34:03 -0700

Hi All,
        I have a doubt regarding draft-kompella-ospf-gmpls-extensions
-01.txt. Section 4.1 of this document states that "control channels
are advertised into OSPF as normal IS links as mentioned in the
previous section".
First, What is the need for advertising control channel information in
OSPF ? I can very well find the control channel once I get the
information about the data channel/interface. There may be one-to-one
mapping of control channel and data channel/interface or multiple data
interfaces share the same control channel.

Second, in the above quoted sentence, I could not find the previous
section (prior to section 4.1) in the draft where the information
regarding control channels is described.

Is this the latest draft ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 26 Jul 2001 11:25:21 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Fwd: RE: {SUKLM} numbering scheme
Date: Thu, 26 Jul 2001 11:23:36 -0700

Hi Lou,
        In the latest GMPLS draft(draft-ietf-mpls-generalized
-signalling-05.txt), Generalized Label Request object has been
modified. Now, It consists of fields LSP encoding type, G-PID and
switching type (newly added field). The reference to draft-kompella
-ospf-gmpls-extensions-02.txt has been made for the description of
switching type field. The latest document that I can found regarding
GMPLS extensions to ospf is draft-kompella-ospf-gmpls-extensions-01.txt
and this document doesn't mention about switching type. Please clarify
where to look for the description of this field.

Regards,
manoj.

>From: Lou Berger <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: [email-masked],[email-masked],[email-masked]
>Subject: Re: Fwd: RE: {SUKLM} numbering scheme
>Date: Thu, 26 Jul 2001 10:22:28 -0400
>
>Thank you for catching this.
>
>Lou
>
>At 09:26 PM 7/25/01, manoj juneja wrote:
>>Hi Eric and Lou,
>>                   The new GMPLS signalling drafts still distinguish
>>between different SDH and SONET version of specifications (like 2000,
>>1995 etc.). Eric, As u said earlier that we will be having only one
>>value for SDH and one for SONET LSP encoding type. please see the mail
>>below for further information. I want to know that whether this has been
>>done intentionally or it is just a bug that still need to be removed.
>>
>>Please clarify.
>>
>>Regards,
>>manoj.
>>>
>>>
>>>
>>>
>>>>From: "Mannie, Eric" <[email-masked]>
>>>>To: 'manoj juneja' <[email-masked]>, [email-masked]
>>>>CC: "[email-masked]'" <[email-masked]>
>>>>Subject: RE: {SUKLM} numbering scheme
>>>>Date: Thu, 28 Jun 2001 21:38:10 +0200
>>>>
>>>>Hello Manoj,
>>>>
>>>>The label is the same of course.
>>>>
>>>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is 
>>>>a
>>>>small bug coming from an old version. That should be removed by Lou. We
>>>>should have only one SDH LSP encoding type value for SDH (same for 
>>>>SONET).
>>>>
>>>>Lou: thanks to correct it.
>>>>
>>>>For the conversion table, Maarten should still have it.
>>>>
>>>>Kind regards,
>>>>
>>>>Eric
>>>>
>>>>-----Original Message-----
>>>>From: manoj juneja [mailto:[email-masked]]
>>>>Sent: Thursday, June 28, 2001 8:28 PM
>>>>To: [email-masked]
>>>>Subject: {SUKLM} numbering scheme
>>>>
>>>>
>>>>Hi All,
>>>>           I have a doubt regarding {SUKLM} numbering scheme. If I
>>>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
>>>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
>>>>ITU-T G.707 2000 ?
>>>>
>>>>Eric, on the ipo u and marteen once exchanged the conversion table for
>>>>EDCBA and SU, If that table is correct, can u please tell me the
>>>>formula from which u derived that table ?
>>>>
>>>>Regards,
>>>>manoj.
>>>>
>>>>
>>>>_________________________________________________________________
>>>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>>>>
>>>
>>>
>>>_________________________________________________________________
>>>Get your FREE download of MSN Explorer at 
>>>http://explorer.msn.com/intl.asp
>>>
>>
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Thu, 26 Jul 2001 11:03:23 -0700
content-class: urn:content-classes:message
Subject: RE: Optical Link Interface
Date:  Thu, 26 Jul 2001 14:02:25 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Andre Fredette" <[email-masked]>
Cc: <[email-masked]>

I support your proposal.

Martin

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Monday, July 23, 2001 10:01 PM
To: [email-masked]
Subject: Optical Link Interface

Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London
because
meaningful technical discussion cannot occur in the time allocated
during
the meeting.

There have been two proposals in the IETF to satisfy the OLI
requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross
Connects"
(PXC)
http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt

LMP-WDM proposes extensions to LMP to satisfy the OLI requirements,
while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:

1. [LMP-WDM] satisfies the OLI Requirements.

2. The extensions to LMP are quite natural and fit within the spirit of
the
LMP protocol.

3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.

4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)

5. Using the same protocol simplifies both implementation and management
on
devices, such as optical cross-connects and routers, that may need to
use
both simultaneously.

While there is no doubt in my mind that NTIP could be made to satisfy
the
OLI requirements, It is my strong opinion that LMP should be the
solution
chosen by the CCAMP working group due to the reasons outlined above.

Comments please!

Regards,
Andre

Delivery-date: Thu, 26 Jul 2001 11:02:02 -0700
content-class: urn:content-classes:message
Subject: RE: Optical Link Interface
Date:  Thu, 26 Jul 2001 14:00:14 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Kireeti,

I have been following this thread with great interest. I agree with your
conclusion that we should pick one protocol and move forward.

You are talking about WG reaching a consensus. I cannot see how this is
possible given the two very different views I see in the latest email
exchanges.

How can we resolve the current dispute? What forum should we use to make
a final decision on this?

Martin

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 9:57 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Optical Link Interface

Hi Osama,

> Even though I don't think reviving CR-LDP and RSVP-TE history will get
us
> anywhere

"Those who forget (ignore) history are doomed to repeat it."

Yes, it makes for painful recollections.  We're living with the
consequences now, though, and I don't want to again.

> the existence of two protocols here have proven to be useful.

That's not what I'm hearing, either from customers, or from the
WG (admittedly, the sample is small).

Listen carefully: I don't want LMP-WDM and NTIP moving forward.
Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
consensus is.  LMP-WDM and LMP works too.

So: you've got the WG chairs (scarred and grumpy), the ADs
and TA (speak up if I'm misrepresenting you), and customers
saying, Pick one protocol and move forward.  Let's do that.
And, please, as Vijay says, let's resolve this already.

Kireeti.

Delivery-date: Thu, 26 Jul 2001 10:56:01 -0700
Date: Thu, 26 Jul 2001 10:53:58 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: [email-masked]
CC: Martin Dubuc <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Queries regarding LMP.

Rajesh,

> >
> > Q3) Destination address can be multicast or any valid IP address of
> > destination node (most likely the NodeID of the destination node).
> 
> If it is the Node ID of the neighbour then how does one find it
> without manual configuration ?? Is it with the help of an IGP
> such as OSPF ? We would like to automate things as much as
> possible.

Initial Config message will go out on a multicast address. 
This makes it easy for initial communication.

All other messages will be addressed to Node ID. 
Section 9 of OIF2000.125.5. clairifies this issues. 

This may change again if Node ID is
not be a routable IP address. It should be really the source
IP address of the Config message to whom you should send
your LMP messages.

Thanks,
Suresh

> 
> If LMP is designed as an independent protocol then IMHO
> we should use a multicast address.
> 
> Regds,
> - Rajesh

Delivery-date: Thu, 26 Jul 2001 07:25:36 -0700
Date: Thu, 26 Jul 2001 10:22:28 -0400
To: "manoj juneja" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fwd: RE: {SUKLM} numbering scheme
Cc: [email-masked],[email-masked],[email-masked]

Thank you for catching this.

Lou

At 09:26 PM 7/25/01, manoj juneja wrote:
>Hi Eric and Lou,
>                   The new GMPLS signalling drafts still distinguish
>between different SDH and SONET version of specifications (like 2000,
>1995 etc.). Eric, As u said earlier that we will be having only one
>value for SDH and one for SONET LSP encoding type. please see the mail
>below for further information. I want to know that whether this has been 
>done intentionally or it is just a bug that still need to be removed.
>
>Please clarify.
>
>Regards,
>manoj.
>>
>>
>>
>>
>>>From: "Mannie, Eric" <[email-masked]>
>>>To: 'manoj juneja' <[email-masked]>, [email-masked]
>>>CC: "[email-masked]'" <[email-masked]>
>>>Subject: RE: {SUKLM} numbering scheme
>>>Date: Thu, 28 Jun 2001 21:38:10 +0200
>>>
>>>Hello Manoj,
>>>
>>>The label is the same of course.
>>>
>>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a
>>>small bug coming from an old version. That should be removed by Lou. We
>>>should have only one SDH LSP encoding type value for SDH (same for SONET).
>>>
>>>Lou: thanks to correct it.
>>>
>>>For the conversion table, Maarten should still have it.
>>>
>>>Kind regards,
>>>
>>>Eric
>>>
>>>-----Original Message-----
>>>From: manoj juneja [mailto:[email-masked]]
>>>Sent: Thursday, June 28, 2001 8:28 PM
>>>To: [email-masked]
>>>Subject: {SUKLM} numbering scheme
>>>
>>>
>>>Hi All,
>>>           I have a doubt regarding {SUKLM} numbering scheme. If I
>>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
>>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
>>>ITU-T G.707 2000 ?
>>>
>>>Eric, on the ipo u and marteen once exchanged the conversion table for
>>>EDCBA and SU, If that table is correct, can u please tell me the
>>>formula from which u derived that table ?
>>>
>>>Regards,
>>>manoj.
>>>
>>>
>>>_________________________________________________________________
>>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>>>
>>
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 20:06:51 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Andre Fredette'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 23:04:15 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1157F.A72F0130
Content-Type: text/plain;
	charset="iso-8859-1"

I actually found it pretty weak.

Bilel.

That's a very interesting analogy.

Andre

At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote:
>In an ideal world, CR-LDP as an extension of LDP would have been
>the way to go.  It's funny that you should be arguing on the other
>side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
>CR-LDP) which is just an extension of LMP (read LDP) which nobody
>needs anyway (read "TE is the only MPLS app").  Such is life ..

------_=_NextPart_001_01C1157F.A72F0130
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I actually found it pretty weak.</FONT>
</P>

<P><FONT SIZE=2>Bilel.</FONT>
</P>
<BR>

<P><FONT SIZE=2>That's a very interesting analogy.</FONT>
</P>

<P><FONT SIZE=2>Andre</FONT>
</P>

<P><FONT SIZE=2>At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=2>&gt;In an ideal world, CR-LDP as an extension of LDP would have been</FONT>
<BR><FONT SIZE=2>&gt;the way to go.&nbsp; It's funny that you should be arguing on the other</FONT>
<BR><FONT SIZE=2>&gt;side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read</FONT>
<BR><FONT SIZE=2>&gt;CR-LDP) which is just an extension of LMP (read LDP) which nobody</FONT>
<BR><FONT SIZE=2>&gt;needs anyway (read &quot;TE is the only MPLS app&quot;).&nbsp; Such is life ..</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1157F.A72F0130--

Delivery-date: Wed, 25 Jul 2001 20:04:39 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 23:01:50 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1157F.509D23B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Kireeti,

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
> applications. The market has settled on RSVP-TE in ONE of the many MPLS
> applications -- namely Traffic Engineering of an IP network --

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

[Bilel] only time will tell.

In an ideal world, CR-LDP as an extension of LDP would have been
the way to go.  It's funny that you should be arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) which nobody
needs anyway (read "TE is the only MPLS app").  Such is life ...

[Bilel] 2 very different situations. + RSVP-TE is an extension of RSVP --
Are you saying "TE is the only MPLS app" ? or is the JD effect?

Bilel.

------_=_NextPart_001_01C1157F.509D23B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Kireeti,</FONT>
</P>

<P><FONT SIZE=2>&gt; [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS</FONT>
<BR><FONT SIZE=2>&gt; applications. The market has settled on RSVP-TE in ONE of the many MPLS</FONT>
<BR><FONT SIZE=2>&gt; applications -- namely Traffic Engineering of an IP network --</FONT>
</P>

<P><FONT SIZE=2>It's irrelevant what application RSVP-TE fits in.&nbsp; RSVP-TE and CR-LDP</FONT>
<BR><FONT SIZE=2>do the same thing in slightly different ways.</FONT>
</P>

<P><FONT SIZE=2>[Bilel] only time will tell.</FONT>
</P>

<P><FONT SIZE=2>In an ideal world, CR-LDP as an extension of LDP would have been</FONT>
<BR><FONT SIZE=2>the way to go.&nbsp; It's funny that you should be arguing on the other</FONT>
<BR><FONT SIZE=2>side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read</FONT>
<BR><FONT SIZE=2>CR-LDP) which is just an extension of LMP (read LDP) which nobody</FONT>
<BR><FONT SIZE=2>needs anyway (read &quot;TE is the only MPLS app&quot;).&nbsp; Such is life ...</FONT>
</P>

<P><FONT SIZE=2>[Bilel] 2 very different situations. + RSVP-TE is an extension of RSVP --</FONT>
<BR><FONT SIZE=2>Are you saying &quot;TE is the only MPLS app&quot; ? or is the JD effect?</FONT>
</P>

<P><FONT SIZE=2>Bilel.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1157F.509D23B0--

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jul 2001 19:00:02 -0700
Date: Wed, 25 Jul 2001 18:57:27 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Optical Link Interface
Cc: [email-masked], [email-masked], [email-masked]

Hi Osama,

> Even though I don't think reviving CR-LDP and RSVP-TE history will get us
> anywhere

"Those who forget (ignore) history are doomed to repeat it."

Yes, it makes for painful recollections.  We're living with the
consequences now, though, and I don't want to again.

> the existence of two protocols here have proven to be useful.

That's not what I'm hearing, either from customers, or from the
WG (admittedly, the sample is small).

Listen carefully: I don't want LMP-WDM and NTIP moving forward.
Just NTIP (or NTIP and LMP) is OKAY if that is what the WG
consensus is.  LMP-WDM and LMP works too.

So: you've got the WG chairs (scarred and grumpy), the ADs
and TA (speak up if I'm misrepresenting you), and customers
saying, Pick one protocol and move forward.  Let's do that.
And, please, as Vijay says, let's resolve this already.

Kireeti.

Delivery-date: Wed, 25 Jul 2001 18:27:02 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Fwd: RE: {SUKLM} numbering scheme
Date: Wed, 25 Jul 2001 18:26:07 -0700

Hi Eric and Lou,
                   The new GMPLS signalling drafts still distinguish
between different SDH and SONET version of specifications (like 2000,
1995 etc.). Eric, As u said earlier that we will be having only one
value for SDH and one for SONET LSP encoding type. please see the mail
below for further information. I want to know that whether this has been 
done intentionally or it is just a bug that still need to be removed.

Please clarify.

Regards,
manoj.
>
>
>
>
>>From: "Mannie, Eric" <[email-masked]>
>>To: 'manoj juneja' <[email-masked]>, [email-masked]
>>CC: "[email-masked]'" <[email-masked]>
>>Subject: RE: {SUKLM} numbering scheme
>>Date: Thu, 28 Jun 2001 21:38:10 +0200
>>
>>Hello Manoj,
>>
>>The label is the same of course.
>>
>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a
>>small bug coming from an old version. That should be removed by Lou. We
>>should have only one SDH LSP encoding type value for SDH (same for SONET).
>>
>>Lou: thanks to correct it.
>>
>>For the conversion table, Maarten should still have it.
>>
>>Kind regards,
>>
>>Eric
>>
>>-----Original Message-----
>>From: manoj juneja [mailto:[email-masked]]
>>Sent: Thursday, June 28, 2001 8:28 PM
>>To: [email-masked]
>>Subject: {SUKLM} numbering scheme
>>
>>
>>Hi All,
>>           I have a doubt regarding {SUKLM} numbering scheme. If I
>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
>>ITU-T G.707 2000 ?
>>
>>Eric, on the ipo u and marteen once exchanged the conversion table for
>>EDCBA and SU, If that table is correct, can u please tell me the
>>formula from which u derived that table ?
>>
>>Regards,
>>manoj.
>>
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>>
>>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 18:14:48 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Andre Fredette <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 21:11:05 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1156F.D83DDA90
Content-Type: text/plain;
	charset="iso-8859-1"

Andre,
 
Please go ahead and implement LMP. As I mentioned it is optional, and that
is your choice. My argument applies to LMP-WDM. 
 
Regards;
 
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]
 
-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 3:47 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface
 
Comments inline. 

At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:

Andre,

This is a misrepresentation of my argument. 
My argument is:
- LMP is at best optional. 

This is your opinion.  The members of the CCAMP working group have decided
that LMP is useful and needs to be specified.

Not everyone is going to implement it. 
- Let's not try to force it on everyone.

The way I read this is that you don't plan to implement LMP, so you want to
make it harder for those that do?

Therefore your argument to use LMP is not reasonable.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

-----Original Message-----
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress in 
the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C1156F.D83DDA90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>A=
ndre,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>P=
lease go
ahead and implement LMP. As I mentioned it is optional, and that is =
your
choice. My argument applies to LMP-WDM. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>R=
egards;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span=
></p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle17><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><font
color=3D"#3366ff" face=3D"Arial Black"><span =
style=3D'font-family:"Arial Black";
color:#3366FF'>Osama Aboul-Magd</span></font><font color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Nortel =
Networks</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>P.O. Box 3511, Station =
&quot;C&quot;</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Ottawa, ON, =
Canada</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>K1Y - 4H7</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Tel: =
613-763-5827</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>e.mail: =
[email-masked]</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle17><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle17><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Andre Fredette =
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
3:47 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Aboul-Magd, Osama
[CAR:1A00:EXCH]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Jonathan Lang;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>Comments
inline. <br>
<br>
At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:<br =
style=3D'mso-special-character:
line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Andre,<br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:navy'>This is a misrepresentation of my =
argument. <br>
My argument is:<br>
- LMP is at best optional. </span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
This is your opinion.&nbsp; The members of the CCAMP working group have =
decided
that LMP is useful and needs to be specified.<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Not
everyone is going to implement it. <br>
- Let's not try to force it on everyone.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
The way I read this is that you don't plan to implement LMP, so you =
want to
make it harder for those that do?<br>
<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Therefore
your argument to use LMP is not reasonable.<br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:navy'>Regards;<br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font color=3D"#3366ff" face=3D"Arial Black"><span =
style=3D'font-family:
"Arial Black";color:#3366FF'>Osama Aboul-Magd<br>
</span></font><font color=3Dnavy><span style=3D'color:navy'>Nortel =
Networks<br>
P.O. Box 3511, Station &quot;C&quot;<br>
Ottawa, ON, Canada<br>
K1Y - 4H7<br>
Tel: 613-763-5827<br>
e.mail: [email-masked]<br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Andre Fredette [<a
href=3D"mailto:[email-masked]" =
eudora=3Dautourl>mailto:[email-masked]</a>]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
2:11 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Aboul-Magd, Osama
[CAR:1A00:EXCH]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Jonathan Lang;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface<br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
Osama,<br>
<br>
[Note: I tried to trim this note down to the key arguments so that it =
is easier
to follow.]<br>
<br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<br>
<br>
Osama's main argument is:<br>
1. I don't think LMP should exist.<br>
2. Therefore let's create a new protocol.<br>
<br>
Given that the members of the working group have decided that LMP will =
be
developed, I don't think Osama's argument is reasonable.<br>
<br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font size=3D2
color=3Dblack><span style=3D'font-size:10.0pt;color:black'>[Osama] what =
is the
limitation here? Are you saying having a simple design is a limitation? =
Not
everything has to be complex. <br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Jonathan]&nbsp; Other DWDM vendors are =
not happy
with the master-slave model.&nbsp; Also, the claim that NTIP is simple =
is an
explicit assertion and you seem to be trying to make an implicit =
assertion that
LMP is complex. <br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
On the master-slave issue.&nbsp; There is clearly some information that =
the
line system does not need.&nbsp; For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.&nbsp; I think =
this works
fine within the context of LMP.<br>
<br>
You have made claims of complexity, but have never been able to back =
them up
with fact.<br>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Given the CR-LDP fiasco in MPLS, it was clearly stated by =
the ADs
and</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Working Group chairs in Minnesota that only one protocol =
will
progress in</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>the IETF.</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>[Osama] I don't understand why CR-LDP and RSVP-TE have =
been
brought to this discussion. This is a completely different situation. =
LMP
hasn't seen the&nbsp; wide deployment that RSVP-TE has. The example is
inadequate.</span></font><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'> <br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Jonathan] CR-LDP and RSVP-TE were both =
being
developed prior to either one of them being widely deployed.&nbsp; The =
effort
involved in developing 2 protocols concurrently to do the same thing is =
widely perceived
as being counter productive. <br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
Given the choice between specifying and implementing two protocols that =
do
basically the same thing and one, I think the choice should be =
clear.<br>
<br>
Andre</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1156F.D83DDA90--

Delivery-date: Wed, 25 Jul 2001 18:06:19 -0700
From: John Drake <[email-masked]>
To: 'Osama Aboul-Magd' <[email-masked]>, Kireeti Kompella <[email-masked]>, Bilel Jamoussi <[email-masked]>
Cc: [email-masked], Vasant Sahay <[email-masked]>,  Babu Narayanan <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 18:02:46 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1156E.AEFE6CE0
Content-Type: text/plain;
	charset="iso-8859-1"

"the existence of two protocols here have proven to be useful."  What in the
world does this mean?  Useful to who and for what?
 
-----Original Message-----
From: Osama Aboul-Magd [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 5:46 PM
To: Kireeti Kompella; Bilel Jamoussi
Cc: [email-masked]; Vasant Sahay; Babu Narayanan
Subject: RE: Optical Link Interface

Kireeti. 

Even though I don't think reviving CR-LDP and RSVP-TE history will get us
anywhere, there should always be the chance to offer customers the black
model T. the existence of two protocols here have proven to be useful.

Regards; 

Osama Aboul-Magd 
Nortel Networks 
P.O. Box 3511, Station "C" 
Ottawa, ON, Canada 
K1Y - 4H7 
Tel: 613-763-5827 
e.mail: [email-masked] 

 -----Original Message----- 
From:   Kireeti Kompella [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Wednesday, July 25, 2001 5:04 PM 
To:     Jamoussi, Bilel [BL60:1A00-M:EXCH] 
Cc:     [email-masked] 
Subject:        RE: Optical Link Interface 

Hi Bilel, 

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS 
> applications. The market has settled on RSVP-TE in ONE of the many MPLS 
> applications -- namely Traffic Engineering of an IP network -- 

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP 
do the same thing in slightly different ways. 

In an ideal world, CR-LDP as an extension of LDP would have been 
the way to go.  It's funny that you should be arguing on the other 
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read 
CR-LDP) which is just an extension of LMP (read LDP) which nobody 
needs anyway (read "TE is the only MPLS app").  Such is life ... 

> The (I)SPs 
> that deployed it did not have a choice from their vendors. 

Guilty as charged.  We gave them black model Ts, and they liked them. 
They didn't ask for any other colors, and aren't asking now, apart 
from idle curiosity. 

> Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The

> market prefers competing solutions to get the best of breed. 

All the ISP folks that I know who had to make a choice say that 
the process of choosing is mostly non-technical, and very much a 
big pain. 

The data I have indicates that the market wants competing 
implementations of the same standard, not competing standards. 
That's where the real value of "best of breed" lies. 

Kireeti. 

------_=_NextPart_001_01C1156E.AEFE6CE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=676350501-26072001>"the existence of two protocols here have proven to be 
useful."&nbsp;  What in the world does this mean?&nbsp; Useful to who and for 
what?</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=676350501-26072001>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=676350501-26072001></SPAN></FONT></FONT></FONT><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Osama Aboul-Magd 
[mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 5:46 
PM<BR><B>To:</B> Kireeti Kompella; Bilel Jamoussi<BR><B>Cc:</B> 
[email-masked]; Vasant Sahay; Babu Narayanan<BR><B>Subject:</B> RE: Optical 
Link Interface<BR><BR></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <P><FONT size=2>Kireeti.</FONT> </P>
  <P><FONT size=2>Even though I don't think reviving CR-LDP and RSVP-TE history 
  will get us anywhere, there should always be the chance to offer customers the 
  black model T. the existence of two protocols here have proven to be 
  useful.</FONT></P>
  <P><FONT size=2>Regards;</FONT> </P>
  <P><FONT size=2>Osama Aboul-Magd</FONT> <BR><FONT size=2>Nortel 
  Networks</FONT> <BR><FONT size=2>P.O. Box 3511, Station "C"</FONT> <BR><FONT 
  size=2>Ottawa, ON, Canada</FONT> <BR><FONT size=2>K1Y - 4H7</FONT> <BR><FONT 
  size=2>Tel: 613-763-5827</FONT> <BR><FONT size=2>e.mail: 
  [email-masked]</FONT> </P>
  <P><FONT size=2>&nbsp;-----Original Message-----</FONT> <BR><FONT size=2>From: 
  &nbsp; Kireeti Kompella [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 5:04 
  PM</FONT> <BR><FONT size=2>To:&nbsp;&nbsp;&nbsp;&nbsp; Jamoussi, Bilel 
  [BL60:1A00-M:EXCH]</FONT> <BR><FONT size=2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; 
  [email-masked]</FONT> <BR><FONT 
  size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Optical Link 
  Interface</FONT> </P>
  <P><FONT size=2>Hi Bilel,</FONT> </P>
  <P><FONT size=2>&gt; [Bilel Jamoussi] John, you seem to have a very narrow 
  view of MPLS</FONT> <BR><FONT size=2>&gt; applications. The market has settled 
  on RSVP-TE in ONE of the many MPLS</FONT> <BR><FONT size=2>&gt; applications 
  -- namely Traffic Engineering of an IP network --</FONT> </P>
  <P><FONT size=2>It's irrelevant what application RSVP-TE fits in.&nbsp; 
  RSVP-TE and CR-LDP</FONT> <BR><FONT size=2>do the same thing in slightly 
  different ways.</FONT> </P>
  <P><FONT size=2>In an ideal world, CR-LDP as an extension of LDP would have 
  been</FONT> <BR><FONT size=2>the way to go.&nbsp; It's funny that you should 
  be arguing on the other</FONT> <BR><FONT size=2>side now -- let's do NTIP 
  (read RSVP-TE) instead of LMP-WDM (read</FONT> <BR><FONT size=2>CR-LDP) which 
  is just an extension of LMP (read LDP) which nobody</FONT> <BR><FONT 
  size=2>needs anyway (read "TE is the only MPLS app").&nbsp; Such is life 
  ...</FONT> </P>
  <P><FONT size=2>&gt; The (I)SPs</FONT> <BR><FONT size=2>&gt; that deployed it 
  did not have a choice from their vendors.</FONT> </P>
  <P><FONT size=2>Guilty as charged.&nbsp; We gave them black model Ts, and they 
  liked them.</FONT> <BR><FONT size=2>They didn't ask for any other colors, and 
  aren't asking now, apart</FONT> <BR><FONT size=2>from idle curiosity.</FONT> 
  </P>
  <P><FONT size=2>&gt; Also, the market has 2 routing protocols in the IGP: OSPF 
  and IS-IS -- The</FONT> <BR><FONT size=2>&gt; market prefers competing 
  solutions to get the best of breed.</FONT> </P>
  <P><FONT size=2>All the ISP folks that I know who had to make a choice say 
  that</FONT> <BR><FONT size=2>the process of choosing is mostly non-technical, 
  and very much a</FONT> <BR><FONT size=2>big pain.</FONT> </P>
  <P><FONT size=2>The data I have indicates that the market wants 
  competing</FONT> <BR><FONT size=2>implementations of the same standard, not 
  competing standards.</FONT> <BR><FONT size=2>That's where the real value of 
  "best of breed" lies.</FONT> </P>
  <P><FONT size=2>Kireeti.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1156E.AEFE6CE0--

Delivery-date: Wed, 25 Jul 2001 18:05:29 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>, Andre Fredette <[email-masked]>
Cc: "Hamid Ould-Brahim" <[email-masked]>, Jonathan Lang <[email-masked]>, ccamp <[email-masked]>, "Vasant Sahay" <[email-masked]>, "Babu Narayanan" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 21:01:48 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1156E.8BF48BD0
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,

Thanks for your advice. I don't know what information model you are looking
at. Does it belong to LTSFGTC class?

The immediate problem is the inter-working between OXC-LS, and for that you
don't need LMP. I suggest you have your model kept with other "obsolete
information models"

Regards; 

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Dimitri Papadimitriou [mailto:[email-masked]] 
Sent:	Wednesday, July 25, 2001 6:56 PM
To:	Andre Fredette
Cc:	Ould-Brahim, Hamid [CAR:1A00:EXCH]; Aboul-Magd, Osama
[CAR:1A00:EXCH]; Jonathan Lang; ccamp
Subject:	Re: Optical Link Interface

 << File: Card for Dimitri Papadimitriou >> Hi Andre et all,

The argument you stated in your previous e-mail is fundamental,
as explained in the document we have a protocol for the OXC-OXC
interaction so that the "logical" solution is to extend the 
proposed protocol to the intra-link exchange of information
whatever kind of device it is (WDM or others). 

Sorry Vijay, from this point of view it is not only a carrier
facility but also related to the consistency of the approach
proposed by your supplier. Use the same protocol for both
functions is one of the key element to achieve the expected 
objective.

Consequently, the solution proposed by Osama and colleagues can
be clearly put on the shelf of the "lost protocols" because even
if fulfilling the same requirements it doesn't fit into a 
consistent informational model.

Regards,
Dimitri.  

Andre Fredette wrote:
> 
> At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:
> 
> > Andre,
> >
> >>
> >> Osama,
> >>
> >> [Note: I tried to trim this note down to the key arguments so that
> >> it is easier to follow.]
> >>
> >> My main argument (and I believe it is shared by the rest of the
> >> LMP-WDM co-authors) is as follows:
> >> 1. LMP exists.
> >> 2. LMP solves most of the OLI problems,
> >> 3. Therefore, let's use LMP.
> >>
> >> Osama's main argument is:
> >> 1. I don't think LMP should exist.
> >> 2. Therefore let's create a new protocol.
> >>
> >> Given that the members of the working group have decided that LMP
> >> will be developed, I don't think Osama's argument is reasonable.
> >>
> >> We went through that before and the WG has decided to make
> >> explicit the clarification that the issue is just between
> >> LMP-WDM and NTIP and not between LMP and NTIP.
> >
> 
> The whole point of LMP-WDM is to use an existing protocol to solve a
> new problem rather than create a new protocol just for the sake of
> creating a new one.  If there is a technical argument against using
> LMP for this problem, let's hear it!
> 
> >>
> >> Besides that I think that some of the arguments
> >> advanced are:
> >>
> >> 1. The issue is not how many protocols need to be advanced.
> >
> 
> This is a significant issue.
> 
> >>
> >> 2. The choice of advancing a given protocol should be
> >>    influenced by whether it is deployed or likely to be
> >>    widely deployed. And this applies even in the case
> >>    of one single protocol.
> >>
> >> 3. No matter what protocol(s) is/are selected,
> >>    it is the market who makes the final decision.
> >>
> >> Hamid.
> >>
> >> At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
> >>
> >> >              [Osama] what is the limitation here? Are you saying
> >> >      having a simple design is a limitation? Not everything has
> >> >      to be complex.
> >> >      [Jonathan]  Other DWDM vendors are not happy with the
> >> >      master-slave model.  Also, the claim that NTIP is simple is
> >> >      an explicit assertion and you seem to be trying to make an
> >> >      implicit assertion that LMP is complex.
> >> >
> >>
> >> On the master-slave issue.  There is clearly some information that
> >> the line system does not need.  For example, I don't expect the
> >> Link Characteristics need to be advertised from OXC to OLS.  I
> >> think this works fine within the context of LMP.
> >>
> >> You have made claims of complexity, but have never been able to
> >> back them up with fact.
> >>
> >> >      Given the CR-LDP fiasco in MPLS, it was clearly stated by
> >> >      the ADs and
> >> >      Working Group chairs in Minnesota that only one protocol
> >> >      will progress in
> >> >      the IETF.
> >> >
> >> >      [Osama] I don't understand why CR-LDP and RSVP-TE have been
> >> >      brought to this discussion. This is a completely different
> >> >      situation. LMP hasn't seen the  wide deployment that RSVP-TE
> >> >      has. The example is inadequate.
> >> >
> >> >      [Jonathan] CR-LDP and RSVP-TE were both being developed
> >> >      prior to either one of them being widely deployed.  The
> >> >      effort involved in developing 2 protocols concurrently to do
> >> >      the same thing is widely perceived as being counter
> >> >      productive.
> >> >
> >>
> >> Given the choice between specifying and implementing two protocols
> >> that do basically the same thing and one, I think the choice
> >> should be clear.
> >>
> >> Andre
> >

------_=_NextPart_001_01C1156E.8BF48BD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dimitri,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your advice. I don't know what information =
model you are looking at. Does it belong to LTSFGTC class?</FONT>
</P>

<P><FONT SIZE=3D2>The immediate problem is the inter-working between =
OXC-LS, and for that you don't need LMP. I suggest you have your model =
kept with other &quot;obsolete information models&quot;</FONT></P>

<P><FONT SIZE=3D2>Regards; </FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Dimitri Papadimitriou [<A =
HREF=3D"mailto:[email-masked]">mailto:dimitri.papadimi=
[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 6:56 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Andre Fredette</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Ould-Brahim, Hamid =
[CAR:1A00:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; Jonathan Lang; =
ccamp</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&lt;&lt; File: Card for Dimitri Papadimitriou =
&gt;&gt; Hi Andre et all,</FONT>
</P>

<P><FONT SIZE=3D2>The argument you stated in your previous e-mail is =
fundamental,</FONT>
<BR><FONT SIZE=3D2>as explained in the document we have a protocol for =
the OXC-OXC</FONT>
<BR><FONT SIZE=3D2>interaction so that the &quot;logical&quot; solution =
is to extend the </FONT>
<BR><FONT SIZE=3D2>proposed protocol to the intra-link exchange of =
information</FONT>
<BR><FONT SIZE=3D2>whatever kind of device it is (WDM or others). =
</FONT>
</P>

<P><FONT SIZE=3D2>Sorry Vijay, from this point of view it is not only a =
carrier</FONT>
<BR><FONT SIZE=3D2>facility but also related to the consistency of the =
approach</FONT>
<BR><FONT SIZE=3D2>proposed by your supplier. Use the same protocol for =
both</FONT>
<BR><FONT SIZE=3D2>functions is one of the key element to achieve the =
expected </FONT>
<BR><FONT SIZE=3D2>objective.</FONT>
</P>

<P><FONT SIZE=3D2>Consequently, the solution proposed by Osama and =
colleagues can</FONT>
<BR><FONT SIZE=3D2>be clearly put on the shelf of the &quot;lost =
protocols&quot; because even</FONT>
<BR><FONT SIZE=3D2>if fulfilling the same requirements it doesn't fit =
into a </FONT>
<BR><FONT SIZE=3D2>consistent informational model.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Dimitri.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Andre Fredette wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Andre,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Osama,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; [Note: I tried to trim this note down =
to the key arguments so that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; it is easier to follow.]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; My main argument (and I believe it is =
shared by the rest of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; LMP-WDM co-authors) is as =
follows:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 1. LMP exists.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 2. LMP solves most of the OLI =
problems,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 3. Therefore, let's use LMP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Osama's main argument is:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 1. I don't think LMP should =
exist.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 2. Therefore let's create a new =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Given that the members of the working =
group have decided that LMP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; will be developed, I don't think =
Osama's argument is reasonable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; We went through that before and the WG =
has decided to make</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; explicit the clarification that the =
issue is just between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; LMP-WDM and NTIP and not between LMP =
and NTIP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The whole point of LMP-WDM is to use an =
existing protocol to solve a</FONT>
<BR><FONT SIZE=3D2>&gt; new problem rather than create a new protocol =
just for the sake of</FONT>
<BR><FONT SIZE=3D2>&gt; creating a new one.&nbsp; If there is a =
technical argument against using</FONT>
<BR><FONT SIZE=3D2>&gt; LMP for this problem, let's hear it!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Besides that I think that some of the =
arguments</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; advanced are:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 1. The issue is not how many protocols =
need to be advanced.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is a significant issue.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 2. The choice of advancing a given =
protocol should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp; influenced by =
whether it is deployed or likely to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp; widely deployed. And =
this applies even in the case</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp; of one single =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 3. No matter what protocol(s) is/are =
selected,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp; it is the market who =
makes the final decision.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Hamid.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; At 10:41 AM 7/25/2001 -0700, Jonathan =
Lang wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; [Osama] what is the limitation here? Are you saying</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
having a simple design is a limitation? Not everything has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
be complex.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[Jonathan]&nbsp; Other DWDM vendors are not happy with the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
master-slave model.&nbsp; Also, the claim that NTIP is simple is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an =
explicit assertion and you seem to be trying to make an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
implicit assertion that LMP is complex.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; On the master-slave issue.&nbsp; There =
is clearly some information that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; the line system does not need.&nbsp; =
For example, I don't expect the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Link Characteristics need to be =
advertised from OXC to OLS.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; think this works fine within the =
context of LMP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; You have made claims of complexity, =
but have never been able to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; back them up with fact.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Given the CR-LDP fiasco in MPLS, it was clearly stated by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
ADs and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Working Group chairs in Minnesota that only one protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
will progress in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[Osama] I don't understand why CR-LDP and RSVP-TE have been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
brought to this discussion. This is a completely different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
situation. LMP hasn't seen the&nbsp; wide deployment that =
RSVP-TE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
has. The example is inadequate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[Jonathan] CR-LDP and RSVP-TE were both being developed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
prior to either one of them being widely deployed.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
effort involved in developing 2 protocols concurrently to do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
same thing is widely perceived as being counter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
productive.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Given the choice between specifying =
and implementing two protocols</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; that do basically the same thing and =
one, I think the choice</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; should be clear.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Andre</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1156E.8BF48BD0--

Delivery-date: Wed, 25 Jul 2001 17:51:33 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Bilel Jamoussi" <[email-masked]>
Cc: [email-masked], "Vasant Sahay" <[email-masked]>, "Babu Narayanan" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 20:46:24 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1156C.656C1D40
Content-Type: text/plain;
	charset="iso-8859-1"

Kireeti.

Even though I don't think reviving CR-LDP and RSVP-TE history will get us
anywhere, there should always be the chance to offer customers the black
model T. the existence of two protocols here have proven to be useful.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Kireeti Kompella [mailto:[email-masked]] 
Sent:	Wednesday, July 25, 2001 5:04 PM
To:	Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc:	[email-masked]
Subject:	RE: Optical Link Interface

Hi Bilel,

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
> applications. The market has settled on RSVP-TE in ONE of the many MPLS
> applications -- namely Traffic Engineering of an IP network --

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

In an ideal world, CR-LDP as an extension of LDP would have been
the way to go.  It's funny that you should be arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) which nobody
needs anyway (read "TE is the only MPLS app").  Such is life ...

> The (I)SPs
> that deployed it did not have a choice from their vendors.

Guilty as charged.  We gave them black model Ts, and they liked them.
They didn't ask for any other colors, and aren't asking now, apart
from idle curiosity.

> Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The
> market prefers competing solutions to get the best of breed.

All the ISP folks that I know who had to make a choice say that
the process of choosing is mostly non-technical, and very much a
big pain.

The data I have indicates that the market wants competing
implementations of the same standard, not competing standards.
That's where the real value of "best of breed" lies.

Kireeti.

------_=_NextPart_001_01C1156C.656C1D40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti.</FONT>
</P>

<P><FONT SIZE=3D2>Even though I don't think reviving CR-LDP and RSVP-TE =
history will get us anywhere, there should always be the chance to =
offer customers the black model T. the existence of two protocols here =
have proven to be useful.</FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 5:04 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Jamoussi, Bilel =
[BL60:1A00-M:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=3D2>Hi Bilel,</FONT>
</P>

<P><FONT SIZE=3D2>&gt; [Bilel Jamoussi] John, you seem to have a very =
narrow view of MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; applications. The market has settled on RSVP-TE =
in ONE of the many MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; applications -- namely Traffic Engineering of =
an IP network --</FONT>
</P>

<P><FONT SIZE=3D2>It's irrelevant what application RSVP-TE fits =
in.&nbsp; RSVP-TE and CR-LDP</FONT>
<BR><FONT SIZE=3D2>do the same thing in slightly different ways.</FONT>
</P>

<P><FONT SIZE=3D2>In an ideal world, CR-LDP as an extension of LDP =
would have been</FONT>
<BR><FONT SIZE=3D2>the way to go.&nbsp; It's funny that you should be =
arguing on the other</FONT>
<BR><FONT SIZE=3D2>side now -- let's do NTIP (read RSVP-TE) instead of =
LMP-WDM (read</FONT>
<BR><FONT SIZE=3D2>CR-LDP) which is just an extension of LMP (read LDP) =
which nobody</FONT>
<BR><FONT SIZE=3D2>needs anyway (read &quot;TE is the only MPLS =
app&quot;).&nbsp; Such is life ...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The (I)SPs</FONT>
<BR><FONT SIZE=3D2>&gt; that deployed it did not have a choice from =
their vendors.</FONT>
</P>

<P><FONT SIZE=3D2>Guilty as charged.&nbsp; We gave them black model Ts, =
and they liked them.</FONT>
<BR><FONT SIZE=3D2>They didn't ask for any other colors, and aren't =
asking now, apart</FONT>
<BR><FONT SIZE=3D2>from idle curiosity.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Also, the market has 2 routing protocols in the =
IGP: OSPF and IS-IS -- The</FONT>
<BR><FONT SIZE=3D2>&gt; market prefers competing solutions to get the =
best of breed.</FONT>
</P>

<P><FONT SIZE=3D2>All the ISP folks that I know who had to make a =
choice say that</FONT>
<BR><FONT SIZE=3D2>the process of choosing is mostly non-technical, and =
very much a</FONT>
<BR><FONT SIZE=3D2>big pain.</FONT>
</P>

<P><FONT SIZE=3D2>The data I have indicates that the market wants =
competing</FONT>
<BR><FONT SIZE=3D2>implementations of the same standard, not competing =
standards.</FONT>
<BR><FONT SIZE=3D2>That's where the real value of &quot;best of =
breed&quot; lies.</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1156C.656C1D40--

Delivery-date: Wed, 25 Jul 2001 17:34:34 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Bala Rajagopalan <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Cc: "Vasant Sahay" <[email-masked]>, "Babu Narayanan" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 20:32:48 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1156A.7F02EF60
Content-Type: text/plain;
	charset="iso-8859-1"

Neighbor discovery is included in the latest revision of the draft. I
submitted last Friday.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Bala Rajagopalan [mailto:[email-masked]] 
Sent:	Wednesday, July 25, 2001 5:54 PM
To:	'Kireeti Kompella'; [email-masked]
Subject:	RE: Optical Link Interface

Kireeti:

Thanks for distilling the issues into the 3 bullet
items. I would also like to add my two cents on these
points as an OXC vendor:

> a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.
> 
  I think both choices have pitfalls.

  LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One
may exist without the other. Indeed, for a WDM vendor, LMP-WDM
will be a new protocol to implement. If they balk, I can't unilaterally
choose LMP-WDM on the OXC side. Also, my experience so far
has been that neighbor discovery based on LMP is not simple
to realize in transparent switches, the main candidate for OLI.
So, the question of LMP-WDM as an extension of LMP (as it
currently stands) may be moot. 

  NTIP: The present definition does not provide for neighbor
  discovery, a function required under OLI. Is another protocol
  required for this? If so, the value of NTIP is diluted.

So, I think a case can be made for NTIP only if the neighbor
disc. function is taken out of OLI. Similarly, a rather strong
case for LMP-WDM can be made if the LMP neighbor disc. functionality
could be simplified. I would personally prefer the second
option since it provides a complete package
(if there is any all-optical vendor out there who
has got LMP neighbor discovery running, send me email :-) ).

> 
> b) Two protocols vs. one.
> 
    One. But one that is useful in practice.
> 
> c) The model: master-slave vs. peer.
> 
 Both LMP-WDM and NTIP can operate in the request-response mode.
I don't see this as an issue.

> 
> d) The transport protocol: TCP or raw over IP.
> 
  No big deal either way.

------_=_NextPart_001_01C1156A.7F02EF60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Neighbor discovery is included in the latest revision of the draft. I submitted last Friday.</FONT>
</P>

<P><FONT SIZE=2>Regards;</FONT>
</P>

<P><FONT SIZE=2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
<BR><FONT SIZE=2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=2>K1Y - 4H7</FONT>
<BR><FONT SIZE=2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: &nbsp; Bala Rajagopalan [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 5:54 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; 'Kireeti Kompella'; [email-masked]</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=2>Kireeti:</FONT>
</P>

<P><FONT SIZE=2>Thanks for distilling the issues into the 3 bullet</FONT>
<BR><FONT SIZE=2>items. I would also like to add my two cents on these</FONT>
<BR><FONT SIZE=2>points as an OXC vendor:</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&nbsp; I think both choices have pitfalls.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One</FONT>
<BR><FONT SIZE=2>may exist without the other. Indeed, for a WDM vendor, LMP-WDM</FONT>
<BR><FONT SIZE=2>will be a new protocol to implement. If they balk, I can't unilaterally</FONT>
<BR><FONT SIZE=2>choose LMP-WDM on the OXC side. Also, my experience so far</FONT>
<BR><FONT SIZE=2>has been that neighbor discovery based on LMP is not simple</FONT>
<BR><FONT SIZE=2>to realize in transparent switches, the main candidate for OLI.</FONT>
<BR><FONT SIZE=2>So, the question of LMP-WDM as an extension of LMP (as it</FONT>
<BR><FONT SIZE=2>currently stands) may be moot. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; NTIP: The present definition does not provide for neighbor</FONT>
<BR><FONT SIZE=2>&nbsp; discovery, a function required under OLI. Is another protocol</FONT>
<BR><FONT SIZE=2>&nbsp; required for this? If so, the value of NTIP is diluted.</FONT>
</P>

<P><FONT SIZE=2>So, I think a case can be made for NTIP only if the neighbor</FONT>
<BR><FONT SIZE=2>disc. function is taken out of OLI. Similarly, a rather strong</FONT>
<BR><FONT SIZE=2>case for LMP-WDM can be made if the LMP neighbor disc. functionality</FONT>
<BR><FONT SIZE=2>could be simplified. I would personally prefer the second</FONT>
<BR><FONT SIZE=2>option since it provides a complete package</FONT>
<BR><FONT SIZE=2>(if there is any all-optical vendor out there who</FONT>
<BR><FONT SIZE=2>has got LMP neighbor discovery running, send me email :-) ).</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; b) Two protocols vs. one.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; One. But one that is useful in practice.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; c) The model: master-slave vs. peer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&nbsp;Both LMP-WDM and NTIP can operate in the request-response mode.</FONT>
<BR><FONT SIZE=2>I don't see this as an issue.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; d) The transport protocol: TCP or raw over IP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&nbsp; No big deal either way.</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1156A.7F02EF60--

Delivery-date: Wed, 25 Jul 2001 16:21:58 -0700
From: Andre Fredette <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
Cc: [email-masked]
Date: Wed, 25 Jul 2001 19:20:46 -0400
Subject: Re: Optical Link Interface

Good points.

Andre

At 02:10 PM 7/25/2001 -0700, Sudheer Dharanikota wrote:
>Hi:
>
>My few cents .. being involved in these discussions.
>
>Kireeti Kompella wrote:
>
> >
> >
> > c) The model: master-slave vs. peer.
> >
> >    This is the key debate (in my opinion).  Is LMP-WDM a "natural
> >    extension of LMP", as Andre says; or is the master-slave model
> >    more appropriate in this context, as Osama says?
> >
>
>The issue here is who has the control over which resource.
>The OXCs have control over the links and link bundles, and
>the DWDMs have the control over the fault reporting behaviour,
>the monitoring (may not be in the first release of the requirements)
>and the mapping of logical nature of the links and link bundles
>to the physical resources.
>
>In my opinion there are and there will be DWDM and OXC
>boxes which will not be capable of doing all the required
>features (as mentioned in the above paragraph). This leads
>to negotiation of features (or capabilities) between the two.
>
>Hence I feel this protocol LMP-DWDM or NTIP should be a
>peer-to-peer protocol.
>
> >
> > d) The transport protocol: TCP or raw over IP.
> >
> >    Does the reliability of using TCP as transport offer a real
> >    advantage in this context?  Or do the complications of
> >    managing failover with TCP outweigh this benefit?
> >
> >
>
>The main goal of these protocols is to report a failure as
>quickly as possible. A failure typically effect multiple
>links. Another observation is that the two elements (DWDM and
>OXC) need not be immediate neighbors. They can go through
>DCN. But in either case the amount of traffic in the control
>plane may not cause packet losses.
>
>With these two observations I feel that TCP is an over kill.
>
>
>Cheers,
>
>sudheer

Delivery-date: Wed, 25 Jul 2001 16:20:29 -0700
From: Andre Fredette <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 25 Jul 2001 19:19:26 -0400
Subject: RE: Optical Link Interface

That's a very interesting analogy.

Andre

At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote:
>In an ideal world, CR-LDP as an extension of LDP would have been
>the way to go.  It's funny that you should be arguing on the other
>side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
>CR-LDP) which is just an extension of LMP (read LDP) which nobody
>needs anyway (read "TE is the only MPLS app").  Such is life ...

Delivery-date: Wed, 25 Jul 2001 16:18:33 -0700
From: Andre Fredette <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Date: Wed, 25 Jul 2001 19:17:16 -0400
Subject: RE: Optical Link Interface

Kireeti,

Thank you for helping us to focus on the technical arguments.

I agree with your comments below.

On the master-slave vs. peer issue, I think both would work, but the peer 
model is more flexible without being significantly more complex.  LMP is 
just not a complex protocol (no matter how you slice it).

Andre

At 01:39 PM 7/25/2001 -0700, Kireeti Kompella wrote:
>Hi,
>
>This email is as a router vendor/implementor.
>
>The issues (so far) are:
>
>a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.
>
>    Subject to (c) below, I much prefer having to implement LMP
>    (which I will have to) and add on the features needed for
>    the OLI, rather than implement two different protocols.  The
>    rationale is the same as was used when deciding to extend
>    link state IGPs with TE information rather than do a new TE
>    link state flooding protocol, or to do GMPLS as an extension
>    of MPLS rather than develop a new optical signaling protocol.
>
>b) Two protocols vs. one.
>
>    One.
>
>c) The model: master-slave vs. peer.
>
>    I'm not qualified to speak here; this is the domain of the
>    optical gurus.  However, I'll make two tangential points.  The
>    first is that the answer seems to depend on the architecture
>    of the component systems, which probably indicates that the
>    protocol should do both.  The second is a piece of generic
>    wisdom (?) that it is generally easier to add bells onto a
>    peer-oriented protocol to deal with the master-slave case
>    than to add whistles to a master-slave protocol to make it
>    work in the peer case.
>
>d) The transport protocol: TCP or raw over IP.
>
>    It is my understanding that the PXC-WDM link is usually one IP
>    hop; it seems that TCP is an overkill in that case.  Also,
>    building failover capability for TCP-based protocols is rather
>    more challenging.
>
>    (Side note: both protocols can be made to work either way, so
>    this is not so much of an NTIP-LMP_WDM issue as much as "what
>    transport should OLI use?")
>
>Kireeti.

Delivery-date: Wed, 25 Jul 2001 16:05:08 -0700
Date: Wed, 25 Jul 2001 19:09:47 -0400
To: "Bilel Jamoussi" <[email-masked]>, "'Jonathan Lang'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: Optical Link Interface

--=====================_38487371==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been 
>talking to view this as a very healthy and competitive approach to have a 
>scalable and robust solution(s). Traffic Engineering an IP network (the 
>only application where RSVP-TE is deployed today) is a very narrow segment 
>of the MPLS/GMPLS applications market.

         Not exactly. I think that we want a scalable and
robust *standard* and competitive implementations,
not competing standards. Remember Beta vs. VHS? That
is a good example of what happens when you get the
latter: consumer confusion and inevitably wasted money
and effort on the part of both the consumer and the
vendor. :(  I think that the ADs are right here: lets
settle on a single solution soon. I would opt for LMP
and LMP-WDM for the reasons already espoused.

         --Tom

--=====================_38487371==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<blockquote type=cite cite><font size=2>[Bilel Jamoussi] There is no
fiasco -- The ISPs and carriers I have been talking to view this as a
very healthy and competitive approach to have a scalable and robust
solution(s). Traffic Engineering an IP network (the only application
where RSVP-TE is deployed today) is a very narrow segment of the
MPLS/GMPLS applications market. </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Not
exactly. I think that we want a scalable and<br>
robust *standard* and competitive implementations,<br>
not competing standards. Remember Beta vs. VHS? That <br>
is a good example of what happens when you get the <br>
latter: consumer confusion and inevitably wasted money <br>
and effort on the part of both the consumer and the <br>
vendor. :(&nbsp; I think that the ADs are right here: lets <br>
settle on a single solution soon. I would opt for LMP<br>
and LMP-WDM for the reasons already espoused.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
</html>

--=====================_38487371==_.ALT--

Delivery-date: Wed, 25 Jul 2001 15:57:39 -0700
Date: Thu, 26 Jul 2001 00:56:25 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG-NA
To: Andre Fredette <[email-masked]>
CC: Hamid Ould-Brahim <[email-masked]>, Osama Aboul-Magd <[email-masked]>, Jonathan Lang <[email-masked]>, ccamp <[email-masked]>
Subject: Re: Optical Link Interface

This is a multi-part message in MIME format.
--------------5FAC6B0E9FA6E01440A67834
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Andre et all,

The argument you stated in your previous e-mail is fundamental,
as explained in the document we have a protocol for the OXC-OXC
interaction so that the "logical" solution is to extend the 
proposed protocol to the intra-link exchange of information
whatever kind of device it is (WDM or others). 

Sorry Vijay, from this point of view it is not only a carrier
facility but also related to the consistency of the approach
proposed by your supplier. Use the same protocol for both
functions is one of the key element to achieve the expected 
objective.

Consequently, the solution proposed by Osama and colleagues can
be clearly put on the shelf of the "lost protocols" because even
if fulfilling the same requirements it doesn't fit into a 
consistent informational model.

Regards,
Dimitri.  

Andre Fredette wrote:
> 
> At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:
> 
> > Andre,
> >
> >>
> >> Osama,
> >>
> >> [Note: I tried to trim this note down to the key arguments so that
> >> it is easier to follow.]
> >>
> >> My main argument (and I believe it is shared by the rest of the
> >> LMP-WDM co-authors) is as follows:
> >> 1. LMP exists.
> >> 2. LMP solves most of the OLI problems,
> >> 3. Therefore, let's use LMP.
> >>
> >> Osama's main argument is:
> >> 1. I don't think LMP should exist.
> >> 2. Therefore let's create a new protocol.
> >>
> >> Given that the members of the working group have decided that LMP
> >> will be developed, I don't think Osama's argument is reasonable.
> >>
> >> We went through that before and the WG has decided to make
> >> explicit the clarification that the issue is just between
> >> LMP-WDM and NTIP and not between LMP and NTIP.
> >
> 
> The whole point of LMP-WDM is to use an existing protocol to solve a
> new problem rather than create a new protocol just for the sake of
> creating a new one.  If there is a technical argument against using
> LMP for this problem, let's hear it!
> 
> >>
> >> Besides that I think that some of the arguments
> >> advanced are:
> >>
> >> 1. The issue is not how many protocols need to be advanced.
> >
> 
> This is a significant issue.
> 
> >>
> >> 2. The choice of advancing a given protocol should be
> >>    influenced by whether it is deployed or likely to be
> >>    widely deployed. And this applies even in the case
> >>    of one single protocol.
> >>
> >> 3. No matter what protocol(s) is/are selected,
> >>    it is the market who makes the final decision.
> >>
> >> Hamid.
> >>
> >> At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
> >>
> >> >              [Osama] what is the limitation here? Are you saying
> >> >      having a simple design is a limitation? Not everything has
> >> >      to be complex.
> >> >      [Jonathan]  Other DWDM vendors are not happy with the
> >> >      master-slave model.  Also, the claim that NTIP is simple is
> >> >      an explicit assertion and you seem to be trying to make an
> >> >      implicit assertion that LMP is complex.
> >> >
> >>
> >> On the master-slave issue.  There is clearly some information that
> >> the line system does not need.  For example, I don't expect the
> >> Link Characteristics need to be advertised from OXC to OLS.  I
> >> think this works fine within the context of LMP.
> >>
> >> You have made claims of complexity, but have never been able to
> >> back them up with fact.
> >>
> >> >      Given the CR-LDP fiasco in MPLS, it was clearly stated by
> >> >      the ADs and
> >> >      Working Group chairs in Minnesota that only one protocol
> >> >      will progress in
> >> >      the IETF.
> >> >
> >> >      [Osama] I don't understand why CR-LDP and RSVP-TE have been
> >> >      brought to this discussion. This is a completely different
> >> >      situation. LMP hasn't seen the  wide deployment that RSVP-TE
> >> >      has. The example is inadequate.
> >> >
> >> >      [Jonathan] CR-LDP and RSVP-TE were both being developed
> >> >      prior to either one of them being widely deployed.  The
> >> >      effort involved in developing 2 protocols concurrently to do
> >> >      the same thing is widely perceived as being counter
> >> >      productive.
> >> >
> >>
> >> Given the choice between specifying and implementing two protocols
> >> that do basically the same thing and one, I think the choice
> >> should be clear.
> >>
> >> Andre
> >
--------------5FAC6B0E9FA6E01440A67834
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------5FAC6B0E9FA6E01440A67834--

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jul 2001 15:14:49 -0700
Date: Wed, 25 Jul 2001 15:11:49 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Optical Link Interface

Hi Bala,

> I would also like to add my two cents on these
> points as an OXC vendor:

Thanks, Bala for your perspective, both as an OXC vendor and
as a non-author :-)

Kireeti.

Delivery-date: Wed, 25 Jul 2001 14:54:40 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 17:54:20 -0400

Kireeti:

Thanks for distilling the issues into the 3 bullet
items. I would also like to add my two cents on these
points as an OXC vendor:

> a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.
> 
  I think both choices have pitfalls.

  LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One
may exist without the other. Indeed, for a WDM vendor, LMP-WDM
will be a new protocol to implement. If they balk, I can't unilaterally
choose LMP-WDM on the OXC side. Also, my experience so far
has been that neighbor discovery based on LMP is not simple
to realize in transparent switches, the main candidate for OLI.
So, the question of LMP-WDM as an extension of LMP (as it
currently stands) may be moot. 

  NTIP: The present definition does not provide for neighbor
  discovery, a function required under OLI. Is another protocol
  required for this? If so, the value of NTIP is diluted.

So, I think a case can be made for NTIP only if the neighbor
disc. function is taken out of OLI. Similarly, a rather strong
case for LMP-WDM can be made if the LMP neighbor disc. functionality
could be simplified. I would personally prefer the second
option since it provides a complete package
(if there is any all-optical vendor out there who
has got LMP neighbor discovery running, send me email :-) ).

> 
> b) Two protocols vs. one.
> 
    One. But one that is useful in practice.
> 
> c) The model: master-slave vs. peer.
> 
 Both LMP-WDM and NTIP can operate in the request-response mode.
I don't see this as an issue.

> 
> d) The transport protocol: TCP or raw over IP.
> 
  No big deal either way.

Delivery-date: Wed, 25 Jul 2001 14:21:37 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 17:19:59 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1154F.8F906850
Content-Type: text/plain;
	charset="iso-8859-1"

John, apology accepted.
 
the slideware comment is in reference to the "more flexible model" of
products vs product limitations -- not NTIP nor LMP-WDM.
 
> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model

itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC 
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship 
suits this 
> interface better. 
I understand this limitation works for your product, but other WDM vendors 
have requested a more flexible model. 

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 5:06 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; John Drake; 'Andre Fredette';
Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]'
Subject: RE: Optical Link Interface

Bilel,
 
I'm awfully sorry, I was just teasing you.  You had started things with your
assertion that LMP-WDM was slideware, but you're right, it was beneath me.
 
Incidentally, I think your note might have had more credibility if you'd
sent it privately. 
 
Thanks,
 
John 

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:48 PM
To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; [email-masked]'
Subject: RE: Optical Link Interface

 

However, NTIP addresses an immediate need and does not HAVE to be based on
LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.
However, as you pointed out, since NTIP is slideware, it can't be an
immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in
people's mouths -- Don't use that style with me!!  
try to stay professional

 

------_=_NextPart_001_01C1154F.8F906850
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=710581621-25072001><FONT face=Arial color=#0000ff size=2>John, 
apology accepted.</FONT></SPAN></DIV>
<DIV><SPAN class=710581621-25072001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=710581621-25072001><FONT face=Arial color=#0000ff size=2>the 
slideware comment is in reference to the "more flexible model" of products vs 
product limitations -- not NTIP nor LMP-WDM.</FONT></SPAN></DIV>
<DIV><SPAN class=710581621-25072001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=710581621-25072001><FONT size=2>&gt; - The issue is not really 
LMP vs TCP. NTIP and LMP-WDM differ in the model<FONT size=3> <BR></FONT><FONT 
size=2>itself. Your </FONT><BR><FONT size=2>&gt; choice to use LMP to run 
LMP-WDM on top of it forced you to treat the PXC</FONT><FONT size=3> 
<BR></FONT><FONT size=2>and LS as peers. </FONT><BR><FONT size=2>&gt; NTIP 
treats PXC-LS relationship as master-slave. Non peer relationship</FONT><FONT 
size=3> <BR></FONT><FONT size=2>suits this </FONT><BR><FONT size=2>&gt; 
interface better.</FONT><FONT size=3> <BR></FONT><FONT size=2>I understand this 
limitation works for your product, but other WDM vendors</FONT><FONT size=3> 
<BR></FONT><FONT size=2>have requested a more flexible model.</FONT><FONT 
size=3> </FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Drake 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 5:06 
  PM<BR><B>To:</B> Jamoussi, Bilel [BL60:1A00-M:EXCH]; John Drake; 'Andre 
  Fredette'; Aboul-Magd, Osama [CAR:1A00:EXCH]<BR><B>Cc:</B> Jonathan Lang; 
  [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001>Bilel,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=015020321-25072001>I'm 
  awfully sorry, I was just teasing you.&nbsp; You had started things with 
  your&nbsp;assertion that LMP-WDM was slideware, but you're right, it was 
  beneath me.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001>Incidentally, I think your note might have had more 
  credibility if you'd sent it privately.&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=015020321-25072001>John&nbsp;</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 
    2001 1:48 PM<BR><B>To:</B> 'John Drake'; 'Andre Fredette'; Osama 
    Aboul-Magd<BR><B>Cc:</B> 'Jonathan Lang'; 
    [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
    Interface<BR><BR></DIV></FONT>
    <DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff 
    size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
        <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
        class=180231720-25072001>However, NTIP addresses an immediate need and 
        does not HAVE to be based on LMP.<BR><SPAN 
        class=514583420-25072001>[John 
        Drake]&nbsp;</SPAN></SPAN></FONT></FONT></FONT><FONT size=2><FONT 
        color=#0000ff><FONT face=Arial><SPAN class=180231720-25072001><SPAN 
        class=514583420-25072001></SPAN></SPAN></FONT></FONT></FONT></DIV>
        <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
        class=180231720-25072001><SPAN class=514583420-25072001>Well, there is a 
        immediate need for a protocol that can support the OLI.&nbsp; However, 
        as you pointed out, since NTIP is slideware, it can't be an immediate 
        solution to that immediate 
        need.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
        <DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff 
        size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
        face=Arial color=#0000ff size=2>[Bilel Jamoussi] John, you have a bad 
        reputation of putting words in people's mouths -- Don't use that style 
        with me!!&nbsp; </FONT></SPAN></SPAN></DIV>
        <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
        face=Arial color=#0000ff size=2>try to stay 
        professional</FONT></SPAN></SPAN></DIV>
        <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
        face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
        face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
        <DIV><FONT face=Arial color=#0000ff 
    size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1154F.8F906850--

Delivery-date: Wed, 25 Jul 2001 14:12:46 -0700
Date: Wed, 25 Jul 2001 17:12:10 -0400
From: Vijay Gill <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: RE: Optical Link Interface

On Wed, 25 Jul 2001, Kireeti Kompella wrote:

> CR-LDP) which is just an extension of LMP (read LDP) which nobody
> needs anyway (read "TE is the only MPLS app").  Such is life ...
>
> > The (I)SPs
> > that deployed it did not have a choice from their vendors.
>
> Guilty as charged.  We gave them black model Ts, and they liked them.
> They didn't ask for any other colors, and aren't asking now, apart
> from idle curiosity.

Having been there in the middle of this, I can attest to it that if we
(the isp's selecting the signalling) felt that CR-LDP was a good enough
solution, we'd have asked our vendors for it. However, the protocol
evolution at the time was scary enough with so many cooks that the simple
and fairly straightforward RSVP-TE process was very appealing.

> > market prefers competing solutions to get the best of breed.
>
> All the ISP folks that I know who had to make a choice say that
> the process of choosing is mostly non-technical, and very much a
> big pain.

In general, best of breed solutions tend to invoke stupendous amounts of
pain as we try and integrate the backends.

> The data I have indicates that the market wants competing
> implementations of the same standard, not competing standards. That's
> where the real value of "best of breed" lies.

Precisely. Well said, Kireeti.

/vijay

Delivery-date: Wed, 25 Jul 2001 14:11:02 -0700
Date: Wed, 25 Jul 2001 14:10:22 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Optical Link Interface

Hi:

My few cents .. being involved in these discussions.

Kireeti Kompella wrote:

>
>
> c) The model: master-slave vs. peer.
>
>    This is the key debate (in my opinion).  Is LMP-WDM a "natural
>    extension of LMP", as Andre says; or is the master-slave model
>    more appropriate in this context, as Osama says?
>

The issue here is who has the control over which resource.
The OXCs have control over the links and link bundles, and
the DWDMs have the control over the fault reporting behaviour,
the monitoring (may not be in the first release of the requirements)
and the mapping of logical nature of the links and link bundles
to the physical resources.

In my opinion there are and there will be DWDM and OXC
boxes which will not be capable of doing all the required
features (as mentioned in the above paragraph). This leads
to negotiation of features (or capabilities) between the two.

Hence I feel this protocol LMP-DWDM or NTIP should be a
peer-to-peer protocol.

>
> d) The transport protocol: TCP or raw over IP.
>
>    Does the reliability of using TCP as transport offer a real
>    advantage in this context?  Or do the complications of
>    managing failover with TCP outweigh this benefit?
>
>

The main goal of these protocols is to report a failure as
quickly as possible. A failure typically effect multiple
links. Another observation is that the two elements (DWDM and
OXC) need not be immediate neighbors. They can go through
DCN. But in either case the amount of traffic in the control
plane may not cause packet losses.

With these two observations I feel that TCP is an over kill.

Cheers,

sudheer

Delivery-date: Wed, 25 Jul 2001 14:06:30 -0700
From: John Drake <[email-masked]>
To: 'Bilel Jamoussi' <[email-masked]>, John Drake <[email-masked]>, 'Andre Fredette' <[email-masked]>,  Osama Aboul-Magd <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 14:05:40 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1154D.8F752A10
Content-Type: text/plain;
	charset="iso-8859-1"

Bilel,
 
I'm awfully sorry, I was just teasing you.  You had started things with your
assertion that LMP-WDM was slideware, but you're right, it was beneath me.
 
Incidentally, I think your note might have had more credibility if you'd
sent it privately. 
 
Thanks,
 
John 

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:48 PM
To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; [email-masked]'
Subject: RE: Optical Link Interface

 

However, NTIP addresses an immediate need and does not HAVE to be based on
LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.
However, as you pointed out, since NTIP is slideware, it can't be an
immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in
people's mouths -- Don't use that style with me!!  
try to stay professional

 

------_=_NextPart_001_01C1154D.8F752A10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001>Bilel,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=015020321-25072001>I'm 
awfully sorry, I was just teasing you.&nbsp; You had started things with 
your&nbsp;assertion that LMP-WDM was slideware, but you're right, it was beneath 
me.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001>Incidentally, I think your note might have had more 
credibility if you'd sent it privately.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=015020321-25072001>John&nbsp;</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 
  1:48 PM<BR><B>To:</B> 'John Drake'; 'Andre Fredette'; Osama 
  Aboul-Magd<BR><B>Cc:</B> 'Jonathan Lang'; 
  [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></DIV></FONT>
  <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
  size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
      class=180231720-25072001>However, NTIP addresses an immediate need and 
      does not HAVE to be based on LMP.<BR><SPAN class=514583420-25072001>[John 
      Drake]&nbsp;</SPAN></SPAN></FONT></FONT></FONT><FONT size=2><FONT 
      color=#0000ff><FONT face=Arial><SPAN class=180231720-25072001><SPAN 
      class=514583420-25072001></SPAN></SPAN></FONT></FONT></FONT></DIV>
      <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
      class=180231720-25072001><SPAN class=514583420-25072001>Well, there is a 
      immediate need for a protocol that can support the OLI.&nbsp; However, as 
      you pointed out, since NTIP is slideware, it can't be an immediate 
      solution to that immediate 
      need.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
      <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
      size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
      color=#0000ff face=Arial size=2>[Bilel Jamoussi] John, you have a bad 
      reputation of putting words in people's mouths -- Don't use that style 
      with me!!&nbsp; </FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
      color=#0000ff face=Arial size=2>try to stay 
      professional</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><FONT color=#0000ff face=Arial 
  size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1154D.8F752A10--

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jul 2001 14:05:22 -0700
Date: Wed, 25 Jul 2001 14:04:17 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: Optical Link Interface
Cc: [email-masked]

Hi Bilel,

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
> applications. The market has settled on RSVP-TE in ONE of the many MPLS
> applications -- namely Traffic Engineering of an IP network --

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

In an ideal world, CR-LDP as an extension of LDP would have been
the way to go.  It's funny that you should be arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) which nobody
needs anyway (read "TE is the only MPLS app").  Such is life ...

> The (I)SPs
> that deployed it did not have a choice from their vendors.

Guilty as charged.  We gave them black model Ts, and they liked them.
They didn't ask for any other colors, and aren't asking now, apart
from idle curiosity.

> Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The
> market prefers competing solutions to get the best of breed.

All the ISP folks that I know who had to make a choice say that
the process of choosing is mostly non-technical, and very much a
big pain.

The data I have indicates that the market wants competing
implementations of the same standard, not competing standards.
That's where the real value of "best of breed" lies.

Kireeti.

Delivery-date: Wed, 25 Jul 2001 14:02:28 -0700
Date: Wed, 25 Jul 2001 17:01:47 -0400
From: Vijay Gill <[email-masked]>
To: Bilel Jamoussi <[email-masked]>
cc: "'John Drake'" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, Osama Aboul-Magd <[email-masked]>, "'Jonathan Lang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface

On Wed, 25 Jul 2001, Bilel Jamoussi wrote:

>
>
> However, NTIP addresses an immediate need and does not HAVE to be based on
> LMP.
> [John Drake]
> Well, there is a immediate need for a protocol that can support the OLI.
> However, as you pointed out, since NTIP is slideware, it can't be an
> immediate solution to that immediate need.
>
> [Bilel Jamoussi] John, you have a bad reputation of putting words in
> people's mouths -- Don't use that style with me!!
> try to stay professional

Folks, lets try and keep this clean please.

Removing co-chair hat.

>From an operators perspective, I'd much rather that my vendors (and the
coders who have to code these protocols up), concentrate on implementation
and maintenance of fewer protocols. This tends to make the code robust and
the more robust code is (and we are all aware of the state of the software
in the internet), the fewer pages. The fewer pages I get, the happier I
am. The implementors have spoken on the NTIP vs LMP-DWDM, and as an
operator, I _will_ be spending money where I feel the most comfortable,
and as of now, I'm tending towards the implementors who think that
extension of LMP is easier for them than writing up NTIP from scratch.

Hat-on.

So lets try to quickly focus on the resolution of this issue. We've been
bickering back and forth over this for far too long.

thank you

/vijay

Delivery-date: Wed, 25 Jul 2001 13:58:29 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE
Date: Wed, 25 Jul 2001 13:57:23 -0700

Hi Tom,
        I am referring to the latest GMPLS signalling drafts.

http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt

Lou Berger has sent these drafts on ccamp mailing list.

Regards,
manoj.

>From: "Thomas D. Nadeau" <[email-masked]>
>To: "manoj juneja" <[email-masked]>, [email-masked]
>Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to  
>RSVP-TE
>Date: Wed, 25 Jul 2001 16:25:40 -0400
>
>
>         Which "GMPLS drafts" are you referring to?
>
>         --Tom
>
>>        I have a doubt related to recently included AdminStatus object in
>>GMPLS drafts. It states two reasons for including this object. In Ist
>>case, the usage of this object by ingress node in non-refresh path
>>message or by transit or egress node in the notify message before
>>deleting the LSP is fine. Is this to supress the alarm generation by
>>optical nodes as  loss of light will propagate faster than the tear down
>>signalling messages (Path/Resv Tear?
>>Can someone please explain me other reason to include this object in
>>PATH/RESV messages ? Is the use of this procedure only applicable prior to
>>LSP deletion ?
>>
>>Regards,
>>manoj.
>>
>>
>>
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 13:50:52 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 16:48:02 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1154B.18ECD7F0
Content-Type: text/plain;
	charset="iso-8859-1"

However, NTIP addresses an immediate need and does not HAVE to be based on
LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.
However, as you pointed out, since NTIP is slideware, it can't be an
immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in
people's mouths -- Don't use that style with me!!  
try to stay professional

 

------_=_NextPart_001_01C1154B.18ECD7F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2><FONT 
size=2></FONT></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=180231720-25072001>However, NTIP addresses an immediate need and does 
    not HAVE to be based on LMP.<BR><SPAN class=514583420-25072001>[John 
    Drake]&nbsp;</SPAN></SPAN></FONT></FONT></FONT><FONT size=2><FONT 
    color=#0000ff><FONT face=Arial><SPAN class=180231720-25072001><SPAN 
    class=514583420-25072001></SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=180231720-25072001><SPAN class=514583420-25072001>Well, there is a 
    immediate need for a protocol that can support the OLI.&nbsp; However, as 
    you pointed out, since NTIP is slideware, it can't be an immediate solution 
    to that immediate need.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff 
    size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
    face=Arial color=#0000ff size=2>[Bilel Jamoussi] John, you have a bad 
    reputation of putting words in people's mouths -- Don't use that style with 
    me!!&nbsp; </FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
    face=Arial color=#0000ff size=2>try to stay 
    professional</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=180231720-25072001><SPAN class=820564420-25072001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff 
size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1154B.18ECD7F0--

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jul 2001 13:40:02 -0700
Date: Wed, 25 Jul 2001 13:39:16 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: Optical Link Interface

Hi,

This email is as a router vendor/implementor.

The issues (so far) are:

a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.

   Subject to (c) below, I much prefer having to implement LMP
   (which I will have to) and add on the features needed for
   the OLI, rather than implement two different protocols.  The
   rationale is the same as was used when deciding to extend
   link state IGPs with TE information rather than do a new TE
   link state flooding protocol, or to do GMPLS as an extension
   of MPLS rather than develop a new optical signaling protocol.

b) Two protocols vs. one.

   One.

c) The model: master-slave vs. peer.

   I'm not qualified to speak here; this is the domain of the
   optical gurus.  However, I'll make two tangential points.  The
   first is that the answer seems to depend on the architecture
   of the component systems, which probably indicates that the
   protocol should do both.  The second is a piece of generic
   wisdom (?) that it is generally easier to add bells onto a
   peer-oriented protocol to deal with the master-slave case
   than to add whistles to a master-slave protocol to make it
   work in the peer case.

d) The transport protocol: TCP or raw over IP.

   It is my understanding that the PXC-WDM link is usually one IP
   hop; it seems that TCP is an overkill in that case.  Also,
   building failover capability for TCP-based protocols is rather
   more challenging.

   (Side note: both protocols can be made to work either way, so
   this is not so much of an NTIP-LMP_WDM issue as much as "what
   transport should OLI use?")

Kireeti.

Delivery-date: Wed, 25 Jul 2001 13:37:42 -0700
From: John Drake <[email-masked]>
To: 'Bilel Jamoussi' <[email-masked]>, 'Andre Fredette' <[email-masked]>, Osama Aboul-Magd <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 13:36:15 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11549.73284760
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:22 PM
To: 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; [email-masked]'
Subject: RE: Optical Link Interface

Andre, it's not that simple. You are not "using" LMP, you are extending LMP
to become a different protocol WDM-LMP.
[John Drake] 
This is simply not true.     
 
There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To
Come) -- I believe LMP fits here and the OLI solution should not be based on
LMP.
[John Drake] 
This is just rant

However, NTIP addresses an immediate need and does not HAVE to be based on
LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.
However, as you pointed out, since NTIP is slideware, it can't be an
immediate solution to that immediate need. 
 
Bilel.

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: 

        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 

Working Group chairs in Minnesota that only one protocol will progress in 

the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C11549.73284760
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
  size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 
  1:22 PM<BR><B>To:</B> 'Andre Fredette'; Osama Aboul-Magd<BR><B>Cc:</B> 
  'Jonathan Lang'; [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></FONT></DIV></FONT>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=180231720-25072001>Andre, it's not that simple. You are not "using" LMP, 
  you are extending LMP to become a different protocol WDM-LMP.<BR><SPAN 
  class=514583420-25072001>[John 
  Drake]&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=180231720-25072001><SPAN class=514583420-25072001>This is simply not 
  true.&nbsp; &nbsp; &nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=180231720-25072001><FONT face=Arial><FONT color=#0000ff 
  size=2>There is what Yakov calls </FONT></FONT><FONT size=2><FONT 
  color=#0000ff><FONT face=Arial>LTSFGTC (Long Term Solutions For Generations To 
  Come) -- I believe LMP fits here and the OLI solution should not be based on 
  LMP.<BR><SPAN class=514583420-25072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=180231720-25072001><FONT size=2><FONT color=#0000ff><FONT 
  face=Arial><SPAN class=514583420-25072001>This is just 
  rant</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
  size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=180231720-25072001>However, NTIP addresses an immediate need and does 
  not HAVE to be based on LMP.<BR><SPAN class=514583420-25072001>[John 
  Drake]&nbsp;</SPAN></SPAN></FONT></FONT></FONT><FONT size=2><FONT 
  color=#0000ff><FONT face=Arial><SPAN class=180231720-25072001><SPAN 
  class=514583420-25072001></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=180231720-25072001><SPAN class=514583420-25072001>Well, there is a 
  immediate need for a protocol that can support the OLI.&nbsp; However, as you 
  pointed out, since NTIP is slideware, it can't be an immediate solution to 
  that immediate need.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
  size=2><FONT size=2></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=180231720-25072001><FONT color=#0000ff face=Arial 
  size=2><FONT size=2>Bilel.</DIV></FONT></FONT></SPAN>
  <BLOCKQUOTE>
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Andre Fredette 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 2:11 
    PM<BR><B>To:</B> Aboul-Magd, Osama [CAR:1A00:EXCH]<BR><B>Cc:</B> Jonathan 
    Lang; [email-masked]<BR><B>Subject:</B> RE: Optical Link 
    Interface<BR><BR></FONT></DIV>Osama,<BR><BR>[Note: I tried to trim this note 
    down to the key arguments so that it is easier to follow.]<BR><BR>My main 
    argument (and I believe it is shared by the rest of the LMP-WDM co-authors) 
    is as follows:<BR>1. LMP exists.<BR>2. LMP solves most of the OLI problems, 
    <BR>3. Therefore, let's use LMP.<BR><BR>Osama's main argument is:<BR>1. I 
    don't think LMP should exist.<BR>2. Therefore let's create a new 
    protocol.<BR><BR>Given that the members of the working group have decided 
    that LMP will be developed, I don't think Osama's argument is 
    reasonable.<BR><BR>At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: 
    <BLOCKQUOTE class=cite type="cite" cite>
      <DL>
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[Osama] what 
        is the limitation here? Are you saying having a simple design is a 
        limitation? Not everything has to be complex. </FONT><FONT color=#0000ff 
        face=arial size=2></FONT><FONT color=#0000ff face=arial size=2>
        <DD>[Jonathan]&nbsp; Other DWDM vendors are not happy with the 
        master-slave model.&nbsp; Also, the claim that NTIP is simple is an 
        explicit assertion and you seem to be trying to make an implicit 
        assertion that LMP is complex. </FONT></DD></DL></BLOCKQUOTE>
    <DL></DL><BR>On the master-slave issue.&nbsp; There is clearly some 
    information that the line system does not need.&nbsp; For example, I don't 
    expect the Link Characteristics need to be advertised from OXC to OLS.&nbsp; 
    I think this works fine within the context of LMP.<BR><BR>You have made 
    claims of complexity, but have never been able to back them up with 
    fact.<BR><BR><BR>
    <BLOCKQUOTE class=cite type="cite" cite>
      <DL><FONT size=2>
        <DD>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs 
        and</FONT> <FONT size=2>
        <DD>Working Group chairs in Minnesota that only one protocol will 
        progress in</FONT> <FONT size=2>
        <DD>the IETF.</FONT> 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>
        <DD>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought 
        to this discussion. This is a completely different situation. LMP hasn't 
        seen the&nbsp; wide deployment that RSVP-TE has. The example is 
        inadequate.</FONT><FONT color=#0000ff face=arial size=2> <BR><BR>
        <DD>[Jonathan] CR-LDP and RSVP-TE were both being developed prior to 
        either one of them being widely deployed.&nbsp; The effort involved in 
        developing 2 protocols concurrently to do the same thing is widely 
        perceived as being counter productive. </FONT></DD></DL></BLOCKQUOTE>
    <DL></DL><BR>Given the choice between specifying and implementing two 
    protocols that do basically the same thing and one, I think the choice 
    should be clear.<BR><BR>Andre<BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11549.73284760--

Delivery-date: Wed, 25 Jul 2001 13:23:24 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Andre Fredette'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 16:22:02 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11547.772B9210
Content-Type: text/plain;
	charset="iso-8859-1"

Andre, it's not that simple. You are not "using" LMP, you are extending LMP
to become a different protocol WDM-LMP.
 
There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To
Come) -- I believe LMP fits here and the OLI solution should not be based on
LMP.
 
However, NTIP addresses an immediate need and does not HAVE to be based on
LMP.
 
Bilel.

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: 

        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 

Working Group chairs in Minnesota that only one protocol will progress in 

the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C11547.772B9210
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2>Andre, 
it's not that simple. You are not "using" LMP, you are extending LMP to become a 
different protocol WDM-LMP.</FONT></SPAN></DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2>There 
is what Yakov calls <FONT size=2>LTSFGTC (Long Term Solutions For Generations To 
Come) -- I believe LMP fits here and the OLI solution should not be based on 
LMP.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2><FONT 
size=2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2><FONT 
size=2>However, NTIP addresses an immediate need and does not HAVE to be based 
on LMP.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2><FONT 
size=2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=180231720-25072001><FONT face=Arial color=#0000ff size=2><FONT 
size=2>Bilel.</DIV></FONT></FONT></SPAN>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Andre Fredette 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 2:11 
  PM<BR><B>To:</B> Aboul-Magd, Osama [CAR:1A00:EXCH]<BR><B>Cc:</B> Jonathan 
  Lang; [email-masked]<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></FONT></DIV>Osama,<BR><BR>[Note: I tried to trim this note 
  down to the key arguments so that it is easier to follow.]<BR><BR>My main 
  argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is 
  as follows:<BR>1. LMP exists.<BR>2. LMP solves most of the OLI problems, 
  <BR>3. Therefore, let's use LMP.<BR><BR>Osama's main argument is:<BR>1. I 
  don't think LMP should exist.<BR>2. Therefore let's create a new 
  protocol.<BR><BR>Given that the members of the working group have decided that 
  LMP will be developed, I don't think Osama's argument is reasonable.<BR><BR>At 
  10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
  <BLOCKQUOTE class=cite cite type="cite">
    <DL>
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[Osama] what 
      is the limitation here? Are you saying having a simple design is a 
      limitation? Not everything has to be complex. </FONT><FONT face=arial 
      color=#0000ff size=2></FONT><FONT face=arial color=#0000ff size=2>
      <DD>[Jonathan]&nbsp; Other DWDM vendors are not happy with the 
      master-slave model.&nbsp; Also, the claim that NTIP is simple is an 
      explicit assertion and you seem to be trying to make an implicit assertion 
      that LMP is complex. </FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>On the master-slave issue.&nbsp; There is clearly some 
  information that the line system does not need.&nbsp; For example, I don't 
  expect the Link Characteristics need to be advertised from OXC to OLS.&nbsp; I 
  think this works fine within the context of LMP.<BR><BR>You have made claims 
  of complexity, but have never been able to back them up with fact.<BR><BR><BR>
  <BLOCKQUOTE class=cite cite type="cite">
    <DL><FONT size=2>
      <DD>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs 
      and</FONT> <FONT size=2>
      <DD>Working Group chairs in Minnesota that only one protocol will progress 
      in</FONT> <FONT size=2>
      <DD>the IETF.</FONT> 
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>
      <DD>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to 
      this discussion. This is a completely different situation. LMP hasn't seen 
      the&nbsp; wide deployment that RSVP-TE has. The example is 
      inadequate.</FONT><FONT face=arial color=#0000ff size=2> <BR><BR>
      <DD>[Jonathan] CR-LDP and RSVP-TE were both being developed prior to 
      either one of them being widely deployed.&nbsp; The effort involved in 
      developing 2 protocols concurrently to do the same thing is widely 
      perceived as being counter productive. </FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>Given the choice between specifying and implementing two 
  protocols that do basically the same thing and one, I think the choice should 
  be clear.<BR><BR>Andre<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11547.772B9210--

Delivery-date: Wed, 25 Jul 2001 13:21:19 -0700
Date: Wed, 25 Jul 2001 16:25:40 -0400
To: "manoj juneja" <[email-masked]>, [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE

         Which "GMPLS drafts" are you referring to?

         --Tom

>        I have a doubt related to recently included AdminStatus object in 
> GMPLS drafts. It states two reasons for including this object. In Ist 
> case, the usage of this object by ingress node in non-refresh path 
> message or by transit or egress node in the notify message before 
> deleting the LSP is fine. Is this to supress the alarm generation by 
> optical nodes as  loss of light will propagate faster than the tear down 
> signalling messages (Path/Resv Tear?
>Can someone please explain me other reason to include this object in 
>PATH/RESV messages ? Is the use of this procedure only applicable prior to 
>LSP deletion ?
>
>Regards,
>manoj.
>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jul 2001 13:18:57 -0700
Date: Wed, 25 Jul 2001 13:16:43 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: Optical Link Interface

Hi,

I wade into this discussion with trepidation.

I'll send out two mails.  This one is as a CCAMP co-chair, and
attempts to distill the issues so far.

This plane is the LMP-DWM vs. NTIP plane.  If you have other
travel plans, this would be an excellent time to disembark.

Both protocols satisfy the requirements.  Thanks to the authors
of the requirements draft to reach agreement on this!

The issues (so far) are:

a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.

   LMP-WDM is an extension of LMP, a reasonably mature protocol.
   NTIP is a new protocol.  These facts may mean it would take
   less time to standardize LMP-WDM than NTIP.  How relevant this
   is, I can't say.

b) Two protocols vs. one.

   NTIP and LMP-WDM are two protocols with one purpose.  I don't
   want two protocols with one purpose.  (As far as I understand,
   the ADs and the TA don't want two protocols with one purpose.)

   To make this crystal clear: LMP & NTIP is acceptable.  LMP &
   LMP-WDM is acceptable.  LMP-WDM & NTIP (with or without LMP)
   is not.

   "Let the market decide" is a final resort ... let's try not to
   go there.

c) The model: master-slave vs. peer.

   This is the key debate (in my opinion).  Is LMP-WDM a "natural
   extension of LMP", as Andre says; or is the master-slave model
   more appropriate in this context, as Osama says?

d) The transport protocol: TCP or raw over IP.

   Does the reliability of using TCP as transport offer a real
   advantage in this context?  Or do the complications of
   managing failover with TCP outweigh this benefit?

An aside: the issue of deployment keeps coming up.  The IETF does
not deploy protocols: it proposes standards.  Ideally, the proposed
standards meet requirements (from service providers!), which hopefully
indicates a willingness to deploy those proposals.  Deployment comes
into play when considering moving a proposed standard to standard
(and a standard to historic) -- but we are far from there.

If deployment was a criterion, the IETF would have killed CR-LDP a
long time ago, making the world a sadder, duller place, but making
my life (as implementor, draft writer and WG chair) much simpler.

Kireeti.

Delivery-date: Wed, 25 Jul 2001 13:18:06 -0700
From: John Drake <[email-masked]>
To: 'Bilel Jamoussi' <[email-masked]>, Jonathan Lang <[email-masked]>, Osama Aboul-Magd <[email-masked]>,  'Andre Fredette' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 13:15:45 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11546.95F91E70
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:05 PM
To: 'Jonathan Lang'; Osama Aboul-Magd; 'Andre Fredette';
[email-masked]'
Subject: RE: Optical Link Interface

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model

itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC 
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship 
suits this 
> interface better. 
I understand this limitation works for your product, but other WDM vendors 
have requested a more flexible model. 

[Bilel Jamoussi] The model can be very flexible when it's at the slideware
stage. 

[John Drake] Are you discussing NTIP? 

> - To link with other standards bodies, as far as I know T1X1, where the 
optical knowledge 
> exists, is yet to arrive to a definition of this interface. More 
contributions are 
> solicited to better understand its need and applications. Given that, I'd 
like to 
> understand the rationale for the "rough consensus" reached at CCAMP 
mailing list. Only 4-5 
> messages were posted to the mailing list and mostly from authors of the 
OLI requirements 
> draft. 
> - I don't see harm in having two protocols. The market made its decisions 
on the examples > you mentioned, and I am sure it will happen again in this 
case. 
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress in 
the IETF. 

[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been
talking to view this as a very healthy and competitive approach to have a
scalable and robust solution(s). Traffic Engineering an IP network (the only
application where RSVP-TE is deployed today) is a very narrow segment of the
MPLS/GMPLS applications market. 

Bilel. 

------_=_NextPart_001_01C11546.95F91E70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Bilel Jamoussi 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 
  1:05 PM<BR><B>To:</B> 'Jonathan Lang'; Osama Aboul-Magd; 'Andre Fredette'; 
  [email-masked]'<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></DIV></FONT><BR>
  <P><FONT size=2>&gt; - The issue is not really LMP vs TCP. NTIP and LMP-WDM 
  differ in the model</FONT> <BR><FONT size=2>itself. Your </FONT><BR><FONT 
  size=2>&gt; choice to use LMP to run LMP-WDM on top of it forced you to treat 
  the PXC</FONT> <BR><FONT size=2>and LS as peers. </FONT><BR><FONT size=2>&gt; 
  NTIP treats PXC-LS relationship as master-slave. Non peer relationship</FONT> 
  <BR><FONT size=2>suits this </FONT><BR><FONT size=2>&gt; interface 
  better.</FONT> <BR><FONT size=2>I understand this limitation works for your 
  product, but other WDM vendors</FONT> <BR><FONT size=2>have requested a more 
  flexible model.</FONT> </P>
  <P><FONT size=2>[Bilel Jamoussi] The model can be very flexible when it's at 
  the slideware stage.</FONT> </P><FONT size=2><FONT color=#0000ff><FONT 
  face=Arial><SPAN class=985261920-25072001>[John Drake]&nbsp;Are you discussing 
  NTIP?&nbsp;</SPAN><BR></FONT></FONT></FONT>
  <P><FONT size=2>&gt; - To link with other standards bodies, as far as I know 
  T1X1, where the</FONT> <BR><FONT size=2>optical knowledge </FONT><BR><FONT 
  size=2>&gt; exists, is yet to arrive to a definition of this interface. 
  More</FONT> <BR><FONT size=2>contributions are </FONT><BR><FONT size=2>&gt; 
  solicited to better understand its need and applications. Given that, 
  I'd</FONT> <BR><FONT size=2>like to </FONT><BR><FONT size=2>&gt; understand 
  the rationale for the "rough consensus" reached at CCAMP</FONT> <BR><FONT 
  size=2>mailing list. Only 4-5 </FONT><BR><FONT size=2>&gt; messages were 
  posted to the mailing list and mostly from authors of the</FONT> <BR><FONT 
  size=2>OLI requirements </FONT><BR><FONT size=2>&gt; draft.</FONT> <BR><FONT 
  size=2>&gt; - I don't see harm in having two protocols. The market made its 
  decisions</FONT> <BR><FONT size=2>on the examples &gt; you mentioned, and I am 
  sure it will happen again in this</FONT> <BR><FONT size=2>case.</FONT> 
  <BR><FONT size=2>Given the CR-LDP fiasco in MPLS, it was clearly stated by the 
  ADs and</FONT> <BR><FONT size=2>Working Group chairs in Minnesota that only 
  one protocol will progress in</FONT> <BR><FONT size=2>the IETF.</FONT> </P>
  <P><FONT size=2>[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I 
  have been talking to view this as a very healthy and competitive approach to 
  have a scalable and robust solution(s). Traffic Engineering an IP network (the 
  only application where RSVP-TE is deployed today) is a very narrow segment of 
  the MPLS/GMPLS applications market. </FONT></P>
  <P><FONT size=2>Bilel.</FONT> <BR><FONT size=2>&nbsp;</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11546.95F91E70--

Delivery-date: Wed, 25 Jul 2001 13:08:28 -0700
From: Andre Fredette <[email-masked]>
To: Bilel Jamoussi <[email-masked]>
Cc: 'John Drake' <[email-masked]>, Osama Aboul-Magd <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 25 Jul 2001 16:05:24 -0400
Subject: RE: Optical Link Interface

--=====================_25363020==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bilel,

In my experience, the market prefers a single standard with competing
implementations.

To quote Yakov from a recent post to the MPLS list, "The fact that in
the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is a
bug, and not a feature.", and "The same applies for MPLS signalling
(CR-LDP vs RSVP)."

Andre

At 03:55 PM 7/25/2001 -0400, Bilel Jamoussi wrote:

Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS --
The market prefers competing solutions to get the best of breed.

--=====================_25363020==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Bilel,<br><br>
In my experience, the market prefers a single standard with competing
implementations.<br><br>
To quote Yakov from a recent post to the MPLS list, &quot;The fact that
in the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is
a bug, and not a feature.&quot;, and &quot;The same applies for MPLS
signalling (CR-LDP vs RSVP).&quot;<br><br>
Andre<br><br>
At 03:55 PM 7/25/2001 -0400, Bilel Jamoussi wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Also,
the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The
market prefers competing solutions to get the best of
breed.</font></blockquote></html>

--=====================_25363020==_.ALT--

Delivery-date: Wed, 25 Jul 2001 13:07:28 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 16:04:39 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11545.091FCBD0
Content-Type: text/plain;
	charset="iso-8859-1"

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this 
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

[Bilel Jamoussi] The model can be very flexible when it's at the slideware
stage.

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge 
> exists, is yet to arrive to a definition of this interface. More
contributions are 
> solicited to better understand its need and applications. Given that, I'd
like to 
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5 
> messages were posted to the mailing list and mostly from authors of the
OLI requirements 
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.

[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been
talking to view this as a very healthy and competitive approach to have a
scalable and robust solution(s). Traffic Engineering an IP network (the only
application where RSVP-TE is deployed today) is a very narrow segment of the
MPLS/GMPLS applications market. 

Bilel.

------_=_NextPart_001_01C11545.091FCBD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; - The issue is not really LMP vs TCP. NTIP and =
LMP-WDM differ in the model</FONT>
<BR><FONT SIZE=3D2>itself. Your </FONT>
<BR><FONT SIZE=3D2>&gt; choice to use LMP to run LMP-WDM on top of it =
forced you to treat the PXC</FONT>
<BR><FONT SIZE=3D2>and LS as peers. </FONT>
<BR><FONT SIZE=3D2>&gt; NTIP treats PXC-LS relationship as =
master-slave. Non peer relationship</FONT>
<BR><FONT SIZE=3D2>suits this </FONT>
<BR><FONT SIZE=3D2>&gt; interface better.</FONT>
<BR><FONT SIZE=3D2>I understand this limitation works for your product, =
but other WDM vendors</FONT>
<BR><FONT SIZE=3D2>have requested a more flexible model.</FONT>
</P>

<P><FONT SIZE=3D2>[Bilel Jamoussi] The model can be very flexible when =
it's at the slideware stage.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; - To link with other standards bodies, as far as =
I know T1X1, where the</FONT>
<BR><FONT SIZE=3D2>optical knowledge </FONT>
<BR><FONT SIZE=3D2>&gt; exists, is yet to arrive to a definition of =
this interface. More</FONT>
<BR><FONT SIZE=3D2>contributions are </FONT>
<BR><FONT SIZE=3D2>&gt; solicited to better understand its need and =
applications. Given that, I'd</FONT>
<BR><FONT SIZE=3D2>like to </FONT>
<BR><FONT SIZE=3D2>&gt; understand the rationale for the &quot;rough =
consensus&quot; reached at CCAMP</FONT>
<BR><FONT SIZE=3D2>mailing list. Only 4-5 </FONT>
<BR><FONT SIZE=3D2>&gt; messages were posted to the mailing list and =
mostly from authors of the</FONT>
<BR><FONT SIZE=3D2>OLI requirements </FONT>
<BR><FONT SIZE=3D2>&gt; draft.</FONT>
<BR><FONT SIZE=3D2>&gt; - I don't see harm in having two protocols. The =
market made its decisions</FONT>
<BR><FONT SIZE=3D2>on the examples &gt; you mentioned, and I am sure it =
will happen again in this</FONT>
<BR><FONT SIZE=3D2>case.</FONT>
<BR><FONT SIZE=3D2>Given the CR-LDP fiasco in MPLS, it was clearly =
stated by the ADs and</FONT>
<BR><FONT SIZE=3D2>Working Group chairs in Minnesota that only one =
protocol will progress in</FONT>
<BR><FONT SIZE=3D2>the IETF.</FONT>
</P>

<P><FONT SIZE=3D2>[Bilel Jamoussi] There is no fiasco -- The ISPs and =
carriers I have been talking to view this as a very healthy and =
competitive approach to have a scalable and robust solution(s). Traffic =
Engineering an IP network (the only application where RSVP-TE is =
deployed today) is a very narrow segment of the MPLS/GMPLS applications =
market. </FONT></P>

<P><FONT SIZE=3D2>Bilel.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11545.091FCBD0--

Delivery-date: Wed, 25 Jul 2001 13:06:00 -0700
From: Andre Fredette <[email-masked]>
To: Hamid Ould-Brahim <[email-masked]>
Cc: Osama Aboul-Magd <[email-masked]>, Jonathan Lang <[email-masked]>, ccamp <[email-masked]>
Date: Wed, 25 Jul 2001 15:59:14 -0400
Subject: RE: Optical Link Interface

--=====================_24992897==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:

Andre,

 
Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP. 
 
Osama's main argument is:
1. I don't think LMP should exist. 
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will
be developed, I don't think Osama's argument is reasonable. 
 
We went through that before and the WG has decided to make 
explicit the clarification that the issue is just between 
LMP-WDM and NTIP and not between LMP and NTIP. 

The whole point of LMP-WDM is to use an existing protocol to solve a new
problem rather than create a new protocol just for the sake of creating
a new one.  If there is a technical argument against using LMP for this
problem, let's hear it!

 
Besides that I think that some of the arguments 
advanced are:
 
1. The issue is not how many protocols need to be advanced.

This is a significant issue.

 
2. The choice of advancing a given protocol should be 
   influenced by whether it is deployed or likely to be 
   widely deployed. And this applies even in the case
   of one single protocol. 
 
3. No matter what protocol(s) is/are selected,
   it is the market who makes the final decision.
 
Hamid. 

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what is the limitation here? Are you saying having a
simple design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave
model.  Also, the claim that NTIP is simple is an explicit assertion and
you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the
line system does not need.  For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.  I think this
works fine within the context of LMP.

You have made claims of complexity, but have never been able to back
them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 

Working Group chairs in Minnesota that only one protocol will progress
in 

the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to
this discussion. This is a completely different situation. LMP hasn't
seen the  wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either
one of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that
do basically the same thing and one, I think the choice should be clear.

Andre

--=====================_24992897==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:<br>
<blockquote type=cite class=cite cite><font face="Courier New, Courier" size=2 color="#0000FF">Andre,</font><br>
<blockquote type=cite class=cite cite><font face="tahoma" size=2>&nbsp;<br>
</font>Osama,<br><br>
[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]<br><br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<font face="arial" size=2 color="#0000FF">
</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;<br>
</font>Osama's main argument is:<br>
1. I don't think LMP should
exist.<font face="arial" size=2 color="#0000FF"> </font><br>
2. Therefore let's create a new protocol.<br><br>
Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is
reasonable.<font face="arial" size=2 color="#0000FF"> </font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;</font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">We went through
that before and the WG has decided to make </font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">explicit the
clarification that the issue is just between </font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">LMP-WDM and NTIP
and not between LMP and NTIP.</font> </blockquote></blockquote><br>
The whole point of LMP-WDM is to use an existing protocol to solve a new
problem rather than create a new protocol just for the sake of creating a
new one.&nbsp; If there is a technical argument against using LMP for
this problem, let's hear it!<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">Besides that I
think that some of the arguments </font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">advanced
are:</font><br>
&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">1. The issue is
not how many protocols need to be
advanced.</font></blockquote></blockquote><br>
This is a significant issue.<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">2. The choice of
advancing a given protocol should be </font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">&nbsp;&nbsp;
influenced by whether it is deployed or likely to be </font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">&nbsp;&nbsp;
widely deployed. And this applies even in the case</font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">&nbsp;&nbsp; of
one single protocol. </font><br>
&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">3. No matter
what protocol(s) is/are selected,</font><br>
<font face="Courier New, Courier" size=2 color="#0000FF">&nbsp;&nbsp; it
is the market who makes the final decision.</font><br>
&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">Hamid.</font>
<br><br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:<blockquote type=cite class=cite cite>
<dl>
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=2>[Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. </font><font face="arial" size=2 color="#0000FF">
<dd>[Jonathan]&nbsp; Other DWDM vendors are not happy with the master-slave model.&nbsp; Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. </font>
</dl></blockquote><br>
On the master-slave issue.&nbsp; There is clearly some information that the line system does not need.&nbsp; For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.&nbsp; I think this works fine within the context of LMP.<br><br>
You have made claims of complexity, but have never been able to back them up with fact.<br><br>
<blockquote type=cite class=cite cite>
<dl><font size=2>
<dd>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and</font> <font size=2>
<dd>Working Group chairs in Minnesota that only one protocol will progress in</font> <font size=2>
<dd>the IETF.</font> 
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=2>
<dd>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the&nbsp; wide deployment that RSVP-TE has. The example is inadequate.</font><font face="arial" size=2 color="#0000FF"> <br><br>

<dd>[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.&nbsp; The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. </font>
</dl></blockquote><br>
Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.<br><br>
Andre</blockquote></blockquote></html>

--=====================_24992897==_.ALT--

Delivery-date: Wed, 25 Jul 2001 12:58:11 -0700
From: "Bilel Jamoussi" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>, "'Andre Fredette'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 15:55:03 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11543.B1EA29B0
Content-Type: text/plain;
	charset="iso-8859-1"

[Osama]  - I don't see harm in having two protocols. The market made its
decisions on the examples you mentioned, and I am sure it will happen again
in this case.
[John Drake] The market has settled on RSVP-TE, so there's clearly an
existence proof that that the market prefers a single solution 

[Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
applications. The market has settled on RSVP-TE in ONE of the many MPLS
applications -- namely Traffic Engineering of an IP network -- The (I)SPs
that deployed it did not have a choice from their vendors.

Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The
market prefers competing solutions to get the best of breed.

Bilel.

------_=_NextPart_001_01C11543.B1EA29B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.50.4308.2900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><SPAN class=610434619-25072001><FONT face=Arial 
color=#0000ff>[Osama] &nbsp;</FONT></SPAN>- I don't see harm in having two 
protocols. The market made its decisions on the examples you mentioned, and I am 
sure it will happen again in this case.<BR><SPAN class=297424515-25072001><FONT 
face=Arial><FONT color=#0000ff>[John Drake]<SPAN 
class=610434619-25072001>&nbsp;</SPAN></FONT></FONT></SPAN><FONT face=Arial 
color=#0000ff><SPAN class=297424515-25072001>The market has settled on RSVP-TE, 
so there's&nbsp;clearly an existence proof that&nbsp;that the market prefers a 
single solution&nbsp;</SPAN></FONT></FONT></DIV>
<P dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN 
class=610434619-25072001>[Bilel Jamoussi] </SPAN></FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=610434619-25072001>John, you seem to have a 
very narrow view of MPLS applications. The market has settled on RSVP-TE in ONE 
of the many MPLS applications -- namely Traffic Engineering of an IP network -- 
The (I)SPs that deployed it did not have a choice from their 
vendors.</SPAN></FONT></P>
<P dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN 
class=610434619-25072001>Also, the market has 2 routing protocols in the IGP: 
OSPF and IS-IS -- The market prefers competing solutions to get the best of 
breed.</SPAN></FONT></P>
<P dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN 
class=610434619-25072001>Bilel.</SPAN></FONT></P>
<P dir=ltr><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</P></BODY></HTML>

------_=_NextPart_001_01C11543.B1EA29B0--

Delivery-date: Wed, 25 Jul 2001 12:52:01 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE
Date: Wed, 25 Jul 2001 12:49:47 -0700

Hi All,
        I have a doubt related to recently included AdminStatus object in 
GMPLS drafts. It states two reasons for including this object. In Ist case, 
the usage of this object by ingress node in non-refresh path message or by 
transit or egress node in the notify message before deleting the LSP is 
fine. Is this to supress the alarm generation by optical nodes as  loss of 
light will propagate faster than the tear down signalling messages 
(Path/Resv Tear?
Can someone please explain me other reason to include this object in 
PATH/RESV messages ? Is the use of this procedure only applicable prior to 
LSP deletion ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 12:48:56 -0700
From: Andre Fredette <[email-masked]>
To: Osama Aboul-Magd <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Date: Wed, 25 Jul 2001 15:46:34 -0400
Subject: RE: Optical Link Interface

--=====================_24232704==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Comments inline. 

At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:

Andre,

This is a misrepresentation of my argument. 
My argument is:
- LMP is at best optional. 

This is your opinion.  The members of the CCAMP working group have
decided that LMP is useful and needs to be specified.

Not everyone is going to implement it. 
- Let's not try to force it on everyone.

The way I read this is that you don't plan to implement LMP, so you want
to make it harder for those that do?

Therefore your argument to use LMP is not reasonable.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

-----Original Message-----
From: Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will
be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what is the limitation here? Are you saying having a
simple design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave
model.  Also, the claim that NTIP is simple is an explicit assertion and
you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the
line system does not need.  For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.  I think this
works fine within the context of LMP.

You have made claims of complexity, but have never been able to back
them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress
in 
the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to
this discussion. This is a completely different situation. LMP hasn't
seen the  wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either
one of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that
do basically the same thing and one, I think the choice should be clear.

Andre

--=====================_24232704==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Comments inline. <br><br>
At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#000080">Andre,<br>
</font><br>
<font face="arial" size=2 color="#000080">This is a misrepresentation of
my argument. <br>
My argument is:<br>
- LMP is at best optional. </font></blockquote><br>
This is your opinion.&nbsp; The members of the CCAMP working group have
decided that LMP is useful and needs to be specified.<br><br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#000080">Not
everyone is going to implement it. <br>
- Let's not try to force it on everyone.</font></blockquote><br>
The way I read this is that you don't plan to implement LMP, so you want
to make it harder for those that do?<br><br>
<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#000080">Therefore
your argument to use LMP is not reasonable.<br>
</font><br>
<font face="arial" size=2 color="#000080">Regards;<br>
</font><br>
<font face="Arial Black, Helvetica" color="#3366FF">Osama 
Aboul-Magd<br>
</font><font face="Times New Roman, Times" color="#000080">Nortel
Networks<br>
P.O. Box 3511, Station &quot;C&quot;<br>
Ottawa, ON, Canada<br>
K1Y - 4H7<br>
Tel: 613-763-5827<br>
e.mail: [email-masked]<br>
</font><br>
<font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> Andre Fredette
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
<b>Sent:</b> Wednesday, July 25, 2001 2:11 PM<br>
<b>To:</b> Aboul-Magd, Osama [CAR:1A00:EXCH]<br>
<b>Cc:</b> Jonathan Lang; [email-masked]<br>
<b>Subject:</b> RE: Optical Link Interface<br>
</font><br>
<font face="Times New Roman, Times">Osama,<br><br>
[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]<br><br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<br><br>
Osama's main argument is:<br>
1. I don't think LMP should exist.<br>
2. Therefore let's create a new protocol.<br><br>
Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.<br><br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:<br>
</font><br>
<font face="Times New Roman, Times">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2>[Osama] what is the limitation here? Are you saying
having a simple design is a limitation? Not everything has to be complex.
<br>
</font><br>
<font face="arial" size=2 color="#0000FF">[Jonathan]&nbsp; Other DWDM
vendors are not happy with the master-slave model.&nbsp; Also, the claim
that NTIP is simple is an explicit assertion and you seem to be trying to
make an implicit assertion that LMP is complex. <br>
</font><font face="Times New Roman, Times"><br>
On the master-slave issue.&nbsp; There is clearly some information that
the line system does not need.&nbsp; For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.&nbsp; I think this
works fine within the context of LMP.<br><br>
You have made claims of complexity, but have never been able to back them
up with fact.<br><br>
</font><font face="Times New Roman, Times" size=2>Given the CR-LDP fiasco
in MPLS, it was clearly stated by the ADs and</font> <br>
<font face="Times New Roman, Times" size=2>Working Group chairs in
Minnesota that only one protocol will progress in</font> <br>
<font face="Times New Roman, Times" size=2>the IETF.</font> <br>
<br>
<font face="Times New Roman, Times" size=2>[Osama] I don't understand why
CR-LDP and RSVP-TE have been brought to this discussion. This is a
completely different situation. LMP hasn't seen the&nbsp; wide deployment
that RSVP-TE has. The example is
inadequate.</font><font face="arial" size=2 color="#0000FF"> <br>
</font><br>
<font face="arial" size=2 color="#0000FF">[Jonathan] CR-LDP and RSVP-TE
were both being developed prior to either one of them being widely
deployed.&nbsp; The effort involved in developing 2 protocols
concurrently to do the same thing is widely perceived as being counter
productive. <br>
</font><font face="Times New Roman, Times"><br>
Given the choice between specifying and implementing two protocols that
do basically the same thing and one, I think the choice should be
clear.<br><br>
Andre</font></blockquote></html>

--=====================_24232704==_.ALT--

Delivery-date: Wed, 25 Jul 2001 12:45:55 -0700
From: "Hamid Ould-Brahim" <[email-masked]>
To: Andre Fredette <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 15:40:56 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_003F_01C11520.31C95760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Andre,

  Osama,

  [Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

  My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
  1. LMP exists.
  2. LMP solves most of the OLI problems,
  3. Therefore, let's use LMP.

  Osama's main argument is:
  1. I don't think LMP should exist.
  2. Therefore let's create a new protocol.

  Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

  We went through that before and the WG has decided to make
  explicit the clarification that the issue is just between
  LMP-WDM and NTIP and not between LMP and NTIP.

  Besides that I think that some of the arguments
  advanced are:

  1. The issue is not how many protocols need to be advanced.

  2. The choice of advancing a given protocol should be
     influenced by whether it is deployed or likely to be
     widely deployed. And this applies even in the case
     of one single protocol.

  3. No matter what protocol(s) is/are selected,
     it is the market who makes the final decision.

  Hamid.

  At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
              [Osama] what is the limitation here? Are you saying having a
simple design is a limitation? Not everything has to be complex.
      [Jonathan]  Other DWDM vendors are not happy with the master-slave
model.  Also, the claim that NTIP is simple is an explicit assertion and you
seem to be trying to make an implicit assertion that LMP is complex.

  On the master-slave issue.  There is clearly some information that the
line system does not need.  For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.  I think this works
fine within the context of LMP.

  You have made claims of complexity, but have never been able to back them
up with fact.

      Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
      Working Group chairs in Minnesota that only one protocol will progress
in
      the IETF.

      [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to
this discussion. This is a completely different situation. LMP hasn't seen
the  wide deployment that RSVP-TE has. The example is inadequate.

      [Jonathan] CR-LDP and RSVP-TE were both being developed prior to
either one of them being widely deployed.  The effort involved in developing
2 protocols concurrently to do the same thing is widely perceived as being
counter productive.

  Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

  Andre

------=_NextPart_000_003F_01C11520.31C95760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
class=3D270401818-25072001>Andre,</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>&nbsp;</DIV>
  <DIV></FONT>Osama,<BR><BR>[Note: I tried to trim this note down to the =
key=20
  arguments so that it is easier to follow.]<BR><BR>My main argument =
(and I=20
  believe it is shared by the rest of the LMP-WDM co-authors) is as=20
  follows:<BR>1. LMP exists.<BR>2. LMP solves most of the OLI problems, =
<BR>3.=20
  Therefore, let's use LMP.<SPAN class=3D270401818-25072001><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2>
  <DIV>&nbsp;</DIV></FONT></DIV>
  <DIV>Osama's main argument is:<BR>1. I don't think LMP should =
exist.<SPAN=20
  class=3D270401818-25072001><FONT color=3D#0000ff face=3DArial=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV>2. Therefore let's create a new protocol.<BR><BR>Given that the =
members=20
  of the working group have decided that LMP will be developed, I don't =
think=20
  Osama's argument is reasonable.<SPAN class=3D270401818-25072001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D270401818-25072001></SPAN><SPAN=20
  class=3D270401818-25072001><FONT color=3D#0000ff face=3DArial=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D270401818-25072001><FONT color=3D#0000ff =
face=3D"Courier New"=20
  size=3D2>We went through that before and the WG has decided to make=20
  </FONT></SPAN></DIV>
  <DIV><SPAN class=3D270401818-25072001><FONT color=3D#0000ff =
face=3D"Courier New"=20
  size=3D2>explicit th</FONT></SPAN><SPAN =
class=3D270401818-25072001><FONT=20
  color=3D#0000ff face=3D"Courier New" size=3D2>e clarification that the =
issue is just=20
  between </FONT></SPAN></DIV>
  <DIV><SPAN class=3D270401818-25072001><FONT color=3D#0000ff =
face=3D"Courier New"=20
  size=3D2>LMP-WDM and NTIP and not</FONT></SPAN><SPAN=20
  class=3D270401818-25072001><FONT color=3D#0000ff face=3D"Courier New" =
size=3D2>=20
  between LMP and NTIP</FONT></SPAN><SPAN =
class=3D270401818-25072001><FONT=20
  color=3D#0000ff face=3D"Courier New" =
size=3D2>.</FONT>&nbsp;</SPAN></DIV>
  <DIV><SPAN class=3D270401818-25072001></SPAN>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>Besides that I think that some of the =
arguments=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>advanced are</SPAN></FONT><FONT =
color=3D#0000ff=20
  face=3D"Courier New" size=3D2><SPAN =
class=3D270401818-25072001>:</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>1. The issue is not how many protocols=20
  </SPAN></FONT><FONT color=3D#0000ff face=3D"Courier New" =
size=3D2><SPAN=20
  class=3D270401818-25072001>need to be advanced.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>2. The choice of advancing a given protocol =
should be=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>&nbsp;&nbsp; influenced by =
whether</SPAN></FONT><FONT=20
  color=3D#0000ff face=3D"Courier New" size=3D2><SPAN =
class=3D270401818-25072001> it is=20
  deployed or likely to be </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>&nbsp;&nbsp; widely =
deployed.</SPAN></FONT><FONT=20
  color=3D#0000ff face=3D"Courier New" size=3D2><SPAN =
class=3D270401818-25072001> And=20
  this applies even in the case</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>&nbsp;&nbsp; of one single=20
  protocol</SPAN></FONT><FONT color=3D#0000ff face=3D"Courier New" =
size=3D2><SPAN=20
  class=3D270401818-25072001>.&nbsp;</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>3. No matter what protocol(s)&nbsp;is/are=20
  selected,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D"Courier New" size=3D2><SPAN=20
  class=3D270401818-25072001>&nbsp;&nbsp; it is the =
market</SPAN></FONT><FONT=20
  color=3D#0000ff face=3D"Courier New" size=3D2><SPAN =
class=3D270401818-25072001> who=20
  makes the final decision</SPAN></FONT><FONT color=3D#0000ff =
face=3D"Courier New"=20
  size=3D2><SPAN class=3D270401818-25072001>.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><SPAN class=3D270401818-25072001><FONT size=3D2><FONT =
color=3D#0000ff=20
  face=3D"Courier New">Hamid.</FONT></FONT>&nbsp;</SPAN><BR><BR>At 10:41 =
AM=20
  7/25/2001 -0700, Jonathan Lang wrote:</DIV>
  <BLOCKQUOTE class=3Dcite cite type=3D"cite">
    <DL>
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>[Osama] what=20
      is the limitation here? Are you saying having a simple design is a =

      limitation? Not everything has to be complex. </FONT><FONT =
color=3D#0000ff=20
      face=3Darial size=3D2></FONT><FONT color=3D#0000ff face=3Darial =
size=3D2>
      <DD>[Jonathan]&nbsp; Other DWDM vendors are not happy with the=20
      master-slave model.&nbsp; Also, the claim that NTIP is simple is =
an=20
      explicit assertion and you seem to be trying to make an implicit =
assertion=20
      that LMP is complex. </FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>On the master-slave issue.&nbsp; There is clearly some=20
  information that the line system does not need.&nbsp; For example, I =
don't=20
  expect the Link Characteristics need to be advertised from OXC to =
OLS.&nbsp; I=20
  think this works fine within the context of LMP.<BR><BR>You have made =
claims=20
  of complexity, but have never been able to back them up with =
fact.<BR><BR><BR>
  <BLOCKQUOTE class=3Dcite cite type=3D"cite">
    <DL><FONT size=3D2>
      <DD>Given the CR-LDP fiasco in MPLS, it was clearly stated by the =
ADs=20
      and</FONT> <FONT size=3D2>
      <DD>Working Group chairs in Minnesota that only one protocol will =
progress=20
      in</FONT> <FONT size=3D2>
      <DD>the IETF.</FONT>=20
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>
      <DD>[Osama] I don't understand why CR-LDP and RSVP-TE have been =
brought to=20
      this discussion. This is a completely different situation. LMP =
hasn't seen=20
      the&nbsp; wide deployment that RSVP-TE has. The example is=20
      inadequate.</FONT><FONT color=3D#0000ff face=3Darial size=3D2> =
<BR><BR>
      <DD>[Jonathan] CR-LDP and RSVP-TE were both being developed prior =
to=20
      either one of them being widely deployed.&nbsp; The effort =
involved in=20
      developing 2 protocols concurrently to do the same thing is widely =

      perceived as being counter productive. =
</FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>Given the choice between specifying and implementing two=20
  protocols that do basically the same thing and one, I think the choice =
should=20
  be clear.<BR><BR>Andre<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003F_01C11520.31C95760--

Delivery-date: Wed, 25 Jul 2001 12:27:05 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Label Set and Suggested Label
Date: Wed, 25 Jul 2001 12:26:00 -0700

Hi All,
     Please ignore the previous mail (because of some typo errors).

Is label set really useful in TDM domain ? I think if the
upstream node wants to select only one label in the label set, it can
very well use the explicit label control procedure. What are other
benefits of having label set in TDM domain ? I can very well understand the 
use of label set for LSC and FSC interfaces where label ranges make
sense. Do label ranges make sense in TDM domain ?

Regards,
manoj.

>From: Eric Gray <[email-masked]>
>To: Suresh Katukam <[email-masked]>
>CC: [email-masked]
>Subject: Re: Label Set and Suggested Label
>Date: Mon, 02 Jul 2001 09:44:00 -0400
>
>Suresh,
>
>     Unfortunately, the current wording is:
>
>"There are four cases where a Label Set is useful in the optical domain."
>
>It is arguable that your examples are more properly in the TDM  domain,
>but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not
>seem to leave much room for generalizing the label set in this way.  It
>should probably say either that these are examples that apply to the
>optical domain (other uses may exist for other domains) or - better -
>still it should simply state these as a few examples and leave it at that.
>
>     There is nothing to be gained by guessing what the authors meant -
>they must make it clear.
>
>--
>Eric Gray
>
>You wrote:
>
> > Manoj,
> >
> > >         In the GMPLS drafts, it is mentioned that the use of label set
> > > is in the following cases :
> > >
> > >            a) End equipment is only capable of transmitting and
> > >               receiving on a small set of wavelengths.
> > >            b) There are sequence of interfaces which can't support
> > >               wavelength conversion.
> > >            c) It is desireable to limit the amount of wavelength
> > >               conversion to reduce the distortion on the optical
> > >               signals.
> > >            d) Two ends of a link support different sets of 
>wavelengths.
> > >
> > > All the above four points are valid only in case LSP encoding type is
> > > lambda. Does this mean if a label set is received in cases where LSP
> > > encoding type is other than Lambda, it should be ignored or considered
> > > protocol error ?
> >
> > I am not sure whether it is the intention of GMPLS authors to list
> > all possible scenerios under which a label set is used. There are
> > other scenerios under which label set can be used. In TDM, for example,
> > one may want to use same time slot (for BLSRs) assigned along the
> > entire BLSR segment. In such a scenerio, BLSR headend lists all 
>available
> > labels and forwards the PATH message. Each node in BLSR knows what
> > label to use when it receives a RESV message.
> >
> > There may be other reasons too. In anycase, you should not consider
> > that to be a protocol error.
> >
> > Thanks,
> > Suresh
> > >
> > > What about the suggested Label ? Is it also defined to take care of
> > > specific LSP encoding type ?
> > >
> > > Please Clarify.
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 12:09:35 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Label Set and Suggested Label
Date: Wed, 25 Jul 2001 12:08:23 -0700

Hi All,
       Is label set realy useful in TDM domain ? I think if the
upstream node wants to select only one label in the label set, it can
very well use the explicit label control procedure. What are other
benefits of having label set in TDM domain ? I can very understand the
use of label set for LSC and FSC interfaces where label ranges make
sense.

Regards,
manoj.

>From: Eric Gray <[email-masked]>
>To: Suresh Katukam <[email-masked]>
>CC: [email-masked]
>Subject: Re: Label Set and Suggested Label
>Date: Mon, 02 Jul 2001 09:44:00 -0400
>
>Suresh,
>
>     Unfortunately, the current wording is:
>
>"There are four cases where a Label Set is useful in the optical domain."
>
>It is arguable that your examples are more properly in the TDM  domain,
>but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not
>seem to leave much room for generalizing the label set in this way.  It
>should probably say either that these are examples that apply to the
>optical domain (other uses may exist for other domains) or - better -
>still it should simply state these as a few examples and leave it at that.
>
>     There is nothing to be gained by guessing what the authors meant -
>they must make it clear.
>
>--
>Eric Gray
>
>You wrote:
>
> > Manoj,
> >
> > >         In the GMPLS drafts, it is mentioned that the use of label set
> > > is in the following cases :
> > >
> > >            a) End equipment is only capable of transmitting and
> > >               receiving on a small set of wavelengths.
> > >            b) There are sequence of interfaces which can't support
> > >               wavelength conversion.
> > >            c) It is desireable to limit the amount of wavelength
> > >               conversion to reduce the distortion on the optical
> > >               signals.
> > >            d) Two ends of a link support different sets of 
>wavelengths.
> > >
> > > All the above four points are valid only in case LSP encoding type is
> > > lambda. Does this mean if a label set is received in cases where LSP
> > > encoding type is other than Lambda, it should be ignored or considered
> > > protocol error ?
> >
> > I am not sure whether it is the intention of GMPLS authors to list
> > all possible scenerios under which a label set is used. There are
> > other scenerios under which label set can be used. In TDM, for example,
> > one may want to use same time slot (for BLSRs) assigned along the
> > entire BLSR segment. In such a scenerio, BLSR headend lists all 
>available
> > labels and forwards the PATH message. Each node in BLSR knows what
> > label to use when it receives a RESV message.
> >
> > There may be other reasons too. In anycase, you should not consider
> > that to be a protocol error.
> >
> > Thanks,
> > Suresh
> > >
> > > What about the suggested Label ? Is it also defined to take care of
> > > specific LSP encoding type ?
> > >
> > > Please Clarify.
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 12:00:27 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: John Drake <[email-masked]>, "'Andre Fredette'" <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 14:58:53 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1153B.D908C950
Content-Type: text/plain;
	charset="iso-8859-1"

John,
 
I think it is unacceptable to misrepresent private conversations. Please
stick to the issues.
 
Regards;
 
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]
 
-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 2:37 PM
To: 'Andre Fredette'; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface
 
As an aside, the LMP-WDM and NTIP authors did have several phone conferences
prior to the last IETF, and the NTIP authors indicated that folding the
contents of LMP-WDM draft into the NTIP draft would be an acceptable
solution to them.  Presumably this would allow it to be called NTIP.
 Since then, they've also indicated that the LMP-WDM protocol is fine, but
it can't have the letters LMP in its name.
Thanks,
John 
-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:11 AM
To: 'Osama Aboul-Magd'
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface
Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: 
        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress in 
the IETF. 
        
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 
[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C1153B.D908C950
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>J=
ohn,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
 think it
is unacceptable to misrepresent private conversations. Please stick to =
the
issues.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>R=
egards;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><font
color=3D"#3366ff" face=3D"Arial Black"><span =
style=3D'font-family:"Arial Black";
color:#3366FF'>Osama Aboul-Magd</span></font><font color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Nortel =
Networks</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>P.O. Box 3511, Station =
&quot;C&quot;</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Ottawa, ON, =
Canada</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>K1Y - 4H7</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Tel: =
613-763-5827</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>e.mail: =
[email-masked]</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle16><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> John Drake
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
2:37 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Andre Fredette'; =
Aboul-Magd,
Osama [CAR:1A00:EXCH]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Jonathan Lang;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>As an aside, the LMP-WDM and =
NTIP authors
did have several phone conferences prior to the last IETF, and the NTIP =
authors
indicated that folding the contents of LMP-WDM draft into the NTIP =
draft would
be an acceptable solution to them.&nbsp; Presumably this would allow it =
to be
called NTIP.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;Since then, they've also =
indicated
that the LMP-WDM protocol is fine, but it can't have the letters LMP in =
its
name.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>John&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
margin-bottom:12.0pt;margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Andre Fredette
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
11:11 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Osama =
Aboul-Magd'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Jonathan Lang;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black;mso-color-alt:w=
indowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>Osama,<br>
<br>
[Note: I tried to trim this note down to the key arguments so that it =
is easier
to follow.]<br>
<br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<br>
<br>
Osama's main argument is:<br>
1. I don't think LMP should exist.<br>
2. Therefore let's create a new protocol.<br>
<br>
Given that the members of the working group have decided that LMP will =
be
developed, I don't think Osama's argument is reasonable.<br>
<br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>[Osama] what is the limitation here? Are you saying having =
a
simple design is a limitation? Not everything has to be complex. =
</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>[Jonathan]&nbsp; Other DWDM vendors are not happy with the
master-slave model.&nbsp; Also, the claim that NTIP is simple is an =
explicit
assertion and you seem to be trying to make an implicit assertion that =
LMP is
complex. </span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
On the master-slave issue.&nbsp; There is clearly some information that =
the
line system does not need.&nbsp; For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.&nbsp; I think =
this works
fine within the context of LMP.<br>
<br>
You have made claims of complexity, but have never been able to back =
them up
with fact.<br>
<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>Given
the CR-LDP fiasco in MPLS, it was clearly stated by the ADs =
and</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black;mso-color-alt:windowtext'><o:p></o=
:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>Working
Group chairs in Minnesota that only one protocol will progress =
in</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black;mso-color-alt:windowtext'><o:p></o=
:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>the
IETF.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:12.0pt;margin-left:72.0pt'><font size=3D2 color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>[Osama] I
don't understand why CR-LDP and RSVP-TE have been brought to this =
discussion.
This is a completely different situation. LMP hasn't seen the&nbsp; =
wide
deployment that RSVP-TE has. The example is =
inadequate.</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'> <o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:72.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>[Jonathan] CR-LDP and RSVP-TE were both being developed =
prior to
either one of them being widely deployed.&nbsp; The effort involved in
developing 2 protocols concurrently to do the same thing is widely =
perceived as
being counter productive. </span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'margin-right:36.0pt;mso-margin-top-alt:auto;
mso-margin-bottom-alt:auto;margin-left:72.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
Given the choice between specifying and implementing two protocols that =
do
basically the same thing and one, I think the choice should be =
clear.<br>
<br>
Andre</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1153B.D908C950--

Delivery-date: Wed, 25 Jul 2001 11:56:08 -0700
content-class: urn:content-classes:message
Subject: RE: Queries regarding LMP.
Date:  Wed, 25 Jul 2001 14:55:14 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Zhi-Wei,

As soon as there are O-O-O nodes (all optical) inside the network, there
needs to be a procedure for fault isolation, regardless if there are OEO
nodes at the edge. LMP provides such fault isolation mechanism. If the
fault isolation procedure in LMP is not used, the vendor has to come up
with its own proprietary mechanism.

For SONET gears, as you point out, there is no need for this procedure
since this technology has mechanisms to deal with fault isolation.

Martin

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 12:35 PM
To: Martin Dubuc
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Queries regarding LMP.

Hi Martin, comments in-line

Martin Dubuc wrote:
>=20
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring
of
> control and data link health. To determine whether LMP is useful or
not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to
facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link
failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).

When you say "truly optical network", do you mean a network that has no
O/E/O (no 3R) at all? or is there some 3R at the edge?

As for mechanisms to isolate faults, I think this capability is already
part of networks. For example, SONET has mechanisms such as trace
identifiers, AIS/RDI signals, and tandem connection points for doing
this. OTN (G.709) also has these defined. In addition, OTN has defined 6
flexible layers for TCM and 2 fixed layer for TCM (section and path).=20

I think LMP is not necessary for fault isolation, but it could be
another mechanism that may be used (if one so chooses).=20

>=20
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
>=20
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
>=20
> -----Original Message-----
> From: rajesh [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Queries regarding LMP.
>=20
> Hi,
>=20
>      Have a few queries regd LMP.
>=20
> Q1)  Regd the applicability of LMP...
>=20
> draft-many-gmpls-architecture-00.txt states that
>=20
> "   For instance, the traditional IP routing model assumes the
>    establishment of a routing adjacency over each link connecting two
>    adjacent nodes. Having such a large number of adjacencies is not
>    scalable at all. Each node needs to maintain each of its
adjacencies
>    one by one, and link state routing information must be flooded in
>    the topology for each link.
>=20
>    To solve this issue the concept of bundling was introduced.
>    Moreover, the manual configuration and control of these links, even
>    if they are unnumbered, becomes totally impractical. The Link
>    Management Protocol (LMP) was specified to solve these problems. "
>=20
> a) Can one assume that LMP makes sense ONLY in the case of a large
>      number of parallel links and link bundling...
>=20
>       and an implementation of GMPLS neednot have LMP if no link
>       bundling is used ??
>=20
>       The above maybe the case when using lower end SONET ADM,
>        DXCs...
>=20
> b) Under what other conditions would one require LMP (ie other than
>       link bundling) ?
>=20
> Q2) Suppose one does NOT need to use LMP but then one needs to use
>          OSPF extensions to support TE
> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
>=20
>         then one may need to do a  correlation of Link Ids between 2
> TE nodes.
>=20
>        a) Is there a standard recommended way to do this correlation
??
>=20
>              E.g OSPF - Link Local Signaling
>                     or OSPF - link scope LSA ?
>=20
> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>          are encoded as IP packets and also suggests protocol number
> 140.
>=20
>           What would be the destination IP address of an LMP packet ??
>=20
>            A multicast or is it got from an IGP ??
>=20
> Q4) In LMP, if a Link Id correlation has been done,  and If the link
ids
>=20
>          on one of the ends or both change... How is this change taken
> into
>          account ??
>=20
>          Eg for i =3D 1,2
>                           Port i, Node 1 connected to Port i, Node 2
>=20
>           If one interchanges the connection then one has to
recorrelate
>=20
>            the Link Id mappings..
>=20
> Thanks in advance,
> Rajesh

Delivery-date: Wed, 25 Jul 2001 11:55:47 -0700
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Queries regarding LMP.
Date: Wed, 25 Jul 2001 14:54:29 -0400

Hello,

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Hi,
> 
>> By the same token, is there really a need for fast keep-alive 
> for all situations, esp. for in-band DCC control channels 
> where there is a link layer protocol in use that can monitor 
> control link health?  Keep-alive is just further overhead in 
> that situation, especially when there may be hellos in the 
> signaling and routing protocols going on at the same time.

For in-band DCC, the SONET/SDH procedures can help in
detecting link down situation. However, a keep-alive also tells
if the neighbor discovery process running is up or down. Perhaps
 the neighbor discovery Hello messages can be sent over a 
coarser time period. W.r.t routing
protocols, the idea is not to create an IGP adjacency over
each link (and hence no IGP hello over each link).

Regards,

Bala

Delivery-date: Wed, 25 Jul 2001 11:53:17 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Andre Fredette <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 14:51:28 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1153A.CFFD3950
Content-Type: text/plain;
	charset="iso-8859-1"

Andre,
 
This is a misrepresentation of my argument. My argument is:
 
- LMP is at best optional. Not everyone is going to implement it. 
- Let's not try to force it on everyone.
 
Therefore your argument to use LMP is not reasonable.
 
Regards;
 
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]
 
-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface
 
Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress in 
the IETF. 
        
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 
[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C1153A.CFFD3950
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>A=
ndre,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
his is a
misrepresentation of my argument. My argument =
is:<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>-=
 LMP is at
best optional. Not everyone is going to implement it. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>-=
 Let's
not try to force it on everyone.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span=
></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
herefore your
argument to use LMP is not =
reasonable.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>R=
egards;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle15><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><font
color=3D"#3366ff" face=3D"Arial Black"><span =
style=3D'font-family:"Arial Black";
color:#3366FF'>Osama Aboul-Magd</span></font><font color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Nortel =
Networks</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>P.O. Box 3511, Station =
&quot;C&quot;</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Ottawa, ON, =
Canada</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>K1Y - 4H7</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Tel: =
613-763-5827</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>e.mail: =
[email-masked]</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle15><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Andre Fredette
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
2:11 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Aboul-Magd, Osama
[CAR:1A00:EXCH]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Jonathan Lang;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>Osama,<br>
<br>
[Note: I tried to trim this note down to the key arguments so that it =
is easier
to follow.]<br>
<br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<br>
<br>
Osama's main argument is:<br>
1. I don't think LMP should exist.<br>
2. Therefore let's create a new protocol.<br>
<br>
Given that the members of the working group have decided that LMP will =
be
developed, I don't think Osama's argument is reasonable.<br>
<br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>[Osama] what is the limitation here? Are you saying having =
a
simple design is a limitation? Not everything has to be complex. =
</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>[Jonathan]&nbsp; Other DWDM vendors are not happy with the =
master-slave
model.&nbsp; Also, the claim that NTIP is simple is an explicit =
assertion and
you seem to be trying to make an implicit assertion that LMP is =
complex. </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
On the master-slave issue.&nbsp; There is clearly some information that =
the
line system does not need.&nbsp; For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.&nbsp; I think =
this works
fine within the context of LMP.<br>
<br>
You have made claims of complexity, but have never been able to back =
them up
with fact.<br>
<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>Given
the CR-LDP fiasco in MPLS, it was clearly stated by the ADs =
and</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black;mso-color-alt:windowtext'><o:p></o=
:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>Working
Group chairs in Minnesota that only one protocol will progress =
in</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black;mso-color-alt:windowtext'><o:p></o=
:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>the
IETF.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:12.0pt;margin-left:72.0pt'><font size=3D2 color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:black'>[Osama] I
don't understand why CR-LDP and RSVP-TE have been brought to this =
discussion.
This is a completely different situation. LMP hasn't seen the&nbsp; =
wide
deployment that RSVP-TE has. The example is =
inadequate.</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'> <o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0pt;margin-right:36.0pt;
margin-bottom:0pt;margin-left:72.0pt;margin-bottom:.0001pt'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>[Jonathan] CR-LDP and RSVP-TE were both being developed =
prior to
either one of them being widely deployed.&nbsp; The effort involved in =
developing
2 protocols concurrently to do the same thing is widely perceived as =
being
counter productive. </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
Given the choice between specifying and implementing two protocols that =
do
basically the same thing and one, I think the choice should be =
clear.<br>
<br>
Andre</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1153A.CFFD3950--

Delivery-date: Wed, 25 Jul 2001 11:38:21 -0700
From: John Drake <[email-masked]>
To: 'Andre Fredette' <[email-masked]>, 'Osama Aboul-Magd' <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 11:36:48 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11538.C3719FC0
Content-Type: text/plain;
	charset="iso-8859-1"

As an aside, the LMP-WDM and NTIP authors did have several phone conferences
prior to the last IETF, and the NTIP authors indicated that folding the
contents of LMP-WDM draft into the NTIP draft would be an acceptable
solution to them.  Presumably this would allow it to be called NTIP.

 Since then, they've also indicated that the LMP-WDM protocol is fine, but
it can't have the letters LMP in its name.

Thanks,

John 

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:11 AM
To: 'Osama Aboul-Magd'
Cc: Jonathan Lang; [email-masked]
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: 

        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

On the master-slave issue.  There is clearly some information that the line
system does not need.  For example, I don't expect the Link Characteristics
need to be advertised from OXC to OLS.  I think this works fine within the
context of LMP.

You have made claims of complexity, but have never been able to back them up
with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 

Working Group chairs in Minnesota that only one protocol will progress in 

the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that do
basically the same thing and one, I think the choice should be clear.

Andre

------_=_NextPart_001_01C11538.C3719FC0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT size=2>As an aside, the LMP-WDM and NTIP authors did have several phone 
conferences prior to the last IETF, and the NTIP authors indicated that folding 
the contents of LMP-WDM draft into the NTIP draft would be an acceptable 
solution to them.<SPAN class=853413518-25072001>&nbsp; Presumably this would 
allow it to be called NTIP.</SPAN></FONT></P>
<P><FONT size=2><SPAN class=853413518-25072001>&nbsp;Since then, they've also 
indicated that the LMP-WDM protoc</SPAN><SPAN class=853413518-25072001>ol is 
fine, but it can't have the letters LMP in its name</SPAN><SPAN 
class=853413518-25072001>.</SPAN></FONT></P>
<P><SPAN class=853413518-25072001></SPAN><FONT size=2><SPAN 
class=853413518-25072001>Thanks,</SPAN></FONT></P>
<P><FONT size=2><SPAN 
class=853413518-25072001>John</SPAN>&nbsp;</FONT></P></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Andre Fredette 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 11:11 
  AM<BR><B>To:</B> 'Osama Aboul-Magd'<BR><B>Cc:</B> Jonathan Lang; 
  [email-masked]<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></DIV></FONT>Osama,<BR><BR>[Note: I tried to trim this note 
  down to the key arguments so that it is easier to follow.]<BR><BR>My main 
  argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is 
  as follows:<BR>1. LMP exists.<BR>2. LMP solves most of the OLI problems, 
  <BR>3. Therefore, let's use LMP.<BR><BR>Osama's main argument is:<BR>1. I 
  don't think LMP should exist.<BR>2. Therefore let's create a new 
  protocol.<BR><BR>Given that the members of the working group have decided that 
  LMP will be developed, I don't think Osama's argument is reasonable.<BR><BR>At 
  10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
  <BLOCKQUOTE class=cite cite type="cite">
    <DL>
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[Osama] what 
      is the limitation here? Are you saying having a simple design is a 
      limitation? Not everything has to be complex. </FONT><FONT color=#0000ff 
      face=arial size=2></FONT><FONT color=#0000ff face=arial size=2>
      <DD>[Jonathan]&nbsp; Other DWDM vendors are not happy with the 
      master-slave model.&nbsp; Also, the claim that NTIP is simple is an 
      explicit assertion and you seem to be trying to make an implicit assertion 
      that LMP is complex. </FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>On the master-slave issue.&nbsp; There is clearly some 
  information that the line system does not need.&nbsp; For example, I don't 
  expect the Link Characteristics need to be advertised from OXC to OLS.&nbsp; I 
  think this works fine within the context of LMP.<BR><BR>You have made claims 
  of complexity, but have never been able to back them up with fact.<BR><BR><BR>
  <BLOCKQUOTE class=cite cite type="cite">
    <DL><FONT size=2>
      <DD>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs 
      and</FONT> <FONT size=2>
      <DD>Working Group chairs in Minnesota that only one protocol will progress 
      in</FONT> <FONT size=2>
      <DD>the IETF.</FONT> 
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>
      <DD>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to 
      this discussion. This is a completely different situation. LMP hasn't seen 
      the&nbsp; wide deployment that RSVP-TE has. The example is 
      inadequate.</FONT><FONT color=#0000ff face=arial size=2> <BR><BR>
      <DD>[Jonathan] CR-LDP and RSVP-TE were both being developed prior to 
      either one of them being widely deployed.&nbsp; The effort involved in 
      developing 2 protocols concurrently to do the same thing is widely 
      perceived as being counter productive. </FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR>Given the choice between specifying and implementing two 
  protocols that do basically the same thing and one, I think the choice should 
  be clear.<BR><BR>Andre<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11538.C3719FC0--

Delivery-date: Wed, 25 Jul 2001 11:38:15 -0700
To: "Martin Dubuc" <[email-masked]>, "Zhi-Wei Lin" <[email-masked]>
Date: Wed, 25 Jul 2001 11:36:49 -0700
From: "Lyndon Ong" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Queries regarding LMP.
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Length: 5126

Hi,

I thought that this was why the fault localization piece of LMP was made negotiable, since it was not necessary to support this in opaque networks.

By the same token, is there really a need for fast keep-alive for all situations, esp. for in-band DCC control channels where there is a link layer protocol in use that can monitor control link health?  Keep-alive is just further overhead in that situation, especially when there may be hellos in the signaling and routing protocols going on at the same time.

Cheers,

Lyndon

--

On Wed, 25 Jul 2001 12:34:38   Zhi-Wei Lin wrote:
>Hi Martin, comments in-line
>
>
>Martin Dubuc wrote:
>> 
>> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
>> control and data link health. To determine whether LMP is useful or not,
>> one has to look at the operational aspect of product deployment and
>> maintenance, i.e. what tools the vendor wants to implement to facilitate
>> provisioning and maintenance of their customers network. In a small
>> network, a vendor may be able to get away with manual configuration of
>> links. In an opaque network, it is also easy to pinpoint link failures.
>> However, in a truly optical network, there needs to be mechanisms to
>> isolate faults (which LMP provides).
>
>When you say "truly optical network", do you mean a network that has no
>O/E/O (no 3R) at all? or is there some 3R at the edge?
>
>As for mechanisms to isolate faults, I think this capability is already
>part of networks. For example, SONET has mechanisms such as trace
>identifiers, AIS/RDI signals, and tandem connection points for doing
>this. OTN (G.709) also has these defined. In addition, OTN has defined 6
>flexible layers for TCM and 2 fixed layer for TCM (section and path). 
>
>I think LMP is not necessary for fault isolation, but it could be
>another mechanism that may be used (if one so chooses). 
>
>> 
>> Usefulness of LMP is not directly tied to use of link bundles. Link
>> bundles are mostly used to reduce the flooding of link information
>> generated by the routing protocol.
>> 
>> Q3) Destination address can be multicast or any valid IP address of
>> destination node (most likely the NodeID of the destination node).
>> 
>> -----Original Message-----
>> From: rajesh [mailto:[email-masked]]
>> Sent: Wednesday, July 25, 2001 1:59 AM
>> To: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Queries regarding LMP.
>> 
>> Hi,
>> 
>>      Have a few queries regd LMP.
>> 
>> Q1)  Regd the applicability of LMP...
>> 
>> draft-many-gmpls-architecture-00.txt states that
>> 
>> "   For instance, the traditional IP routing model assumes the
>>    establishment of a routing adjacency over each link connecting two
>>    adjacent nodes. Having such a large number of adjacencies is not
>>    scalable at all. Each node needs to maintain each of its adjacencies
>>    one by one, and link state routing information must be flooded in
>>    the topology for each link.
>> 
>>    To solve this issue the concept of bundling was introduced.
>>    Moreover, the manual configuration and control of these links, even
>>    if they are unnumbered, becomes totally impractical. The Link
>>    Management Protocol (LMP) was specified to solve these problems. "
>> 
>> a) Can one assume that LMP makes sense ONLY in the case of a large
>>      number of parallel links and link bundling...
>> 
>>       and an implementation of GMPLS neednot have LMP if no link
>>       bundling is used ??
>> 
>>       The above maybe the case when using lower end SONET ADM,
>>        DXCs...
>> 
>> b) Under what other conditions would one require LMP (ie other than
>>       link bundling) ?
>> 
>> Q2) Suppose one does NOT need to use LMP but then one needs to use
>>          OSPF extensions to support TE
>> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
>> 
>>         then one may need to do a  correlation of Link Ids between 2
>> TE nodes.
>> 
>>        a) Is there a standard recommended way to do this correlation ??
>> 
>>              E.g OSPF - Link Local Signaling
>>                     or OSPF - link scope LSA ?
>> 
>> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>>          are encoded as IP packets and also suggests protocol number
>> 140.
>> 
>>           What would be the destination IP address of an LMP packet ??
>> 
>>            A multicast or is it got from an IGP ??
>> 
>> Q4) In LMP, if a Link Id correlation has been done,  and If the link ids
>> 
>>          on one of the ends or both change... How is this change taken
>> into
>>          account ??
>> 
>>          Eg for i = 1,2
>>                           Port i, Node 1 connected to Port i, Node 2
>> 
>>           If one interchanges the connection then one has to recorrelate
>> 
>>            the Link Id mappings..
>> 
>> Thanks in advance,
>> Rajesh
>
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Delivery-date: Wed, 25 Jul 2001 11:12:21 -0700
From: Andre Fredette <[email-masked]>
To: 'Osama Aboul-Magd' <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, [email-masked]
Date: Wed, 25 Jul 2001 14:10:46 -0400
Subject: RE: Optical Link Interface

--=====================_18484599==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Osama,

[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems, 
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will
be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what is the limitation here? Are you saying having a
simple design is a limitation? Not everything has to be complex. 

[Jonathan]  Other DWDM vendors are not happy with the master-slave
model.  Also, the claim that NTIP is simple is an explicit assertion and
you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the
line system does not need.  For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.  I think this
works fine within the context of LMP.

You have made claims of complexity, but have never been able to back
them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 

Working Group chairs in Minnesota that only one protocol will progress
in 

the IETF. 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to
this discussion. This is a completely different situation. LMP hasn't
seen the  wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either
one of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

Given the choice between specifying and implementing two protocols that
do basically the same thing and one, I think the choice should be clear.

Andre

--=====================_18484599==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Osama,<br><br>
[Note: I tried to trim this note down to the key arguments so that it is
easier to follow.]<br><br>
My main argument (and I believe it is shared by the rest of the LMP-WDM
co-authors) is as follows:<br>
1. LMP exists.<br>
2. LMP solves most of the OLI problems, <br>
3. Therefore, let's use LMP.<br><br>
Osama's main argument is:<br>
1. I don't think LMP should exist.<br>
2. Therefore let's create a new protocol.<br><br>
Given that the members of the working group have decided that LMP will be
developed, I don't think Osama's argument is reasonable.<br><br>
At 10:41 AM 7/25/2001 -0700, Jonathan Lang
wrote:<blockquote type=cite class=cite cite>
<dl>
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=2>[Osama] what
is the limitation here? Are you saying having a simple design is a
limitation? Not everything has to be complex.
</font><font face="arial" size=2 color="#0000FF">
</font><font face="arial" size=2 color="#0000FF">
<dd>[Jonathan]&nbsp; Other DWDM vendors are not happy with the
master-slave model.&nbsp; Also, the claim that NTIP is simple is an
explicit assertion and you seem to be trying to make an implicit
assertion that LMP is complex. </font></blockquote>
</dl><br>
On the master-slave issue.&nbsp; There is clearly some information that
the line system does not need.&nbsp; For example, I don't expect the Link
Characteristics need to be advertised from OXC to OLS.&nbsp; I think this
works fine within the context of LMP.<br><br>
You have made claims of complexity, but have never been able to back them
up with fact.<br><br>
<br>
<blockquote type=cite class=cite cite>
<dl><font size=2>
<dd>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs
and</font> <font size=2>
<dd>Working Group chairs in Minnesota that only one protocol will
progress in</font> <font size=2>
<dd>the IETF.</font> 
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=2>
<dd>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought
to this discussion. This is a completely different situation. LMP hasn't
seen the&nbsp; wide deployment that RSVP-TE has. The example is
inadequate.</font><font face="arial" size=2 color="#0000FF"> <br><br>

<dd>[Jonathan] CR-LDP and RSVP-TE were both being developed prior to
either one of them being widely deployed.&nbsp; The effort involved in
developing 2 protocols concurrently to do the same thing is widely
perceived as being counter productive. </font></blockquote>
</dl><br>
Given the choice between specifying and implementing two protocols that
do basically the same thing and one, I think the choice should be
clear.<br><br>
Andre<br>
</html>

--=====================_18484599==_.ALT--

Delivery-date: Wed, 25 Jul 2001 10:48:04 -0700
From: Jonathan Lang <[email-masked]>
To: 'Osama Aboul-Magd' <[email-masked]>, Jonathan Lang <[email-masked]>, Andre Fredette <[email-masked]>,  [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 10:41:15 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11531.00FBFE60
Content-Type: text/plain;
	charset="iso-8859-1"

Osama,
  Please see inline comments.
 
Thanks,
Jonathan

-----Original Message-----
From: Osama Aboul-Magd [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 10:21 AM
To: Jonathan Lang; Andre Fredette; [email-masked]
Subject: RE: Optical Link Interface

Jonathan, 

Comments are inline. 

Regards; 

Osama Aboul-Magd 
Nortel Networks 
P.O. Box 3511, Station "C" 
Ottawa, ON, Canada 
K1Y - 4H7 
Tel: 613-763-5827 
e.mail: [email-masked] 

 -----Original Message----- 
From:   Jonathan Lang [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Wednesday, July 25, 2001 11:53 AM 
To:     Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette;
[email-masked] 
Subject:        RE: Optical Link Interface 

Osama, 
  Please see inline comments. 

Thanks, 
Jonathan 

>-----Original Message----- 
>From: Osama Aboul-Magd [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, July 25, 2001 8:15 AM 
>To: Andre Fredette; [email-masked] 
>Subject: RE: Optical Link Interface 
> 
> 
>Andre, 
>Obviously I disagree with you in your conclusion. There are number of 
factors that should 
> be considered: 
>- While LMP has been in STANDARD process for some time, there hasn't been 
much deployment, 
> if any, of it. Furthermore the reality of optical networks today is that 
same vendor 
> equipment is deployed in a single span. Implementation of LMP in this case

is at best 
> optional. One may choose not to implement LMP at all. IMHO tying this 
important interface 
> to the fate of LMP is not the way to proceed. How long LMP been at the 
IETF is irrelevant. 
> - NTIP is a new TCP application in the same way as LMP-WDM is a NEW 
application for LMP. 
I'm glad you brought this up.  TCP greatly complicates the fault recovery 
procedure and fault recovery is an essential aspect for this interface. 

        [Osama] I am not sure I follow. 

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model

itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC 
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship 
suits this 
> interface better. 
I understand this limitation works for your product, but other WDM vendors 
have requested a more flexible model. 

        [Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex.  

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.
Also, the claim that NTIP is simple is an explicit assertion and you seem to
be trying to make an implicit assertion that LMP is complex. 

> - To link with other standards bodies, as far as I know T1X1, where the 
optical knowledge 
> exists, is yet to arrive to a definition of this interface. More 
contributions are 
> solicited to better understand its need and applications. Given that, I'd 
like to 
> understand the rationale for the "rough consensus" reached at CCAMP 
mailing list. Only 4-5 
> messages were posted to the mailing list and mostly from authors of the 
OLI requirements 
> draft. 
> - I don't see harm in having two protocols. The market made its decisions 
on the examples > you mentioned, and I am sure it will happen again in this 
case. 
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and 
Working Group chairs in Minnesota that only one protocol will progress in 
the IETF. 
        
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one
of them being widely deployed.  The effort involved in developing 2
protocols concurrently to do the same thing is widely perceived as being
counter productive. 

> Regards; 
> Osama Aboul-Magd 
> Nortel Networks 
> P.O. Box 3511, Station "C" 
> Ottawa, ON, Canada 
> K1Y - 4H7 
> Tel: 613-763-5827 
> e.mail: [email-masked] 
 -----Original Message----- 
From:   Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Monday, July 23, 2001 10:01 PM 
To:     [email-masked] 
Subject:        Optical Link Interface 
Last month, the "Optical Link Interface (OLI) Requirements" document 
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
<http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt>  
was discussed on the ccamp mailing list and achieved "rough consensus" 
according to our working group co-chairs.  Given this, we'd like to make 
some progress on the protocol specification.  I'd like to generate some 
discussion on this mailing list before the IETF meeting in London because 
meaningful technical discussion cannot occur in the time allocated during 
the meeting. 
There have been two proposals in the IETF to satisfy the OLI requirements: 
1. [LMP-WDM]: 
"Link Management Protocol (LMP) for DWDM Optical Line Systems" 
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
<http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt>  
(note, this updated document was submitted Friday, so it should show up 
on the official website soon). 
and 
2. [NTIP]: 
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" 
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
<http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt>  
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while 
NTIP proposes a new protocol.  We believe that the LMP approach is best 
because: 
1. [LMP-WDM] satisfies the OLI Requirements. 
2. The extensions to LMP are quite natural and fit within the spirit of the 
LMP protocol. 
3. LMP is a reasonably mature IETF protocol specification: 
     - It has been in the works for well over a year. 
     - It is an official working group document. 
4. It is better to have one protocol, than two for a given function 
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 
5. Using the same protocol simplifies both implementation and management on 
devices, such as optical cross-connects and routers, that may need to use 
both simultaneously. 
While there is no doubt in my mind that NTIP could be made to satisfy the 
OLI requirements, It is my strong opinion that LMP should be the solution 
chosen by the CCAMP working group due to the reasons outlined above. 
Comments please! 
Regards, 
Andre 

------_=_NextPart_001_01C11531.00FBFE60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=642002117-25072001>Osama,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=642002117-25072001>&nbsp; 
Please see inline comments.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=642002117-25072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=642002117-25072001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=642002117-25072001>Jonathan</SPAN></FONT></DIV></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Osama Aboul-Magd 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 
  10:21 AM<BR><B>To:</B> Jonathan Lang; Andre Fredette; 
  [email-masked]<BR><B>Subject:</B> RE: Optical Link 
  Interface<BR><BR></DIV></FONT>
  <P><FONT size=2>Jonathan,</FONT> </P>
  <P><FONT size=2>Comments are inline.</FONT> </P>
  <P><FONT size=2>Regards;</FONT> </P>
  <P><FONT size=2>Osama Aboul-Magd</FONT> <BR><FONT size=2>Nortel 
  Networks</FONT> <BR><FONT size=2>P.O. Box 3511, Station "C"</FONT> <BR><FONT 
  size=2>Ottawa, ON, Canada</FONT> <BR><FONT size=2>K1Y - 4H7</FONT> <BR><FONT 
  size=2>Tel: 613-763-5827</FONT> <BR><FONT size=2>e.mail: 
  [email-masked]</FONT> </P>
  <P><FONT size=2>&nbsp;-----Original Message-----</FONT> <BR><FONT size=2>From: 
  &nbsp; Jonathan Lang [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 11:53 
  AM</FONT> <BR><FONT size=2>To:&nbsp;&nbsp;&nbsp;&nbsp; Aboul-Magd, Osama 
  [CAR:1A00:EXCH]; Andre Fredette; [email-masked]</FONT> <BR><FONT 
  size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Optical Link 
  Interface</FONT> </P>
  <P><FONT size=2>Osama,</FONT> <BR><FONT size=2>&nbsp; Please see inline 
  comments.</FONT> </P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Jonathan</FONT> </P>
  <P><FONT size=2>&gt;-----Original Message-----</FONT> <BR><FONT 
  size=2>&gt;From: Osama Aboul-Magd [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
  <BR><FONT size=2>&gt;Sent: Wednesday, July 25, 2001 8:15 AM</FONT> <BR><FONT 
  size=2>&gt;To: Andre Fredette; [email-masked]</FONT> <BR><FONT 
  size=2>&gt;Subject: RE: Optical Link Interface</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Andre, 
  </FONT><BR><FONT size=2>&gt;Obviously I disagree with you in your conclusion. 
  There are number of</FONT> <BR><FONT size=2>factors that should</FONT> 
  <BR><FONT size=2>&gt; be considered: </FONT><BR><FONT size=2>&gt;- While LMP 
  has been in STANDARD process for some time, there hasn't been</FONT> <BR><FONT 
  size=2>much deployment,</FONT> <BR><FONT size=2>&gt; if any, of it. 
  Furthermore the reality of optical networks today is that</FONT> <BR><FONT 
  size=2>same vendor </FONT><BR><FONT size=2>&gt; equipment is deployed in a 
  single span. Implementation of LMP in this case</FONT> <BR><FONT size=2>is at 
  best </FONT><BR><FONT size=2>&gt; optional. One may choose not to implement 
  LMP at all. IMHO tying this</FONT> <BR><FONT size=2>important interface 
  </FONT><BR><FONT size=2>&gt; to the fate of LMP is not the way to proceed. How 
  long LMP been at the</FONT> <BR><FONT size=2>IETF is irrelevant.</FONT> 
  <BR><FONT size=2>&gt; - NTIP is a new TCP application in the same way as 
  LMP-WDM is a NEW</FONT> <BR><FONT size=2>application for LMP.</FONT> <BR><FONT 
  size=2>I'm glad you brought this up.&nbsp; TCP greatly complicates the fault 
  recovery</FONT> <BR><FONT size=2>procedure and fault recovery is an essential 
  aspect for this interface.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[Osama] I am not 
  sure I follow. </FONT></P>
  <P><FONT size=2>&gt; - The issue is not really LMP vs TCP. NTIP and LMP-WDM 
  differ in the model</FONT> <BR><FONT size=2>itself. Your </FONT><BR><FONT 
  size=2>&gt; choice to use LMP to run LMP-WDM on top of it forced you to treat 
  the PXC</FONT> <BR><FONT size=2>and LS as peers. </FONT><BR><FONT size=2>&gt; 
  NTIP treats PXC-LS relationship as master-slave. Non peer relationship</FONT> 
  <BR><FONT size=2>suits this </FONT><BR><FONT size=2>&gt; interface 
  better.</FONT> <BR><FONT size=2>I understand this limitation works for your 
  product, but other WDM vendors</FONT> <BR><FONT size=2>have requested a more 
  flexible model.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[Osama] what is the 
  limitation here? Are you saying having a simple design is a limitation? Not 
  everything has to be complex.&nbsp;<FONT color=#0000ff face=Arial><SPAN 
  class=031154017-25072001>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=031154017-25072001><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=642002117-25072001>[Jonathan] &nbsp;Other DWDM vendors are not happy 
  with the master-slave model.&nbsp; Also, the claim that NTIP is simple is an 
  explicit assertion and&nbsp;you seem to be trying to make&nbsp;an implicit 
  assertion that LMP is 
  complex.</SPAN></FONT></FONT>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>&gt; - To link with other standards bodies, as far as I know 
  T1X1, where the</FONT> <BR><FONT size=2>optical knowledge </FONT><BR><FONT 
  size=2>&gt; exists, is yet to arrive to a definition of this interface. 
  More</FONT> <BR><FONT size=2>contributions are </FONT><BR><FONT size=2>&gt; 
  solicited to better understand its need and applications. Given that, 
  I'd</FONT> <BR><FONT size=2>like to </FONT><BR><FONT size=2>&gt; understand 
  the rationale for the "rough consensus" reached at CCAMP</FONT> <BR><FONT 
  size=2>mailing list. Only 4-5 </FONT><BR><FONT size=2>&gt; messages were 
  posted to the mailing list and mostly from authors of the</FONT> <BR><FONT 
  size=2>OLI requirements </FONT><BR><FONT size=2>&gt; draft.</FONT> <BR><FONT 
  size=2>&gt; - I don't see harm in having two protocols. The market made its 
  decisions</FONT> <BR><FONT size=2>on the examples &gt; you mentioned, and I am 
  sure it will happen again in this</FONT> <BR><FONT size=2>case.</FONT> 
  <BR><FONT size=2>Given the CR-LDP fiasco in MPLS, it was clearly stated by the 
  ADs and</FONT> <BR><FONT size=2>Working Group chairs in Minnesota that only 
  one protocol will progress in</FONT> <BR><FONT size=2>the IETF.</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT size=2>[Osama] I 
  don't understand why CR-LDP and RSVP-TE have been brought to this discussion. 
  This is a completely different situation. LMP hasn't seen the&nbsp; wide 
  deployment that RSVP-TE has. The example is inadequate.<FONT color=#0000ff 
  face=Arial><SPAN class=031154017-25072001>&nbsp;</SPAN></FONT></FONT></P><FONT 
  size=2><FONT color=#0000ff face=Arial><SPAN class=031154017-25072001>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=642002117-25072001>[Jonathan] CR-LDP and RSVP-TE were both being 
  developed prior to either one of them being widely deployed.&nbsp; The effort 
  involved in developing 2 protocols concurrently to do the same thing is widely 
  perceived as being counter 
  productive.</SPAN></FONT></FONT>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>&gt; Regards; </FONT><BR><FONT size=2>&gt; Osama Aboul-Magd 
  </FONT><BR><FONT size=2>&gt; Nortel Networks </FONT><BR><FONT size=2>&gt; P.O. 
  Box 3511, Station "C" </FONT><BR><FONT size=2>&gt; Ottawa, ON, Canada 
  </FONT><BR><FONT size=2>&gt; K1Y - 4H7 </FONT><BR><FONT size=2>&gt; Tel: 
  613-763-5827 </FONT><BR><FONT size=2>&gt; e.mail: [email-masked] 
  </FONT><BR><FONT size=2>&nbsp;-----Original Message----- </FONT><BR><FONT 
  size=2>From:&nbsp;&nbsp; Andre Fredette [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent:&nbsp;&nbsp; Monday, July 23, 2001 10:01 PM 
  </FONT><BR><FONT size=2>To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked] 
  </FONT><BR><FONT size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Optical Link Interface </FONT><BR><FONT size=2>Last month, the "Optical Link 
  Interface (OLI) Requirements" document </FONT><BR><FONT size=2><A 
  href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" 
  target=_blank>http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</A> 
  </FONT><BR><FONT size=2>was discussed on the ccamp mailing list and achieved 
  "rough consensus" </FONT><BR><FONT size=2>according to our working group 
  co-chairs.&nbsp; Given this, we'd like to make </FONT><BR><FONT size=2>some 
  progress on the protocol specification.&nbsp; I'd like to generate some 
  </FONT><BR><FONT size=2>discussion on this mailing list before the IETF 
  meeting in London because </FONT><BR><FONT size=2>meaningful technical 
  discussion cannot occur in the time allocated during </FONT><BR><FONT 
  size=2>the meeting. </FONT><BR><FONT size=2>There have been two proposals in 
  the IETF to satisfy the OLI requirements: </FONT><BR><FONT size=2>1. 
  [LMP-WDM]: </FONT><BR><FONT size=2>"Link Management Protocol (LMP) for DWDM 
  Optical Line Systems" </FONT><BR><FONT size=2><A 
  href="http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt" 
  target=_blank>http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt</A> 
  </FONT><BR><FONT size=2>(note, this updated document was submitted Friday, so 
  it should show up </FONT><BR><FONT size=2>on the official website soon). 
  </FONT><BR><FONT size=2>and </FONT><BR><FONT size=2>2. [NTIP]: 
  </FONT><BR><FONT size=2>"Network Transport Interface Protocol (NTIP) for 
  Photonic Cross Connects" </FONT><BR><FONT size=2>(PXC) <A 
  href="http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt" 
  target=_blank>http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt</A> 
  </FONT><BR><FONT size=2>LMP-WDM proposes extensions to LMP to satisfy the OLI 
  requirements, while </FONT><BR><FONT size=2>NTIP proposes a new 
  protocol.&nbsp; We believe that the LMP approach is best </FONT><BR><FONT 
  size=2>because: </FONT><BR><FONT size=2>1. [LMP-WDM] satisfies the OLI 
  Requirements. </FONT><BR><FONT size=2>2. The extensions to LMP are quite 
  natural and fit within the spirit of the </FONT><BR><FONT size=2>LMP protocol. 
  </FONT><BR><FONT size=2>3. LMP is a reasonably mature IETF protocol 
  specification: </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp; - It has been 
  in the works for well over a year. </FONT><BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp; - It is an official working group document. 
  </FONT><BR><FONT size=2>4. It is better to have one protocol, than two for a 
  given function </FONT><BR><FONT size=2>(remember CR-LDP vs. RSVP-TE, and OSPF 
  vs. IS-IS) </FONT><BR><FONT size=2>5. Using the same protocol simplifies both 
  implementation and management on </FONT><BR><FONT size=2>devices, such as 
  optical cross-connects and routers, that may need to use </FONT><BR><FONT 
  size=2>both simultaneously. </FONT><BR><FONT size=2>While there is no doubt in 
  my mind that NTIP could be made to satisfy the </FONT><BR><FONT size=2>OLI 
  requirements, It is my strong opinion that LMP should be the solution 
  </FONT><BR><FONT size=2>chosen by the CCAMP working group due to the reasons 
  outlined above. </FONT><BR><FONT size=2>Comments please! </FONT><BR><FONT 
  size=2>Regards, </FONT><BR><FONT size=2>Andre 
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11531.00FBFE60--

Delivery-date: Wed, 25 Jul 2001 10:22:46 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Jonathan Lang <[email-masked]>, Andre Fredette <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 13:21:00 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1152E.2C90CA90
Content-Type: text/plain;
	charset="iso-8859-1"

Jonathan,

Comments are inline.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Jonathan Lang [mailto:[email-masked]] 
Sent:	Wednesday, July 25, 2001 11:53 AM
To:	Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette;
[email-masked]
Subject:	RE: Optical Link Interface

Osama,
  Please see inline comments.

Thanks,
Jonathan

>-----Original Message-----
>From: Osama Aboul-Magd [mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 8:15 AM
>To: Andre Fredette; [email-masked]
>Subject: RE: Optical Link Interface
>
>
>Andre, 
>Obviously I disagree with you in your conclusion. There are number of
factors that should
> be considered: 
>- While LMP has been in STANDARD process for some time, there hasn't been
much deployment,
> if any, of it. Furthermore the reality of optical networks today is that
same vendor 
> equipment is deployed in a single span. Implementation of LMP in this case
is at best 
> optional. One may choose not to implement LMP at all. IMHO tying this
important interface 
> to the fate of LMP is not the way to proceed. How long LMP been at the
IETF is irrelevant.
> - NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP.
I'm glad you brought this up.  TCP greatly complicates the fault recovery
procedure and fault recovery is an essential aspect for this interface.

	[Osama] I am not sure I follow. 

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this 
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

	[Osama] what is the limitation here? Are you saying having a simple
design is a limitation? Not everything has to be complex. 

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge 
> exists, is yet to arrive to a definition of this interface. More
contributions are 
> solicited to better understand its need and applications. Given that, I'd
like to 
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5 
> messages were posted to the mailing list and mostly from authors of the
OLI requirements 
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
	
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this
discussion. This is a completely different situation. LMP hasn't seen the
wide deployment that RSVP-TE has. The example is inadequate.

> Regards; 
> Osama Aboul-Magd 
> Nortel Networks 
> P.O. Box 3511, Station "C" 
> Ottawa, ON, Canada 
> K1Y - 4H7 
> Tel: 613-763-5827 
> e.mail: [email-masked] 
 -----Original Message----- 
From:   Andre Fredette [mailto:[email-masked]] 
Sent:   Monday, July 23, 2001 10:01 PM 
To:     [email-masked] 
Subject:        Optical Link Interface 
Last month, the "Optical Link Interface (OLI) Requirements" document 
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt 
was discussed on the ccamp mailing list and achieved "rough consensus" 
according to our working group co-chairs.  Given this, we'd like to make 
some progress on the protocol specification.  I'd like to generate some 
discussion on this mailing list before the IETF meeting in London because 
meaningful technical discussion cannot occur in the time allocated during 
the meeting. 
There have been two proposals in the IETF to satisfy the OLI requirements: 
1. [LMP-WDM]: 
"Link Management Protocol (LMP) for DWDM Optical Line Systems" 
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt 
(note, this updated document was submitted Friday, so it should show up 
on the official website soon). 
and 
2. [NTIP]: 
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" 
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt 
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while 
NTIP proposes a new protocol.  We believe that the LMP approach is best 
because: 
1. [LMP-WDM] satisfies the OLI Requirements. 
2. The extensions to LMP are quite natural and fit within the spirit of the 
LMP protocol. 
3. LMP is a reasonably mature IETF protocol specification: 
     - It has been in the works for well over a year. 
     - It is an official working group document. 
4. It is better to have one protocol, than two for a given function 
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 
5. Using the same protocol simplifies both implementation and management on 
devices, such as optical cross-connects and routers, that may need to use 
both simultaneously. 
While there is no doubt in my mind that NTIP could be made to satisfy the 
OLI requirements, It is my strong opinion that LMP should be the solution 
chosen by the CCAMP working group due to the reasons outlined above. 
Comments please! 
Regards, 
Andre 

------_=_NextPart_001_01C1152E.2C90CA90
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Jonathan,</FONT>
</P>

<P><FONT SIZE=2>Comments are inline.</FONT>
</P>

<P><FONT SIZE=2>Regards;</FONT>
</P>

<P><FONT SIZE=2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
<BR><FONT SIZE=2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=2>K1Y - 4H7</FONT>
<BR><FONT SIZE=2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: &nbsp; Jonathan Lang [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, July 25, 2001 11:53 AM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; [email-masked]</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Optical Link Interface</FONT>
</P>

<P><FONT SIZE=2>Osama,</FONT>
<BR><FONT SIZE=2>&nbsp; Please see inline comments.</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Jonathan</FONT>
</P>

<P><FONT SIZE=2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;From: Osama Aboul-Magd [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt;Sent: Wednesday, July 25, 2001 8:15 AM</FONT>
<BR><FONT SIZE=2>&gt;To: Andre Fredette; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;Subject: RE: Optical Link Interface</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Andre, </FONT>
<BR><FONT SIZE=2>&gt;Obviously I disagree with you in your conclusion. There are number of</FONT>
<BR><FONT SIZE=2>factors that should</FONT>
<BR><FONT SIZE=2>&gt; be considered: </FONT>
<BR><FONT SIZE=2>&gt;- While LMP has been in STANDARD process for some time, there hasn't been</FONT>
<BR><FONT SIZE=2>much deployment,</FONT>
<BR><FONT SIZE=2>&gt; if any, of it. Furthermore the reality of optical networks today is that</FONT>
<BR><FONT SIZE=2>same vendor </FONT>
<BR><FONT SIZE=2>&gt; equipment is deployed in a single span. Implementation of LMP in this case</FONT>
<BR><FONT SIZE=2>is at best </FONT>
<BR><FONT SIZE=2>&gt; optional. One may choose not to implement LMP at all. IMHO tying this</FONT>
<BR><FONT SIZE=2>important interface </FONT>
<BR><FONT SIZE=2>&gt; to the fate of LMP is not the way to proceed. How long LMP been at the</FONT>
<BR><FONT SIZE=2>IETF is irrelevant.</FONT>
<BR><FONT SIZE=2>&gt; - NTIP is a new TCP application in the same way as LMP-WDM is a NEW</FONT>
<BR><FONT SIZE=2>application for LMP.</FONT>
<BR><FONT SIZE=2>I'm glad you brought this up.&nbsp; TCP greatly complicates the fault recovery</FONT>
<BR><FONT SIZE=2>procedure and fault recovery is an essential aspect for this interface.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>[Osama] I am not sure I follow. </FONT>
</P>

<P><FONT SIZE=2>&gt; - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model</FONT>
<BR><FONT SIZE=2>itself. Your </FONT>
<BR><FONT SIZE=2>&gt; choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC</FONT>
<BR><FONT SIZE=2>and LS as peers. </FONT>
<BR><FONT SIZE=2>&gt; NTIP treats PXC-LS relationship as master-slave. Non peer relationship</FONT>
<BR><FONT SIZE=2>suits this </FONT>
<BR><FONT SIZE=2>&gt; interface better.</FONT>
<BR><FONT SIZE=2>I understand this limitation works for your product, but other WDM vendors</FONT>
<BR><FONT SIZE=2>have requested a more flexible model.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>[Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. </FONT></P>

<P><FONT SIZE=2>&gt; - To link with other standards bodies, as far as I know T1X1, where the</FONT>
<BR><FONT SIZE=2>optical knowledge </FONT>
<BR><FONT SIZE=2>&gt; exists, is yet to arrive to a definition of this interface. More</FONT>
<BR><FONT SIZE=2>contributions are </FONT>
<BR><FONT SIZE=2>&gt; solicited to better understand its need and applications. Given that, I'd</FONT>
<BR><FONT SIZE=2>like to </FONT>
<BR><FONT SIZE=2>&gt; understand the rationale for the &quot;rough consensus&quot; reached at CCAMP</FONT>
<BR><FONT SIZE=2>mailing list. Only 4-5 </FONT>
<BR><FONT SIZE=2>&gt; messages were posted to the mailing list and mostly from authors of the</FONT>
<BR><FONT SIZE=2>OLI requirements </FONT>
<BR><FONT SIZE=2>&gt; draft.</FONT>
<BR><FONT SIZE=2>&gt; - I don't see harm in having two protocols. The market made its decisions</FONT>
<BR><FONT SIZE=2>on the examples &gt; you mentioned, and I am sure it will happen again in this</FONT>
<BR><FONT SIZE=2>case.</FONT>
<BR><FONT SIZE=2>Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and</FONT>
<BR><FONT SIZE=2>Working Group chairs in Minnesota that only one protocol will progress in</FONT>
<BR><FONT SIZE=2>the IETF.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<BR><FONT SIZE=2>[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the&nbsp; wide deployment that RSVP-TE has. The example is inadequate.</FONT></P>

<P><FONT SIZE=2>&gt; Regards; </FONT>
<BR><FONT SIZE=2>&gt; Osama Aboul-Magd </FONT>
<BR><FONT SIZE=2>&gt; Nortel Networks </FONT>
<BR><FONT SIZE=2>&gt; P.O. Box 3511, Station &quot;C&quot; </FONT>
<BR><FONT SIZE=2>&gt; Ottawa, ON, Canada </FONT>
<BR><FONT SIZE=2>&gt; K1Y - 4H7 </FONT>
<BR><FONT SIZE=2>&gt; Tel: 613-763-5827 </FONT>
<BR><FONT SIZE=2>&gt; e.mail: [email-masked] </FONT>
<BR><FONT SIZE=2>&nbsp;-----Original Message----- </FONT>
<BR><FONT SIZE=2>From:&nbsp;&nbsp; Andre Fredette [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Monday, July 23, 2001 10:01 PM </FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked] </FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Optical Link Interface </FONT>
<BR><FONT SIZE=2>Last month, the &quot;Optical Link Interface (OLI) Requirements&quot; document </FONT>
<BR><FONT SIZE=2><A HREF="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" TARGET="_blank">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</A> </FONT>
<BR><FONT SIZE=2>was discussed on the ccamp mailing list and achieved &quot;rough consensus&quot; </FONT>
<BR><FONT SIZE=2>according to our working group co-chairs.&nbsp; Given this, we'd like to make </FONT>
<BR><FONT SIZE=2>some progress on the protocol specification.&nbsp; I'd like to generate some </FONT>
<BR><FONT SIZE=2>discussion on this mailing list before the IETF meeting in London because </FONT>
<BR><FONT SIZE=2>meaningful technical discussion cannot occur in the time allocated during </FONT>
<BR><FONT SIZE=2>the meeting. </FONT>
<BR><FONT SIZE=2>There have been two proposals in the IETF to satisfy the OLI requirements: </FONT>
<BR><FONT SIZE=2>1. [LMP-WDM]: </FONT>
<BR><FONT SIZE=2>&quot;Link Management Protocol (LMP) for DWDM Optical Line Systems&quot; </FONT>
<BR><FONT SIZE=2><A HREF="http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt" TARGET="_blank">http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt</A> </FONT>
<BR><FONT SIZE=2>(note, this updated document was submitted Friday, so it should show up </FONT>
<BR><FONT SIZE=2>on the official website soon). </FONT>
<BR><FONT SIZE=2>and </FONT>
<BR><FONT SIZE=2>2. [NTIP]: </FONT>
<BR><FONT SIZE=2>&quot;Network Transport Interface Protocol (NTIP) for Photonic Cross Connects&quot; </FONT>
<BR><FONT SIZE=2>(PXC) <A HREF="http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt" TARGET="_blank">http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt</A> </FONT>
<BR><FONT SIZE=2>LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while </FONT>
<BR><FONT SIZE=2>NTIP proposes a new protocol.&nbsp; We believe that the LMP approach is best </FONT>
<BR><FONT SIZE=2>because: </FONT>
<BR><FONT SIZE=2>1. [LMP-WDM] satisfies the OLI Requirements. </FONT>
<BR><FONT SIZE=2>2. The extensions to LMP are quite natural and fit within the spirit of the </FONT>
<BR><FONT SIZE=2>LMP protocol. </FONT>
<BR><FONT SIZE=2>3. LMP is a reasonably mature IETF protocol specification: </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - It has been in the works for well over a year. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - It is an official working group document. </FONT>
<BR><FONT SIZE=2>4. It is better to have one protocol, than two for a given function </FONT>
<BR><FONT SIZE=2>(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) </FONT>
<BR><FONT SIZE=2>5. Using the same protocol simplifies both implementation and management on </FONT>
<BR><FONT SIZE=2>devices, such as optical cross-connects and routers, that may need to use </FONT>
<BR><FONT SIZE=2>both simultaneously. </FONT>
<BR><FONT SIZE=2>While there is no doubt in my mind that NTIP could be made to satisfy the </FONT>
<BR><FONT SIZE=2>OLI requirements, It is my strong opinion that LMP should be the solution </FONT>
<BR><FONT SIZE=2>chosen by the CCAMP working group due to the reasons outlined above. </FONT>
<BR><FONT SIZE=2>Comments please! </FONT>
<BR><FONT SIZE=2>Regards, </FONT>
<BR><FONT SIZE=2>Andre </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1152E.2C90CA90--

Delivery-date: Wed, 25 Jul 2001 10:22:03 -0700
From: Jonathan Lang <[email-masked]>
To: 'Martin Dubuc' <[email-masked]>, [email-masked],  [email-masked], Jonathan Lang <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: Queries regarding LMP.
Date: Wed, 25 Jul 2001 10:17:02 -0700

Following up on Martin's comments...

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 8:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Queries regarding LMP.
> 
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).
> 
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
To add further, when GMPLS labels map to physical resources (i.e., ports or
fibers), LMP can be used to exchange these labels so that there is a common
understanding of the mapping.  Even if man ual configuration is used, LMP
provides a mechanism to verify the accuracy (it is not uncommon for manual
configuration to be in error...).

> 
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
Note that the protocol Id suggestion of 140 has been removed in the latest
version as this value MUST be assigned by IANA.  140 has been used in
interops for the time being, but this shouldn't be considered as the final
protocol id.

Q4) Recorrelation of Link Ids can be done by reverifying the link and/or
resending the LinkSummary message.

Thanks,
Jonathan 

> 
> -----Original Message-----
> From: rajesh [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Queries regarding LMP.
> 
> 
> Hi,
> 
>      Have a few queries regd LMP.
> 
> Q1)  Regd the applicability of LMP...
> 
> draft-many-gmpls-architecture-00.txt states that
> 
> "   For instance, the traditional IP routing model assumes the
>    establishment of a routing adjacency over each link connecting two
>    adjacent nodes. Having such a large number of adjacencies is not
>    scalable at all. Each node needs to maintain each of its 
> adjacencies
>    one by one, and link state routing information must be flooded in
>    the topology for each link.
> 
>    To solve this issue the concept of bundling was introduced.
>    Moreover, the manual configuration and control of these links, even
>    if they are unnumbered, becomes totally impractical. The Link
>    Management Protocol (LMP) was specified to solve these problems. "
> 
> a) Can one assume that LMP makes sense ONLY in the case of a large
>      number of parallel links and link bundling...
> 
>       and an implementation of GMPLS neednot have LMP if no link
>       bundling is used ??
> 
>       The above maybe the case when using lower end SONET ADM,
>        DXCs...
> 
> b) Under what other conditions would one require LMP (ie other than
>       link bundling) ?
> 
> Q2) Suppose one does NOT need to use LMP but then one needs to use
>          OSPF extensions to support TE
> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
> 
>         then one may need to do a  correlation of Link Ids between 2
> TE nodes.
> 
>        a) Is there a standard recommended way to do this 
> correlation ??
> 
>              E.g OSPF - Link Local Signaling
>                     or OSPF - link scope LSA ?
> 
> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>          are encoded as IP packets and also suggests protocol number
> 140.
> 
>           What would be the destination IP address of an LMP packet ??
> 
>            A multicast or is it got from an IGP ??
> 
> Q4) In LMP, if a Link Id correlation has been done,  and If 
> the link ids
> 
>          on one of the ends or both change... How is this change taken
> into
>          account ??
> 
>          Eg for i = 1,2
>                           Port i, Node 1 connected to Port i, Node 2
> 
>           If one interchanges the connection then one has to 
> recorrelate
> 
>            the Link Id mappings..
> 
> Thanks in advance,
> Rajesh
> 

Delivery-date: Wed, 25 Jul 2001 09:38:28 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: John Drake <[email-masked]>, Andre Fredette <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 12:37:15 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11528.0FEA6820
Content-Type: text/plain;
	charset="iso-8859-1"

 
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]
 
-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:47 AM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; [email-masked]
Subject: RE: Optical Link Interface

-----Original Message-----
From: Osama Aboul-Magd [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 8:15 AM
To: Andre Fredette; [email-masked]
Subject: RE: Optical Link Interface
Andre, 
Obviously I disagree with you in your conclusion. There are number of
factors that should be considered: 
- While LMP has been in STANDARD process for some time, there hasn't been
much deployment, if any, of it. Furthermore the reality of optical networks
today is that same vendor equipment is deployed in a single span.
Implementation of LMP in this case is at best optional. One may choose not
to implement LMP at all. IMHO tying this important interface to the fate of
LMP is not the way to proceed. How long LMP been at the IETF is irrelevant.
[John Drake] 
You're first arguing that if the interface is based upon LMP it's not
needed, and then arguing that if it's not based upon LMP that it's critical 
- NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP. 
[John Drake] 
Assertion not supported by the facts 
- The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your choice to use LMP to run LMP-WDM on top of it forced you to
treat the PXC and LS as peers. NTIP treats PXC-LS relationship as
master-slave. Non peer relationship suits this interface better.
[John Drake] 
Assertion not supported by the facts 
- To link with other standards bodies, as far as I know T1X1, where the
optical knowledge exists, is yet to ar rive to a definition of this
interface. More contributions are solicited to better understand its need
and applications. Given that, I'd like to understand the rationale for the
"rough consensus" reached at CCAMP mailing list. Only 4-5 messages were
posted to the mailing list and mostly from authors of the OLI requirements
draft.
[John Drake] 
I'm sure that there's a point here 
- I don't see harm in having two protocols. The market made its decisions on
the examples you mentioned, and I am sure it will happen again in this case.
[John Drake] 
The market has settled on RSVP-TE, so there's clearly an existence proof
that that the market prefers a single solution 
                        [Osama] totally a different situation. Please let me
know how much LMP installed base is out there today? However you seem to
agree with me that we can trust the market to make the decision.
Regards; 
Osama Aboul-Magd 
Nortel Networks 
P.O. Box 3511, Station "C" 
Ottawa, ON, Canada 
K1Y - 4H7 
Tel: 613-763-5827 
e.mail: [email-masked] 
 -----Original Message----- 
From:   Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Monday, July 23, 2001 10:01 PM 
To:     [email-masked] 
Subject:        Optical Link Interface 
Last month, the "Optical Link Interface (OLI) Requirements" document 
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
<http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt>  
was discussed on the ccamp mailing list and achieved "rough consensus" 
according to our working group co-chairs.  Given this, we'd like to make 
some progress on the protocol specification.  I'd like to generate some 
discussion on this mailing list before the IETF meeting in London because 
meaningful technical discussion cannot occur in the time allocated during 
the meeting. 
There have been two proposals in the IETF to satisfy the OLI requirements: 
1. [LMP-WDM]: 
"Link Management Protocol (LMP) for DWDM Optical Line Systems" 
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
<http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt>  
(note, this updated document was submitted Friday, so it should show up 
on the official website soon). 
and 
2. [NTIP]: 
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" 
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
<http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt>  
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while 
NTIP proposes a new protocol.  We believe that the LMP approach is best 
because: 
1. [LMP-WDM] satisfies the OLI Requirements. 
2. The extensions to LMP are quite natural and fit within the spirit of the 
LMP protocol. 
3. LMP is a reasonably mature IETF protocol specification: 
     - It has been in the works for well over a year. 
     - It is an official working group document. 
4. It is better to have one protocol, than two for a given function 
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 
5. Using the same protocol simplifies both implementation and management on 
devices, such as optical cross-connects and routers, that may need to use 
both simultaneously. 
While there is no doubt in my mind that NTIP could be made to satisfy the 
OLI requirements, It is my strong opinion that LMP should be the solution 
chosen by the CCAMP working group due to the reasons outlined above. 
Comments please! 
Regards, 
Andre 

------_=_NextPart_001_01C11528.0FEA6820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>RE: Optical Link Interface</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><font
color=3D"#3366ff" face=3D"Arial Black"><span =
style=3D'font-family:"Arial Black";
color:#3366FF'>Osama Aboul-Magd</span></font><font color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Nortel =
Networks</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>P.O. Box 3511, Station =
&quot;C&quot;</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Ottawa, ON, =
Canada</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>K1Y - 4H7</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Tel: =
613-763-5827</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>e.mail: =
[email-masked]</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle19><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> John Drake
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
11:47 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Aboul-Magd, Osama
[CAR:1A00:EXCH]; Andre Fredette; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font><font color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dnavy
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:72.0pt'><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Osama Aboul-Magd
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July =
25, 2001
8:15 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Andre Fredette;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Optical =
Link
Interface</span></font><font size=3D2 color=3Dnavy face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:navy;mso-color-alt:wi=
ndowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Andre,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Obviously I disagree with you in =
your
conclusion. There are number of factors that should be =
considered:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>- While LMP has been in STANDARD =
process
for some time, there hasn't been much deployment, if any, of it. =
Furthermore
the reality of optical networks today is that same vendor equipment is =
deployed
in a single span. Implementation of LMP in this case is at best =
optional. One
may choose not to implement LMP at all. IMHO tying this important =
interface to
the fate of LMP is not the way to proceed. How long LMP been at the =
IETF is
irrelevant.<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[John Drake]&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>You're first =
arguing that
if the interface is based upon LMP it's not needed, and then arguing =
that if
it's not based upon LMP that it's critical&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>- NTIP is a new TCP application =
in the
same way as LMP-WDM is a NEW application for LMP. <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[John Drake]&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Assertion not =
supported
by the facts&nbsp;</span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>- The issue is not really LMP vs =
TCP. NTIP
and LMP-WDM differ in the model itself. Your choice to use LMP to run =
LMP-WDM
on top of it forced you to treat the PXC and LS as peers. NTIP treats =
PXC-LS relationship
as master-slave. Non peer relationship suits this interface better.<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[John Drake]&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Assertion not =
supported
by the facts&nbsp;</span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>- To link with other standards =
bodies, as
far as I know T1X1, where the optical knowledge exists, is yet to =
ar&nbsp;rive
to a definition of this interface. More contributions are solicited to =
better
understand its need and applications. Given that, I'd like to =
understand the
rationale for the &quot;rough consensus&quot; reached at CCAMP mailing =
list.
Only 4-5 messages were posted to the mailing list and mostly from =
authors of
the OLI requirements draft.<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[John Drake]&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>I'm sure that =
there's a
point here&nbsp;</span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>- I don't see harm in having two
protocols. The market made its decisions on the examples you mentioned, =
and I
am sure it will happen again in this case.<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[John Drake]&nbsp;</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>The market has =
settled on
RSVP-TE, so there's&nbsp;clearly an existence proof that&nbsp;that the =
market
prefers a single solution&nbsp;</span></font><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><span class=3DEmailStyle19><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
span
style=3D'mso-tab-count:2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>[Osama]
totally a different situation. Please let me know how much LMP =
installed base
is out there today? However you seem to agree with me that we can trust =
the
market to make the decision.<o:p></o:p></span></font></span></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Regards;</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Osama =
Aboul-Magd</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Nortel Networks</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>P.O. Box 3511, Station &quot;C&quot;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Ottawa, ON, Canada</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>K1Y - 4H7</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Tel: 613-763-5827</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>e.mail: [email-masked]</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;-----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: &nbsp; Andre Fredette [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent:&nbsp;&nbsp; Monday, July 23, 2001 10:01 =
PM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Optical =
Link
Interface</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Last month, the &quot;Optical =
Link
Interface (OLI) Requirements&quot; document</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'><a
href=3D"http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.t=
xt"
target=3D"_blank">http://search.ietf.org/internet-drafts/draft-many-oli-=
reqts-00.txt</a></span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>was discussed on the ccamp mailing list and achieved =
&quot;rough
consensus&quot;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>according to our working group co-chairs.&nbsp; Given =
this, we'd
like to make</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>some progress on the protocol specification.&nbsp; I'd =
like to
generate some</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>discussion on this mailing list before the IETF meeting in =
London
because</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>meaningful technical discussion cannot occur in the time =
allocated
during</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>the meeting.</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>There have been two proposals in =
the IETF
to satisfy the OLI requirements:</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>1. [LMP-WDM]:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&quot;Link Management Protocol (LMP) for DWDM Optical Line
Systems&quot;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'><a
href=3D"http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt"
target=3D"_blank">http://www.photonex.com/other/draft-fredette-lmp-wdm-0=
2.txt</a></span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>(note, this updated document was submitted Friday, so it =
should
show up</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>on the official website soon).</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>and</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>2. [NTIP]:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&quot;Network Transport Interface Protocol (NTIP) for =
Photonic
Cross Connects&quot;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>(PXC) <a
href=3D"http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00=
.txt"
target=3D"_blank">http://search.ietf.org/internet-drafts/draft-sahay-cca=
mp-ntip-00.txt</a></span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>LMP-WDM proposes extensions to =
LMP to
satisfy the OLI requirements, while</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>NTIP proposes a new protocol.&nbsp; We believe that the =
LMP
approach is best</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>because:</span></font><font color=3Dblack><span =
style=3D'color:black'>
</span></font><font color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>1. [LMP-WDM] satisfies the OLI
Requirements.</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>2. The extensions to LMP are =
quite natural
and fit within the spirit of the</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>LMP protocol.</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>3. LMP is a reasonably mature =
IETF
protocol specification:</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp; - It has been in the works for =
well over
a year.</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp; - It is an official working group
document.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dnavy><span style=3D'color:navy;mso-color-alt:windowtext'><o:p></=
o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>4. It is better to have one =
protocol, than
two for a given function</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>(remember CR-LDP vs. RSVP-TE, and OSPF vs. =
IS-IS)</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>5. Using the same protocol =
simplifies both
implementation and management on</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>devices, such as optical cross-connects and routers, that =
may need
to use</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>both simultaneously.</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>While there is no doubt in my =
mind that
NTIP could be made to satisfy the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>OLI requirements, It is my strong opinion that LMP should =
be the
solution</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>chosen by the CCAMP working group due to the reasons =
outlined
above.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Comments =
please!</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Regards,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Andre</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------_=_NextPart_001_01C11528.0FEA6820--

Delivery-date: Wed, 25 Jul 2001 09:36:33 -0700
Date: Wed, 25 Jul 2001 12:34:38 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Martin Dubuc <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Queries regarding LMP.

Hi Martin, comments in-line

Martin Dubuc wrote:
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).

When you say "truly optical network", do you mean a network that has no
O/E/O (no 3R) at all? or is there some 3R at the edge?

As for mechanisms to isolate faults, I think this capability is already
part of networks. For example, SONET has mechanisms such as trace
identifiers, AIS/RDI signals, and tandem connection points for doing
this. OTN (G.709) also has these defined. In addition, OTN has defined 6
flexible layers for TCM and 2 fixed layer for TCM (section and path). 

I think LMP is not necessary for fault isolation, but it could be
another mechanism that may be used (if one so chooses). 

> 
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
> 
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
> 
> -----Original Message-----
> From: rajesh [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Queries regarding LMP.
> 
> Hi,
> 
>      Have a few queries regd LMP.
> 
> Q1)  Regd the applicability of LMP...
> 
> draft-many-gmpls-architecture-00.txt states that
> 
> "   For instance, the traditional IP routing model assumes the
>    establishment of a routing adjacency over each link connecting two
>    adjacent nodes. Having such a large number of adjacencies is not
>    scalable at all. Each node needs to maintain each of its adjacencies
>    one by one, and link state routing information must be flooded in
>    the topology for each link.
> 
>    To solve this issue the concept of bundling was introduced.
>    Moreover, the manual configuration and control of these links, even
>    if they are unnumbered, becomes totally impractical. The Link
>    Management Protocol (LMP) was specified to solve these problems. "
> 
> a) Can one assume that LMP makes sense ONLY in the case of a large
>      number of parallel links and link bundling...
> 
>       and an implementation of GMPLS neednot have LMP if no link
>       bundling is used ??
> 
>       The above maybe the case when using lower end SONET ADM,
>        DXCs...
> 
> b) Under what other conditions would one require LMP (ie other than
>       link bundling) ?
> 
> Q2) Suppose one does NOT need to use LMP but then one needs to use
>          OSPF extensions to support TE
> (draft-kompella-ospf-gmpls-extensions-01.txt) ,
> 
>         then one may need to do a  correlation of Link Ids between 2
> TE nodes.
> 
>        a) Is there a standard recommended way to do this correlation ??
> 
>              E.g OSPF - Link Local Signaling
>                     or OSPF - link scope LSA ?
> 
> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
>          are encoded as IP packets and also suggests protocol number
> 140.
> 
>           What would be the destination IP address of an LMP packet ??
> 
>            A multicast or is it got from an IGP ??
> 
> Q4) In LMP, if a Link Id correlation has been done,  and If the link ids
> 
>          on one of the ends or both change... How is this change taken
> into
>          account ??
> 
>          Eg for i = 1,2
>                           Port i, Node 1 connected to Port i, Node 2
> 
>           If one interchanges the connection then one has to recorrelate
> 
>            the Link Id mappings..
> 
> Thanks in advance,
> Rajesh

Delivery-date: Wed, 25 Jul 2001 09:01:01 -0700
content-class: urn:content-classes:message
Subject: RE: Queries regarding LMP.
Date:  Wed, 25 Jul 2001 11:58:31 -0400
From: "Martin Dubuc" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
control and data link health. To determine whether LMP is useful or not,
one has to look at the operational aspect of product deployment and
maintenance, i.e. what tools the vendor wants to implement to facilitate
provisioning and maintenance of their customers network. In a small
network, a vendor may be able to get away with manual configuration of
links. In an opaque network, it is also easy to pinpoint link failures.
However, in a truly optical network, there needs to be mechanisms to
isolate faults (which LMP provides).

Usefulness of LMP is not directly tied to use of link bundles. Link
bundles are mostly used to reduce the flooding of link information
generated by the routing protocol.

Q3) Destination address can be multicast or any valid IP address of
destination node (most likely the NodeID of the destination node).

-----Original Message-----
From: rajesh [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:59 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Queries regarding LMP.

Hi,

     Have a few queries regd LMP.

Q1)  Regd the applicability of LMP...

draft-many-gmpls-architecture-00.txt states that

"   For instance, the traditional IP routing model assumes the
   establishment of a routing adjacency over each link connecting two
   adjacent nodes. Having such a large number of adjacencies is not
   scalable at all. Each node needs to maintain each of its adjacencies
   one by one, and link state routing information must be flooded in
   the topology for each link.

   To solve this issue the concept of bundling was introduced.
   Moreover, the manual configuration and control of these links, even
   if they are unnumbered, becomes totally impractical. The Link
   Management Protocol (LMP) was specified to solve these problems. "

a) Can one assume that LMP makes sense ONLY in the case of a large
     number of parallel links and link bundling...

      and an implementation of GMPLS neednot have LMP if no link
      bundling is used ??

      The above maybe the case when using lower end SONET ADM,
       DXCs...

b) Under what other conditions would one require LMP (ie other than
      link bundling) ?

Q2) Suppose one does NOT need to use LMP but then one needs to use
         OSPF extensions to support TE
(draft-kompella-ospf-gmpls-extensions-01.txt) ,

        then one may need to do a  correlation of Link Ids between 2
TE nodes.

       a) Is there a standard recommended way to do this correlation ??

             E.g OSPF - Link Local Signaling
                    or OSPF - link scope LSA ?

Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
         are encoded as IP packets and also suggests protocol number
140.

          What would be the destination IP address of an LMP packet ??

           A multicast or is it got from an IGP ??

Q4) In LMP, if a Link Id correlation has been done,  and If the link ids

         on one of the ends or both change... How is this change taken
into
         account ??

         Eg for i =3D 1,2
                          Port i, Node 1 connected to Port i, Node 2

          If one interchanges the connection then one has to recorrelate

           the Link Id mappings..

Thanks in advance,
Rajesh

Delivery-date: Wed, 25 Jul 2001 08:59:24 -0700
From: Jonathan Lang <[email-masked]>
To: 'Osama Aboul-Magd' <[email-masked]>, Andre Fredette <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 08:53:28 -0700

Osama,
  Please see inline comments.

Thanks,
Jonathan

>-----Original Message-----
>From: Osama Aboul-Magd [mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 8:15 AM
>To: Andre Fredette; [email-masked]
>Subject: RE: Optical Link Interface
>
>
>Andre, 
>Obviously I disagree with you in your conclusion. There are number of
factors that should
> be considered: 
>- While LMP has been in STANDARD process for some time, there hasn't been
much deployment,
> if any, of it. Furthermore the reality of optical networks today is that
same vendor 
> equipment is deployed in a single span. Implementation of LMP in this case
is at best 
> optional. One may choose not to implement LMP at all. IMHO tying this
important interface 
> to the fate of LMP is not the way to proceed. How long LMP been at the
IETF is irrelevant.
> - NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP.
I'm glad you brought this up.  TCP greatly complicates the fault recovery
procedure and fault recovery is an essential aspect for this interface.

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your 
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers. 
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this 
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge 
> exists, is yet to arrive to a definition of this interface. More
contributions are 
> solicited to better understand its need and applications. Given that, I'd
like to 
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5 
> messages were posted to the mailing list and mostly from authors of the
OLI requirements 
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.

> Regards; 
> Osama Aboul-Magd 
> Nortel Networks 
> P.O. Box 3511, Station "C" 
> Ottawa, ON, Canada 
> K1Y - 4H7 
> Tel: 613-763-5827 
> e.mail: [email-masked] 
 -----Original Message----- 
From:   Andre Fredette [mailto:[email-masked]] 
Sent:   Monday, July 23, 2001 10:01 PM 
To:     [email-masked] 
Subject:        Optical Link Interface 
Last month, the "Optical Link Interface (OLI) Requirements" document 
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt 
was discussed on the ccamp mailing list and achieved "rough consensus" 
according to our working group co-chairs.  Given this, we'd like to make 
some progress on the protocol specification.  I'd like to generate some 
discussion on this mailing list before the IETF meeting in London because 
meaningful technical discussion cannot occur in the time allocated during 
the meeting. 
There have been two proposals in the IETF to satisfy the OLI requirements: 
1. [LMP-WDM]: 
"Link Management Protocol (LMP) for DWDM Optical Line Systems" 
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt 
(note, this updated document was submitted Friday, so it should show up 
on the official website soon). 
and 
2. [NTIP]: 
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" 
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt 
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while 
NTIP proposes a new protocol.  We believe that the LMP approach is best 
because: 
1. [LMP-WDM] satisfies the OLI Requirements. 
2. The extensions to LMP are quite natural and fit within the spirit of the 
LMP protocol. 
3. LMP is a reasonably mature IETF protocol specification: 
     - It has been in the works for well over a year. 
     - It is an official working group document. 
4. It is better to have one protocol, than two for a given function 
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 
5. Using the same protocol simplifies both implementation and management on 
devices, such as optical cross-connects and routers, that may need to use 
both simultaneously. 
While there is no doubt in my mind that NTIP could be made to satisfy the 
OLI requirements, It is my strong opinion that LMP should be the solution 
chosen by the CCAMP working group due to the reasons outlined above. 
Comments please! 
Regards, 
Andre 

Delivery-date: Wed, 25 Jul 2001 08:48:43 -0700
From: John Drake <[email-masked]>
To: 'Osama Aboul-Magd' <[email-masked]>, Andre Fredette <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 08:46:41 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11520.FFB62B30
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Osama Aboul-Magd [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 8:15 AM
To: Andre Fredette; [email-masked]
Subject: RE: Optical Link Interface

Andre, 

Obviously I disagree with you in your conclusion. There are number of
factors that should be considered: 

- While LMP has been in STANDARD process for some time, there hasn't been
much deployment, if any, of it. Furthermore the reality of optical networks
today is that same vendor equipment is deployed in a single span.
Implementation of LMP in this case is at best optional. One may choose not
to implement LMP at all. IMHO tying this important interface to the fate of
LMP is not the way to proceed. How long LMP been at the IETF is irrelevant.
[John Drake] 

You're first arguing that if the interface is based upon LMP it's not
needed, and then arguing that if it's not based upon LMP that it's critical 

- NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP. 
[John Drake] 

Assertion not supported by the facts 

- The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your choice to use LMP to run LMP-WDM on top of it forced you to
treat the PXC and LS as peers. NTIP treats PXC-LS relationship as
master-slave. Non peer relationship suits this interface better.
[John Drake] 

Assertion not supported by the facts 

- To link with other standards bodies, as far as I know T1X1, where the
optical knowledge exists, is yet to ar rive to a definition of this
interface. More contributions are solicited to better understand its need
and applications. Given that, I'd like to understand the rationale for the
"rough consensus" reached at CCAMP mailing list. Only 4-5 messages were
posted to the mailing list and mostly from authors of the OLI requirements
draft.
[John Drake] 

I'm sure that there's a point here 

- I don't see harm in having two protocols. The market made its decisions on
the examples you mentioned, and I am sure it will happen again in this case.
[John Drake] 

The market has settled on RSVP-TE, so there's clearly an existence proof
that that the market prefers a single solution 

Regards; 

Osama Aboul-Magd 
Nortel Networks 
P.O. Box 3511, Station "C" 
Ottawa, ON, Canada 
K1Y - 4H7 
Tel: 613-763-5827 
e.mail: [email-masked] 

 -----Original Message----- 
From:   Andre Fredette [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Monday, July 23, 2001 10:01 PM 
To:     [email-masked] 
Subject:        Optical Link Interface 

Last month, the "Optical Link Interface (OLI) Requirements" document 
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
<http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt>  
was discussed on the ccamp mailing list and achieved "rough consensus" 
according to our working group co-chairs.  Given this, we'd like to make 
some progress on the protocol specification.  I'd like to generate some 
discussion on this mailing list before the IETF meeting in London because 
meaningful technical discussion cannot occur in the time allocated during 
the meeting. 

There have been two proposals in the IETF to satisfy the OLI requirements: 

1. [LMP-WDM]: 
"Link Management Protocol (LMP) for DWDM Optical Line Systems" 
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
<http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt>  
(note, this updated document was submitted Friday, so it should show up 
on the official website soon). 

and 

2. [NTIP]: 
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" 
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
<http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt>  

LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while 
NTIP proposes a new protocol.  We believe that the LMP approach is best 
because: 

1. [LMP-WDM] satisfies the OLI Requirements. 

2. The extensions to LMP are quite natural and fit within the spirit of the 
LMP protocol. 

3. LMP is a reasonably mature IETF protocol specification: 
     - It has been in the works for well over a year. 
     - It is an official working group document. 

4. It is better to have one protocol, than two for a given function 
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 

5. Using the same protocol simplifies both implementation and management on 
devices, such as optical cross-connects and routers, that may need to use 
both simultaneously. 

While there is no doubt in my mind that NTIP could be made to satisfy the 
OLI requirements, It is my strong opinion that LMP should be the solution 
chosen by the CCAMP working group due to the reasons outlined above. 

Comments please! 

Regards, 
Andre 

------_=_NextPart_001_01C11520.FFB62B30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Optical Link Interface</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Osama Aboul-Magd 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, July 25, 2001 
  8:15 AM<BR><B>To:</B> Andre Fredette; [email-masked]<BR><B>Subject:</B> 
  RE: Optical Link Interface<BR><BR></DIV></FONT>
  <P><FONT size=2>Andre,</FONT> </P>
  <P><FONT size=2>Obviously I disagree with you in your conclusion. There are 
  number of factors that should be considered:</FONT> </P>
  <P><FONT size=2>- While LMP has been in STANDARD process for some time, there 
  hasn't been much deployment, if any, of it. Furthermore the reality of optical 
  networks today is that same vendor equipment is deployed in a single span. 
  Implementation of LMP in this case is at best optional. One may choose not to 
  implement LMP at all. IMHO tying this important interface to the fate of LMP 
  is not the way to proceed. How long LMP been at the IETF is 
  irrelevant.<BR><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>[John Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>You're first arguing that if the interface is based 
  upon LMP it's not needed, and then arguing that if it's not based upon LMP 
  that it's critical&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>- NTIP is a new TCP application in the same way as LMP-WDM is 
  a NEW application for LMP. <BR><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>[John Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>Assertion not supported by the 
  facts&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>- The issue is not really LMP vs TCP. NTIP and LMP-WDM differ 
  in the model itself. Your choice to use LMP to run LMP-WDM on top of it forced 
  you to treat the PXC and LS as peers. NTIP treats PXC-LS relationship as 
  master-slave. Non peer relationship suits this interface better.<BR><FONT 
  color=#0000ff face=Arial><SPAN class=297424515-25072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>Assertion not supported by the 
  facts&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>- To link with other standards bodies, as far as I know T1X1, 
  where the optical knowledge exists, is yet to ar<SPAN 
  class=297424515-25072001>&nbsp;</SPAN>rive to a definition of this interface. 
  More contributions are solicited to better understand its need and 
  applications. Given that, I'd like to understand the rationale for the "rough 
  consensus" reached at CCAMP mailing list. Only 4-5 messages were posted to the 
  mailing list and mostly from authors of the OLI requirements draft.<BR><FONT 
  color=#0000ff face=Arial><SPAN class=297424515-25072001>[John 
  Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>I'm sure that there's a point 
  here&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>- I don't see harm in having two protocols. The market made 
  its decisions on the examples you mentioned, and I am sure it will happen 
  again in this case.<BR><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>[John Drake]&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=297424515-25072001>The market has settled on RSVP-TE, so 
  there's&nbsp;clearly an existence proof that&nbsp;that the market prefers a 
  single solution&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>Regards;</FONT> </P>
  <P><FONT size=2>Osama Aboul-Magd</FONT> <BR><FONT size=2>Nortel 
  Networks</FONT> <BR><FONT size=2>P.O. Box 3511, Station "C"</FONT> <BR><FONT 
  size=2>Ottawa, ON, Canada</FONT> <BR><FONT size=2>K1Y - 4H7</FONT> <BR><FONT 
  size=2>Tel: 613-763-5827</FONT> <BR><FONT size=2>e.mail: 
  [email-masked]</FONT> </P>
  <P><FONT size=2>&nbsp;-----Original Message-----</FONT> <BR><FONT size=2>From: 
  &nbsp; Andre Fredette [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent:&nbsp;&nbsp; Monday, July 23, 2001 10:01 
  PM</FONT> <BR><FONT size=2>To:&nbsp;&nbsp;&nbsp;&nbsp; 
  [email-masked]</FONT> <BR><FONT 
  size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Optical Link 
  Interface</FONT> </P>
  <P><FONT size=2>Last month, the "Optical Link Interface (OLI) Requirements" 
  document</FONT> <BR><FONT size=2><A 
  href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" 
  target=_blank>http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</A></FONT> 
  <BR><FONT size=2>was discussed on the ccamp mailing list and achieved "rough 
  consensus"</FONT> <BR><FONT size=2>according to our working group 
  co-chairs.&nbsp; Given this, we'd like to make</FONT> <BR><FONT size=2>some 
  progress on the protocol specification.&nbsp; I'd like to generate some</FONT> 
  <BR><FONT size=2>discussion on this mailing list before the IETF meeting in 
  London because</FONT> <BR><FONT size=2>meaningful technical discussion cannot 
  occur in the time allocated during</FONT> <BR><FONT size=2>the meeting.</FONT> 
  </P>
  <P><FONT size=2>There have been two proposals in the IETF to satisfy the OLI 
  requirements:</FONT> </P>
  <P><FONT size=2>1. [LMP-WDM]:</FONT> <BR><FONT size=2>"Link Management 
  Protocol (LMP) for DWDM Optical Line Systems"</FONT> <BR><FONT size=2><A 
  href="http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt" 
  target=_blank>http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt</A></FONT> 
  <BR><FONT size=2>(note, this updated document was submitted Friday, so it 
  should show up</FONT> <BR><FONT size=2>on the official website soon).</FONT> 
  </P>
  <P><FONT size=2>and</FONT> </P>
  <P><FONT size=2>2. [NTIP]:</FONT> <BR><FONT size=2>"Network Transport 
  Interface Protocol (NTIP) for Photonic Cross Connects"</FONT> <BR><FONT 
  size=2>(PXC) <A 
  href="http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt" 
  target=_blank>http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt</A></FONT> 
  </P>
  <P><FONT size=2>LMP-WDM proposes extensions to LMP to satisfy the OLI 
  requirements, while</FONT> <BR><FONT size=2>NTIP proposes a new 
  protocol.&nbsp; We believe that the LMP approach is best</FONT> <BR><FONT 
  size=2>because:</FONT> </P>
  <P><FONT size=2>1. [LMP-WDM] satisfies the OLI Requirements.</FONT> </P>
  <P><FONT size=2>2. The extensions to LMP are quite natural and fit within the 
  spirit of the</FONT> <BR><FONT size=2>LMP protocol.</FONT> </P>
  <P><FONT size=2>3. LMP is a reasonably mature IETF protocol 
  specification:</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp; - It has been 
  in the works for well over a year.</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp; - It is an official working group 
  document.</FONT> </P>
  <P><FONT size=2>4. It is better to have one protocol, than two for a given 
  function</FONT> <BR><FONT size=2>(remember CR-LDP vs. RSVP-TE, and OSPF vs. 
  IS-IS)</FONT> </P>
  <P><FONT size=2>5. Using the same protocol simplifies both implementation and 
  management on</FONT> <BR><FONT size=2>devices, such as optical cross-connects 
  and routers, that may need to use</FONT> <BR><FONT size=2>both 
  simultaneously.</FONT> </P>
  <P><FONT size=2>While there is no doubt in my mind that NTIP could be made to 
  satisfy the</FONT> <BR><FONT size=2>OLI requirements, It is my strong opinion 
  that LMP should be the solution</FONT> <BR><FONT size=2>chosen by the CCAMP 
  working group due to the reasons outlined above.</FONT> </P>
  <P><FONT size=2>Comments please!</FONT> </P>
  <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Andre</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C11520.FFB62B30--

Delivery-date: Wed, 25 Jul 2001 08:18:48 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Andre Fredette <[email-masked]>, [email-masked]
Subject: RE: Optical Link Interface
Date: Wed, 25 Jul 2001 11:15:02 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1151C.937F5DF0
Content-Type: text/plain;
	charset="iso-8859-1"

Andre,

Obviously I disagree with you in your conclusion. There are number of
factors that should be considered:

- While LMP has been in STANDARD process for some time, there hasn't been
much deployment, if any, of it. Furthermore the reality of optical networks
today is that same vendor equipment is deployed in a single span.
Implementation of LMP in this case is at best optional. One may choose not
to implement LMP at all. IMHO tying this important interface to the fate of
LMP is not the way to proceed. How long LMP been at the IETF is irrelevant.

- NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP. 

- The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your choice to use LMP to run LMP-WDM on top of it forced you to
treat the PXC and LS as peers. NTIP treats PXC-LS relationship as
master-slave. Non peer relationship suits this interface better.

- To link with other standards bodies, as far as I know T1X1, where the
optical knowledge exists, is yet to arrive to a definition of this
interface. More contributions are solicited to better understand its need
and applications. Given that, I'd like to understand the rationale for the
"rough consensus" reached at CCAMP mailing list. Only 4-5 messages were
posted to the mailing list and mostly from authors of the OLI requirements
draft.

- I don't see harm in having two protocols. The market made its decisions on
the examples you mentioned, and I am sure it will happen again in this case.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Andre Fredette [mailto:[email-masked]] 
Sent:	Monday, July 23, 2001 10:01 PM
To:	[email-masked]
Subject:	Optical Link Interface

Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London because
meaningful technical discussion cannot occur in the time allocated during
the meeting.

There have been two proposals in the IETF to satisfy the OLI requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt

LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:

1. [LMP-WDM] satisfies the OLI Requirements.

2. The extensions to LMP are quite natural and fit within the spirit of the
LMP protocol.

3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.

4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)

5. Using the same protocol simplifies both implementation and management on
devices, such as optical cross-connects and routers, that may need to use
both simultaneously.

While there is no doubt in my mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should be the solution
chosen by the CCAMP working group due to the reasons outlined above.

Comments please!

Regards,
Andre

------_=_NextPart_001_01C1151C.937F5DF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Optical Link Interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Andre,</FONT>
</P>

<P><FONT SIZE=3D2>Obviously I disagree with you in your conclusion. =
There are number of factors that should be considered:</FONT>
</P>

<P><FONT SIZE=3D2>- While LMP has been in STANDARD process for some =
time, there hasn't been much deployment, if any, of it. Furthermore the =
reality of optical networks today is that same vendor equipment is =
deployed in a single span. Implementation of LMP in this case is at =
best optional. One may choose not to implement LMP at all. IMHO tying =
this important interface to the fate of LMP is not the way to proceed. =
How long LMP been at the IETF is irrelevant.</FONT></P>

<P><FONT SIZE=3D2>- NTIP is a new TCP application in the same way as =
LMP-WDM is a NEW application for LMP. </FONT>
</P>

<P><FONT SIZE=3D2>- The issue is not really LMP vs TCP. NTIP and =
LMP-WDM differ in the model itself. Your choice to use LMP to run =
LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP =
treats PXC-LS relationship as master-slave. Non peer relationship suits =
this interface better.</FONT></P>

<P><FONT SIZE=3D2>- To link with other standards bodies, as far as I =
know T1X1, where the optical knowledge exists, is yet to arrive to a =
definition of this interface. More contributions are solicited to =
better understand its need and applications. Given that, I'd like to =
understand the rationale for the &quot;rough consensus&quot; reached at =
CCAMP mailing list. Only 4-5 messages were posted to the mailing list =
and mostly from authors of the OLI requirements draft.</FONT></P>

<P><FONT SIZE=3D2>- I don't see harm in having two protocols. The =
market made its decisions on the examples you mentioned, and I am sure =
it will happen again in this case.</FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Andre Fredette [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Monday, July 23, 2001 10:01 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Optical Link Interface</FONT>
</P>

<P><FONT SIZE=3D2>Last month, the &quot;Optical Link Interface (OLI) =
Requirements&quot; document</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.t=
xt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-many-oli-=
reqts-00.txt</A></FONT>
<BR><FONT SIZE=3D2>was discussed on the ccamp mailing list and achieved =
&quot;rough consensus&quot;</FONT>
<BR><FONT SIZE=3D2>according to our working group co-chairs.&nbsp; =
Given this, we'd like to make</FONT>
<BR><FONT SIZE=3D2>some progress on the protocol specification.&nbsp; =
I'd like to generate some</FONT>
<BR><FONT SIZE=3D2>discussion on this mailing list before the IETF =
meeting in London because</FONT>
<BR><FONT SIZE=3D2>meaningful technical discussion cannot occur in the =
time allocated during</FONT>
<BR><FONT SIZE=3D2>the meeting.</FONT>
</P>

<P><FONT SIZE=3D2>There have been two proposals in the IETF to satisfy =
the OLI requirements:</FONT>
</P>

<P><FONT SIZE=3D2>1. [LMP-WDM]:</FONT>
<BR><FONT SIZE=3D2>&quot;Link Management Protocol (LMP) for DWDM =
Optical Line Systems&quot;</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt" =
TARGET=3D"_blank">http://www.photonex.com/other/draft-fredette-lmp-wdm-0=
2.txt</A></FONT>
<BR><FONT SIZE=3D2>(note, this updated document was submitted Friday, =
so it should show up</FONT>
<BR><FONT SIZE=3D2>on the official website soon).</FONT>
</P>

<P><FONT SIZE=3D2>and</FONT>
</P>

<P><FONT SIZE=3D2>2. [NTIP]:</FONT>
<BR><FONT SIZE=3D2>&quot;Network Transport Interface Protocol (NTIP) =
for Photonic Cross Connects&quot;</FONT>
<BR><FONT SIZE=3D2>(PXC) <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00=
.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-sahay-cca=
mp-ntip-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>LMP-WDM proposes extensions to LMP to satisfy the OLI =
requirements, while</FONT>
<BR><FONT SIZE=3D2>NTIP proposes a new protocol.&nbsp; We believe that =
the LMP approach is best</FONT>
<BR><FONT SIZE=3D2>because:</FONT>
</P>

<P><FONT SIZE=3D2>1. [LMP-WDM] satisfies the OLI Requirements.</FONT>
</P>

<P><FONT SIZE=3D2>2. The extensions to LMP are quite natural and fit =
within the spirit of the</FONT>
<BR><FONT SIZE=3D2>LMP protocol.</FONT>
</P>

<P><FONT SIZE=3D2>3. LMP is a reasonably mature IETF protocol =
specification:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; - It has been in the works =
for well over a year.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; - It is an official working =
group document.</FONT>
</P>

<P><FONT SIZE=3D2>4. It is better to have one protocol, than two for a =
given function</FONT>
<BR><FONT SIZE=3D2>(remember CR-LDP vs. RSVP-TE, and OSPF vs. =
IS-IS)</FONT>
</P>

<P><FONT SIZE=3D2>5. Using the same protocol simplifies both =
implementation and management on</FONT>
<BR><FONT SIZE=3D2>devices, such as optical cross-connects and routers, =
that may need to use</FONT>
<BR><FONT SIZE=3D2>both simultaneously.</FONT>
</P>

<P><FONT SIZE=3D2>While there is no doubt in my mind that NTIP could be =
made to satisfy the</FONT>
<BR><FONT SIZE=3D2>OLI requirements, It is my strong opinion that LMP =
should be the solution</FONT>
<BR><FONT SIZE=3D2>chosen by the CCAMP working group due to the reasons =
outlined above.</FONT>
</P>

<P><FONT SIZE=3D2>Comments please!</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Andre</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1151C.937F5DF0--

Delivery-date: Wed, 25 Jul 2001 07:44:53 -0700
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Latest SONET Specification
Date: Wed, 25 Jul 2001 10:20:25 -0400

The latest version is available via the T1X1.5 files as T1X1.5/2001-062:
ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC

Regards,
Deborah Brungard
AT&T

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 9:09 PM
To: [email-masked]
Subject: Latest SONET Specification

Hi All,
         Where can I find the latest SONET specs (which explains the SONET 
multiplexing structure) SONET ANSI T1.105-2000 ? Is it published ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 25 Jul 2001 05:59:02 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>
Cc: "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: ARE: [T1X1.5] arbitrary contiguous concatenation question
Date: Wed, 25 Jul 2001 14:55:51 +0200

Hello Juergen and Maarten,

I don't understand the relationship between
draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that you are =
talking
about.

In addition, the IETF is not specifying any SDH/SONET interoperability =
(Not
at all in the GMPLS scope).

Also, I am not sure to understand why the abstract (B, A) notation of =
G.707
(used to have a clearer specification, and not used (transported) in =
any
protocol as far as I know) could imply that contiguous time-slots are =
not
contiguous anymore ?

The "Arbitrary" concatenation that you are speaking about is a =
contiguous
concatenation, time-slots are physically contiguous. I don't understand =
the
relevance of the SDH (B, A) notation in relationship with SONET in the
context of the IETF. Anyway, contiguous time-slots will stay physically
contiguous even if you see an issue with the SDH G.707 (B, A) notation
applied to SONET.

Also, "flexible arbitrary concatenation" (whatever it is - everybody =
seems
to have a different understanding) is not part of
draft-ietf-ccamp-gmpls-sonet-sdh-01.txt.

I guess also that this discussion is relevant for the ITU-T and/or =
T1X1, not
for the ccamp mailing list (of the IETF).

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 4:28 PM
To: 'Maarten Vissers'; ccamp
Cc: t1x1.5; q11/15
Subject: AW: [T1X1.5] arbitrary contiguous concatenation question

Maarten,

good point. Lets hear what the supporters of arbitrary concatenation =
have to
say.

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: Maarten Vissers [mailto:[email-masked]]
> Gesendet: Dienstag, 10. Juli 2001 11:14
> An: ccamp
> Cc: t1x1.5; q11/15
> Betreff: [T1X1.5] arbitrary contiguous concatenation question
>=20
>=20
> All,
>=20
> draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling=20
> support for arbitrary
> contiguous concatenation in appendix 3. Looking a bit more=20
> into this arbitrary
> concatenation from the transport plane, I came across a=20
> question with respect to
> the definition of "contiguous STS-1/AU-3 timeslots". Let me=20
> introduce this
> question:
>=20
> Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within=20
> an STM-4) as
> follows
>=20
>      Time          111
>      Slot 123456789012123456789
>=20
> 	B 123412341234123412341...
> 	A 111122223333111122223...
>=20
> AU-3 timeslots have a TimeSlot number and a (B,A) number,=20
> with TS1 associated
> with (1,1) and TS12 associated with (4,3).
>=20
> 	Note - the figure in the pre-published version of G.707
> 	doesn't show the timeslot numbering in a correct manner.
>=20
> and the AU-4 numbering is as follows (figure 7-24/G.707)
>=20
>      Time
>      Slot 123412341234123412341
>=20
> 	B 123412341234123412341...
> 	A 000000000000000000000...
>=20
> An AU-4 [STS-3c] is as such essentially a "non-contiguous"=20
> concatenation of
> AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4=20
> (2,0) uses AU-3
> timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)].
>=20
>=20
> If we define STS-1 contiguous concatenation, which timeslots=20
> are then used for
> e.g. a STS-1-3c:
> 	i)  timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or
> 	ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9]
>=20
> Similarly, for the case of a STS-1-6c do we use:
> 	i)  (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2)=20
> [TS1,TS2,TS3,TS4,TS5,TS6] or
> 	ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3)=20
> [TS1,TS2,TS5,TS6,TS9,TS10]
>=20
>=20
> And which timeslots do we use for e.g. a STS-1-5c?
>=20
>=20
> If this detail is not specified, interworking is not possible=20
> unless we include
> the list of timeslots as we do with virtual concatenation=20
> (and as discussed for
> flexible arbitrary concatenation).
>=20
>=20
> Regards,
>=20
> Maarten
>=20

Delivery-date: Tue, 24 Jul 2001 18:11:52 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Latest SONET Specification
Date: Tue, 24 Jul 2001 18:09:00 -0700

Hi All,
         Where can I find the latest SONET specs (which explains the SONET 
multiplexing structure) SONET ANSI T1.105-2000 ? Is it published ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 24 Jul 2001 13:46:01 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Fwd: RE: {SUKLM} numbering scheme
Date: Tue, 24 Jul 2001 13:44:05 -0700

Hi Eric and Lou,
                   The new GMPLS signalling drafts still distinguish
between different SDH and SONET version of specifications (like 2000,
1995 etc.). Eric, As u said earlier that we will be having only one value 
for SDH and one for SONET LSP encoding type. please see the mail below for 
further information. I want to know that whether this has been done 
intentionally or it is just a bug that still need to be removed.

Please clarify.

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, [email-masked]
>CC: "[email-masked]'" <[email-masked]>
>Subject: RE: {SUKLM} numbering scheme
>Date: Thu, 28 Jun 2001 21:38:10 +0200
>
>Hello Manoj,
>
>The label is the same of course.
>
>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a
>small bug coming from an old version. That should be removed by Lou. We
>should have only one SDH LSP encoding type value for SDH (same for SONET).
>
>Lou: thanks to correct it.
>
>For the conversion table, Maarten should still have it.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Thursday, June 28, 2001 8:28 PM
>To: [email-masked]
>Subject: {SUKLM} numbering scheme
>
>
>Hi All,
>           I have a doubt regarding {SUKLM} numbering scheme. If I
>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
>ITU-T G.707 2000 ?
>
>Eric, on the ipo u and marteen once exchanged the conversion table for
>EDCBA and SU, If that table is correct, can u please tell me the
>formula from which u derived that table ?
>
>Regards,
>manoj.
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 24 Jul 2001 12:17:53 -0700
Date: Tue, 24 Jul 2001 15:14:18 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: new gmpls signaling drafts

FYI -

New versions of the GMPLS signaling drafts have been submitted.  We 
attempted to cover the major last call issues.  For those who don't want to 
wait, the drafts are available at:

http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt

Delivery-date: Tue, 24 Jul 2001 07:49:16 -0700
From: Heiles Juergen <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>
Cc: "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: AW: [T1X1.5] arbitrary contiguous concatenation question
Date: Tue, 24 Jul 2001 16:28:03 +0200

Maarten,

good point. Lets hear what the supporters of arbitrary concatenation =
have to say.

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: Maarten Vissers [mailto:[email-masked]]
> Gesendet: Dienstag, 10. Juli 2001 11:14
> An: ccamp
> Cc: t1x1.5; q11/15
> Betreff: [T1X1.5] arbitrary contiguous concatenation question
>=20
>=20
> All,
>=20
> draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling=20
> support for arbitrary
> contiguous concatenation in appendix 3. Looking a bit more=20
> into this arbitrary
> concatenation from the transport plane, I came across a=20
> question with respect to
> the definition of "contiguous STS-1/AU-3 timeslots". Let me=20
> introduce this
> question:
>=20
> Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within=20
> an STM-4) as
> follows
>=20
>      Time          111
>      Slot 123456789012123456789
>=20
> 	B 123412341234123412341...
> 	A 111122223333111122223...
>=20
> AU-3 timeslots have a TimeSlot number and a (B,A) number,=20
> with TS1 associated
> with (1,1) and TS12 associated with (4,3).
>=20
> 	Note - the figure in the pre-published version of G.707
> 	doesn't show the timeslot numbering in a correct manner.
>=20
> and the AU-4 numbering is as follows (figure 7-24/G.707)
>=20
>      Time
>      Slot 123412341234123412341
>=20
> 	B 123412341234123412341...
> 	A 000000000000000000000...
>=20
> An AU-4 [STS-3c] is as such essentially a "non-contiguous"=20
> concatenation of
> AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4=20
> (2,0) uses AU-3
> timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)].
>=20
>=20
> If we define STS-1 contiguous concatenation, which timeslots=20
> are then used for
> e.g. a STS-1-3c:
> 	i)  timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or
> 	ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9]
>=20
> Similarly, for the case of a STS-1-6c do we use:
> 	i)  (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2)=20
> [TS1,TS2,TS3,TS4,TS5,TS6] or
> 	ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3)=20
> [TS1,TS2,TS5,TS6,TS9,TS10]
>=20
>=20
> And which timeslots do we use for e.g. a STS-1-5c?
>=20
>=20
> If this detail is not specified, interworking is not possible=20
> unless we include
> the list of timeslots as we do with virtual concatenation=20
> (and as discussed for
> flexible arbitrary concatenation).
>=20
>=20
> Regards,
>=20
> Maarten
>=20

Delivery-date: Mon, 23 Jul 2001 19:06:42 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Date: Mon, 23 Jul 2001 22:00:46 -0400
Subject: Optical Link Interface

Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London because
meaningful technical discussion cannot occur in the time allocated during
the meeting.

There have been two proposals in the IETF to satisfy the OLI requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt

LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:

1. [LMP-WDM] satisfies the OLI Requirements.

2. The extensions to LMP are quite natural and fit within the spirit of the
LMP protocol.

3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.

4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)

5. Using the same protocol simplifies both implementation and management on
devices, such as optical cross-connects and routers, that may need to use
both simultaneously.

While there is no doubt in my mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should be the solution
chosen by the CCAMP working group due to the reasons outlined above.

Comments please!

Regards,
Andre

Delivery-date: Fri, 20 Jul 2001 18:05:55 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Bi-directional LSPs Incompatibility
Date: Fri, 20 Jul 2001 18:03:19 -0700

Hi Eric,
          I was going through the OIF Signallng working group mail
archive. I found one mail related to making the RESVCONF message
mandatory. There were mails exchanged in OIF on 2nd July related to
this thread. Fong Liaw mentioned some advantages of keeping the
RESVCONF message.
Fong stated the following text :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"One reason for not pre-program the cross-connect in the forward
direction is to prevent misbehaved (destination) client taking
advantages of the pre-programmed cross-connect, send traffic
and then reject the connection to avoid billing. This was a big
problem for voice calls and I also heard Curtis raised the concern of
pre-programming at one of the OIF meeting."

p.s. The ResvConf message is really an advisory message. There
are other ways to find out if the cross-connect has been programmed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Even Osama Aboul-Magd of Nortel has agreed to put this type of 3-way
handshake in LDP. Osama defined new status code "reservation confirmed"
in the notification message.
So, I think it will not going to be removed. So, probably GMPLS has to
add this in the new revision.

Please comment.

Regards,
manoj.

>From: Eric Gray <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: Bi-directional LSPs Incompatibility
>Date: Thu, 19 Jul 2001 10:58:02 -0400
>
>Manoj ,
>
>     George's point is that strict alignment does not need to be a goal.
>If you look at the O-UNI as a user of GMPLS services, there is no
>reason to expect this user to use all available services.
>
>--
>Eric Gray
>
>You wrote:
>
> > Hi George,
> >             As long as both the documents are not aligned, we can say 
>there
> > is some incompatibility. I think one can argue it in both ways. Is it a
> > incompatibility or a feature that GMPLS offers but UNI is unable to make 
>use
> > of it ?
> >
> > Regards,
> > manoj.
> >
> > >From: George Swallow <[email-masked]>
> > >To: "manoj juneja" <[email-masked]>
> > >CC: [email-masked], [email-masked]
> > >Subject: Re: Bi-directional LSPs Incompatibility
> > >Date: Wed, 18 Jul 2001 18:23:39 -0400
> > >
> > > > Hi All,
> > > >         There is some incompatibility in documents of OIF
> > > > (oif2000.125.5) and IETF 
>(draft-ietf-mpls-generalized-rsvp-te-03.txt)
> > > > related to bidirectional LSPs. OIF's O-UNI document says [docId
> > > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> > > > insert a RESV_CONFIRM object in the RESV message and should wait for
> > > > ResvConf message before start transmitting data.
> > > > But, the IETF document says the terminator node process path message
> > > > as usual with the exception that the upstream label can immediately 
>be
> > > > used to transport data traffic associated with the LSP upstream 
>towards
> > > > the initiator.
> > > >
> > > > Please Help.
> > > >
> > > > Regards,
> > > > manoj.
> > >
> > >I don't see a problem in this case.  Having the two ends more
> > >constrained than the middle as to when a circuit can be considered in
> > >service doesn't seem to present a problem.
> > >
> > >But my personal opinion is that the RESV Conf should be optional for
> > >the UNI.
> > >
> > >...George
> > >
> > >==================================================================
> > >George Swallow       Cisco Systems                   (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 20 Jul 2001 14:28:59 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: LMP questions
Date: Fri, 20 Jul 2001 14:27:05 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11162.B9212970
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Jonathan,

How does LMP respond to adjacent link failures? i.e., how does
lmp converge on adjacent data link failures for fault location
identification? this case has not been discussed in the draft.

rgds
bhaskara

-----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Friday, July 20, 2001 2:11 PM
To: 'Adnan Ahmed'; Jonathan Lang; [email-masked]
Cc: Saibal Das
Subject: RE: LMP questions

Adnan,
  In your example, you need to run an LMP control channel between B and C.
This control channel could be tunneled through A.

Thanks,
Jonathan

> -----Original Message-----
> From: Adnan Ahmed [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 4:02 PM
> To: Jonathan Lang; [email-masked]
> Cc: Saibal Das
> Subject: Re: LMP questions
> 
> 
> Jonathan:
> 
> I have a follow up question related to your response:
> 
> "Assuming that the control channels utilize an out-of-band 
> network (such
> as Ethernet) will the control channel topology i.e. the physical
> infrastructure used to realize the CCs, match the fiber topology?
> [Jonathan] The control channel topology does not need to 
> match the fiber
> technology."
> 
> Consider this scenario involving three OXCs where:
> 
> - OXCs A, B and C are connected to each other through fiber
> - Control channel CC-1 is setup b/w A & B and a control 
> channel CC-2 is
> setup b/w A & C.
> 
> Does your response above imply that it is possible to setup 
> TE/data bearing
> links between OXCs B and C by utilizing CC-1 and CC-2 without a direct
> control channel between them?
> 
> Thank you for your help.
> -- Adnan
> 
> 
> ----- Original Message -----
> From: "Jonathan Lang" <[email-masked]>
> To: "'Adnan Ahmed'" <[email-masked]>; <[email-masked]>
> Cc: "Saibal Das" <[email-masked]>
> Sent: Friday, July 20, 2001 1:38 PM
> Subject: RE: LMP questions
> 
> 
> > Adnan,
> >   Please see inline comments.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Adnan Ahmed [mailto:[email-masked]]
> > Sent: Friday, July 20, 2001 10:59 AM
> > To: [email-masked]
> > Cc: Saibal Das
> > Subject: LMP questions
> >
> >
> > Hello:
> >
> > I have some questions regarding LMP:
> >
> > 1. What mechanism is used to automatically setup control 
> channels b/w two
> > nodes? Will the user or managing application update the 
> lmpNbrTable with
> > neighbouring nodes before a node initiates control channel 
> setup, or is a
> > node required to incoporate some sort of "ping" to discover 
> noeghbours and
> > then initiate CC setup?
> > [Jonathan] Currently, the draft doesn't specify a mechanism to
> automatically
> > setup control channels.  There has been some work done in 
> the OIF to do
> > this.
> >
> > 2. Assuming that the control channels utilize an 
> out-of-band network (such
> > as Ethernet) will the control channel topology i.e. the physical
> > infrastructure used to realize the CCs, match the fiber topology?
> > [Jonathan] The control channel topology does not need to 
> match the fiber
> > technology.
> >
> > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or 
> are LMP TE links
> > only between adjacent elements?
> > [Jonathan] As LMP is currently defined, it is only between adjacent
> > elements.
> >
> > 4. The current LMP draft does not specify how TE links 
> formed by LMP are
> > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this
> > information from LMP?
> > [Jonathan] This is implementation dependent.
> >
> >
> > Regards,
> > ====
> > Adnan Ahmed
> > [V] 972.503.8881 x222            [F] 972.503.8885
> >
> >
> >
> 

------_=_NextPart_001_01C11162.B9212970
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: LMP questions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Jonathan,</FONT>
</P>

<P><FONT SIZE=2>How does LMP respond to adjacent link failures? i.e., how does</FONT>
<BR><FONT SIZE=2>lmp converge on adjacent data link failures for fault location</FONT>
<BR><FONT SIZE=2>identification? this case has not been discussed in the draft.</FONT>
</P>

<P><FONT SIZE=2>rgds</FONT>
<BR><FONT SIZE=2>bhaskara</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jonathan Lang [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, July 20, 2001 2:11 PM</FONT>
<BR><FONT SIZE=2>To: 'Adnan Ahmed'; Jonathan Lang; [email-masked]</FONT>
<BR><FONT SIZE=2>Cc: Saibal Das</FONT>
<BR><FONT SIZE=2>Subject: RE: LMP questions</FONT>
</P>
<BR>

<P><FONT SIZE=2>Adnan,</FONT>
<BR><FONT SIZE=2>&nbsp; In your example, you need to run an LMP control channel between B and C.</FONT>
<BR><FONT SIZE=2>This control channel could be tunneled through A.</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Jonathan</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Adnan Ahmed [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, July 20, 2001 4:02 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Jonathan Lang; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Saibal Das</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: LMP questions</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Jonathan:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have a follow up question related to your response:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;Assuming that the control channels utilize an out-of-band </FONT>
<BR><FONT SIZE=2>&gt; network (such</FONT>
<BR><FONT SIZE=2>&gt; as Ethernet) will the control channel topology i.e. the physical</FONT>
<BR><FONT SIZE=2>&gt; infrastructure used to realize the CCs, match the fiber topology?</FONT>
<BR><FONT SIZE=2>&gt; [Jonathan] The control channel topology does not need to </FONT>
<BR><FONT SIZE=2>&gt; match the fiber</FONT>
<BR><FONT SIZE=2>&gt; technology.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Consider this scenario involving three OXCs where:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - OXCs A, B and C are connected to each other through fiber</FONT>
<BR><FONT SIZE=2>&gt; - Control channel CC-1 is setup b/w A &amp; B and a control </FONT>
<BR><FONT SIZE=2>&gt; channel CC-2 is</FONT>
<BR><FONT SIZE=2>&gt; setup b/w A &amp; C.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Does your response above imply that it is possible to setup </FONT>
<BR><FONT SIZE=2>&gt; TE/data bearing</FONT>
<BR><FONT SIZE=2>&gt; links between OXCs B and C by utilizing CC-1 and CC-2 without a direct</FONT>
<BR><FONT SIZE=2>&gt; control channel between them?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you for your help.</FONT>
<BR><FONT SIZE=2>&gt; -- Adnan</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=2>&gt; From: &quot;Jonathan Lang&quot; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt; To: &quot;'Adnan Ahmed'&quot; &lt;[email-masked]&gt;; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt; Cc: &quot;Saibal Das&quot; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, July 20, 2001 1:38 PM</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: LMP questions</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Adnan,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Please see inline comments.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt; Jonathan</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Adnan Ahmed [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Friday, July 20, 2001 10:59 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Saibal Das</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: LMP questions</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hello:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I have some questions regarding LMP:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 1. What mechanism is used to automatically setup control </FONT>
<BR><FONT SIZE=2>&gt; channels b/w two</FONT>
<BR><FONT SIZE=2>&gt; &gt; nodes? Will the user or managing application update the </FONT>
<BR><FONT SIZE=2>&gt; lmpNbrTable with</FONT>
<BR><FONT SIZE=2>&gt; &gt; neighbouring nodes before a node initiates control channel </FONT>
<BR><FONT SIZE=2>&gt; setup, or is a</FONT>
<BR><FONT SIZE=2>&gt; &gt; node required to incoporate some sort of &quot;ping&quot; to discover </FONT>
<BR><FONT SIZE=2>&gt; noeghbours and</FONT>
<BR><FONT SIZE=2>&gt; &gt; then initiate CC setup?</FONT>
<BR><FONT SIZE=2>&gt; &gt; [Jonathan] Currently, the draft doesn't specify a mechanism to</FONT>
<BR><FONT SIZE=2>&gt; automatically</FONT>
<BR><FONT SIZE=2>&gt; &gt; setup control channels.&nbsp; There has been some work done in </FONT>
<BR><FONT SIZE=2>&gt; the OIF to do</FONT>
<BR><FONT SIZE=2>&gt; &gt; this.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2. Assuming that the control channels utilize an </FONT>
<BR><FONT SIZE=2>&gt; out-of-band network (such</FONT>
<BR><FONT SIZE=2>&gt; &gt; as Ethernet) will the control channel topology i.e. the physical</FONT>
<BR><FONT SIZE=2>&gt; &gt; infrastructure used to realize the CCs, match the fiber topology?</FONT>
<BR><FONT SIZE=2>&gt; &gt; [Jonathan] The control channel topology does not need to </FONT>
<BR><FONT SIZE=2>&gt; match the fiber</FONT>
<BR><FONT SIZE=2>&gt; &gt; technology.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or </FONT>
<BR><FONT SIZE=2>&gt; are LMP TE links</FONT>
<BR><FONT SIZE=2>&gt; &gt; only between adjacent elements?</FONT>
<BR><FONT SIZE=2>&gt; &gt; [Jonathan] As LMP is currently defined, it is only between adjacent</FONT>
<BR><FONT SIZE=2>&gt; &gt; elements.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 4. The current LMP draft does not specify how TE links </FONT>
<BR><FONT SIZE=2>&gt; formed by LMP are</FONT>
<BR><FONT SIZE=2>&gt; &gt; updated into OSPF. Is this LMPs responsiblity or will OSPF pull this</FONT>
<BR><FONT SIZE=2>&gt; &gt; information from LMP?</FONT>
<BR><FONT SIZE=2>&gt; &gt; [Jonathan] This is implementation dependent.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; ====</FONT>
<BR><FONT SIZE=2>&gt; &gt; Adnan Ahmed</FONT>
<BR><FONT SIZE=2>&gt; &gt; [V] 972.503.8881 x222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [F] 972.503.8885</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11162.B9212970--

Delivery-date: Fri, 20 Jul 2001 14:15:28 -0700
From: Jonathan Lang <[email-masked]>
To: 'Adnan Ahmed' <[email-masked]>, Jonathan Lang <[email-masked]>,  [email-masked]
Cc: Saibal Das <[email-masked]>
Subject: RE: LMP questions
Date: Fri, 20 Jul 2001 14:10:52 -0700

Adnan,
  In your example, you need to run an LMP control channel between B and C.
This control channel could be tunneled through A.

Thanks,
Jonathan

> -----Original Message-----
> From: Adnan Ahmed [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 4:02 PM
> To: Jonathan Lang; [email-masked]
> Cc: Saibal Das
> Subject: Re: LMP questions
> 
> 
> Jonathan:
> 
> I have a follow up question related to your response:
> 
> "Assuming that the control channels utilize an out-of-band 
> network (such
> as Ethernet) will the control channel topology i.e. the physical
> infrastructure used to realize the CCs, match the fiber topology?
> [Jonathan] The control channel topology does not need to 
> match the fiber
> technology."
> 
> Consider this scenario involving three OXCs where:
> 
> - OXCs A, B and C are connected to each other through fiber
> - Control channel CC-1 is setup b/w A & B and a control 
> channel CC-2 is
> setup b/w A & C.
> 
> Does your response above imply that it is possible to setup 
> TE/data bearing
> links between OXCs B and C by utilizing CC-1 and CC-2 without a direct
> control channel between them?
> 
> Thank you for your help.
> -- Adnan
> 
> 
> ----- Original Message -----
> From: "Jonathan Lang" <[email-masked]>
> To: "'Adnan Ahmed'" <[email-masked]>; <[email-masked]>
> Cc: "Saibal Das" <[email-masked]>
> Sent: Friday, July 20, 2001 1:38 PM
> Subject: RE: LMP questions
> 
> 
> > Adnan,
> >   Please see inline comments.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Adnan Ahmed [mailto:[email-masked]]
> > Sent: Friday, July 20, 2001 10:59 AM
> > To: [email-masked]
> > Cc: Saibal Das
> > Subject: LMP questions
> >
> >
> > Hello:
> >
> > I have some questions regarding LMP:
> >
> > 1. What mechanism is used to automatically setup control 
> channels b/w two
> > nodes? Will the user or managing application update the 
> lmpNbrTable with
> > neighbouring nodes before a node initiates control channel 
> setup, or is a
> > node required to incoporate some sort of "ping" to discover 
> noeghbours and
> > then initiate CC setup?
> > [Jonathan] Currently, the draft doesn't specify a mechanism to
> automatically
> > setup control channels.  There has been some work done in 
> the OIF to do
> > this.
> >
> > 2. Assuming that the control channels utilize an 
> out-of-band network (such
> > as Ethernet) will the control channel topology i.e. the physical
> > infrastructure used to realize the CCs, match the fiber topology?
> > [Jonathan] The control channel topology does not need to 
> match the fiber
> > technology.
> >
> > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or 
> are LMP TE links
> > only between adjacent elements?
> > [Jonathan] As LMP is currently defined, it is only between adjacent
> > elements.
> >
> > 4. The current LMP draft does not specify how TE links 
> formed by LMP are
> > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this
> > information from LMP?
> > [Jonathan] This is implementation dependent.
> >
> >
> > Regards,
> > ====
> > Adnan Ahmed
> > [V] 972.503.8881 x222            [F] 972.503.8885
> >
> >
> >
> 

Delivery-date: Fri, 20 Jul 2001 14:04:45 -0700
From: "Adnan Ahmed" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>, <[email-masked]>
Cc: "Saibal Das" <[email-masked]>
Subject: Re: LMP questions
Date: Fri, 20 Jul 2001 16:02:15 -0700
Organization: Varros Telecom

Jonathan:

I have a follow up question related to your response:

"Assuming that the control channels utilize an out-of-band network (such
as Ethernet) will the control channel topology i.e. the physical
infrastructure used to realize the CCs, match the fiber topology?
[Jonathan] The control channel topology does not need to match the fiber
technology."

Consider this scenario involving three OXCs where:

- OXCs A, B and C are connected to each other through fiber
- Control channel CC-1 is setup b/w A & B and a control channel CC-2 is
setup b/w A & C.

Does your response above imply that it is possible to setup TE/data bearing
links between OXCs B and C by utilizing CC-1 and CC-2 without a direct
control channel between them?

Thank you for your help.
-- Adnan

----- Original Message -----
From: "Jonathan Lang" <[email-masked]>
To: "'Adnan Ahmed'" <[email-masked]>; <[email-masked]>
Cc: "Saibal Das" <[email-masked]>
Sent: Friday, July 20, 2001 1:38 PM
Subject: RE: LMP questions

> Adnan,
>   Please see inline comments.
>
> Thanks,
> Jonathan
>
> -----Original Message-----
> From: Adnan Ahmed [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 10:59 AM
> To: [email-masked]
> Cc: Saibal Das
> Subject: LMP questions
>
>
> Hello:
>
> I have some questions regarding LMP:
>
> 1. What mechanism is used to automatically setup control channels b/w two
> nodes? Will the user or managing application update the lmpNbrTable with
> neighbouring nodes before a node initiates control channel setup, or is a
> node required to incoporate some sort of "ping" to discover noeghbours and
> then initiate CC setup?
> [Jonathan] Currently, the draft doesn't specify a mechanism to
automatically
> setup control channels.  There has been some work done in the OIF to do
> this.
>
> 2. Assuming that the control channels utilize an out-of-band network (such
> as Ethernet) will the control channel topology i.e. the physical
> infrastructure used to realize the CCs, match the fiber topology?
> [Jonathan] The control channel topology does not need to match the fiber
> technology.
>
> 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE links
> only between adjacent elements?
> [Jonathan] As LMP is currently defined, it is only between adjacent
> elements.
>
> 4. The current LMP draft does not specify how TE links formed by LMP are
> updated into OSPF. Is this LMPs responsiblity or will OSPF pull this
> information from LMP?
> [Jonathan] This is implementation dependent.
>
>
> Regards,
> ====
> Adnan Ahmed
> [V] 972.503.8881 x222            [F] 972.503.8885
>
>
>

Delivery-date: Fri, 20 Jul 2001 13:43:54 -0700
From: Jonathan Lang <[email-masked]>
To: 'Adnan Ahmed' <[email-masked]>, [email-masked]
Cc: Saibal Das <[email-masked]>
Subject: RE: LMP questions
Date: Fri, 20 Jul 2001 13:38:39 -0700

Adnan,
  Please see inline comments.

Thanks,
Jonathan

-----Original Message-----
From: Adnan Ahmed [mailto:[email-masked]]
Sent: Friday, July 20, 2001 10:59 AM
To: [email-masked]
Cc: Saibal Das
Subject: LMP questions

Hello:

I have some questions regarding LMP:

1. What mechanism is used to automatically setup control channels b/w two
nodes? Will the user or managing application update the lmpNbrTable with
neighbouring nodes before a node initiates control channel setup, or is a
node required to incoporate some sort of "ping" to discover noeghbours and
then initiate CC setup?
[Jonathan] Currently, the draft doesn't specify a mechanism to automatically
setup control channels.  There has been some work done in the OIF to do
this.

2. Assuming that the control channels utilize an out-of-band network (such
as Ethernet) will the control channel topology i.e. the physical
infrastructure used to realize the CCs, match the fiber topology?
[Jonathan] The control channel topology does not need to match the fiber
technology.

3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE links
only between adjacent elements?
[Jonathan] As LMP is currently defined, it is only between adjacent
elements.

4. The current LMP draft does not specify how TE links formed by LMP are
updated into OSPF. Is this LMPs responsiblity or will OSPF pull this
information from LMP?
[Jonathan] This is implementation dependent.

Regards,
====
Adnan Ahmed
[V] 972.503.8881 x222            [F] 972.503.8885

Delivery-date: Fri, 20 Jul 2001 09:04:33 -0700
From: "Adnan Ahmed" <[email-masked]>
To: <[email-masked]>
Cc: "Saibal Das" <[email-masked]>
Subject: LMP questions
Date: Fri, 20 Jul 2001 10:59:11 -0700
Organization: Varros Telecom

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01C1110B.01BF6F00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello:

I have some questions regarding LMP:

1. What mechanism is used to automatically setup control channels b/w =
two nodes? Will the user or managing application update the lmpNbrTable =
with neighbouring nodes before a node initiates control channel setup, =
or is a node required to incoporate some sort of "ping" to discover =
noeghbours and then initiate CC setup?

2. Assuming that the control channels utilize an out-of-band network =
(such as Ethernet) will the control channel topology i.e. the physical =
infrastructure used to realize the CCs, match the fiber topology?

3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE =
links only between adjacent elements?

4. The current LMP draft does not specify how TE links formed by LMP are =
updated into OSPF. Is this LMPs responsiblity or will OSPF pull this =
information from LMP?

Regards,
=3D=3D=3D=3D
Adnan Ahmed
[V] 972.503.8881 x222            [F] 972.503.8885

------=_NextPart_000_006A_01C1110B.01BF6F00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have some questions regarding =
LMP:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. What mechanism is used to =
automatically setup=20
control channels b/w two nodes? Will the user or managing application =
update the=20
lmpNbrTable with neighbouring nodes before a node initiates control =
channel=20
setup, or is a node required to incoporate some sort of "ping" to =
discover=20
noeghbours and then initiate CC setup?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. Assuming that the control channels =
utilize an=20
out-of-band network (such as Ethernet) will the control channel topology =
i.e.=20
the physical infrastructure used to realize the CCs, match the fiber=20
topology?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3. Can&nbsp;LMP TE links span multiple =
OXCs (as=20
FA-LSPs do) or are LMP TE links only between adjacent =
elements?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>4. The current LMP draft does not =
specify how TE=20
links formed by LMP are updated into OSPF. Is this LMPs responsiblity or =
will=20
OSPF pull this information from LMP?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR>Regards,<BR>=3D=3D=3D=3D<BR>Adnan =
Ahmed</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>[V] 972.503.8881=20
x222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[F]=20
972.503.8885</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006A_01C1110B.01BF6F00--

Delivery-date: Fri, 20 Jul 2001 07:52:39 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: [email-masked]
Subject: draft-tempest-mpls-ccamp-rsvp-resync-00.txt
Date: Fri, 20 Jul 2001 10:48:06 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1112A.FC7E0360
Content-Type: text/plain;
	charset="iso-8859-1"

The draft "draft-tempest-mpls-ccamp-rsvp-resync-00.txt" has been submitted

http://search.ietf.org/internet-drafts/draft-tempest-mpls-ccamp-rsvp-resync-
00.txt

Abstract:
This draft describes a mechanism for recovery after control channel failure
in RSVP-TE.  The draft introduces a procedure for state re-synchronization
between two neighboring LSRs.   

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

------_=_NextPart_001_01C1112A.FC7E0360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>draft-tempest-mpls-ccamp-rsvp-resync-00.txt</TITLE>
</HEAD>
<BODY>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The =
draft &quot;draft-tempest-mpls-ccamp-rsvp-resync-00.txt&quot; has been =
submitted</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-tempest-mpls-ccamp-=
rsvp-resync-00.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-tempest-m=
pls-ccamp-rsvp-resync-00.txt</A></FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Abstract:</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">This draft describes a mechanism for recovery after control =
channel</FONT> <FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">failure in RSVP-TE.&nbsp; The d</FONT><FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial Unicode MS">raft introduces a procedure for =
state re-</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">synchronization between two neighboring LSRs.&nbsp;&nbsp;</FONT> =
</P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">R</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">egards;</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial =
Black">Osama Aboul-Magd</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Nortel =
Networks</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">P.O. =
Box 3511, Station &quot;C&quot;</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Ottawa, =
ON, Canada</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">K1Y - =
4H7</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel: =
613-763-5827</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">e.mail: =
[email-masked]</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C1112A.FC7E0360--

Delivery-date: Thu, 19 Jul 2001 14:47:29 -0700
From: "S Kalipatnapu" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "manoj juneja" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Bi-directional LSPs Incompatibility
Date: Thu, 19 Jul 2001 18:58:52 -0400

Manoj,

MPLS Label Switched Paths are inherently uni-directional, while GMPLS lambda
swithed paths are inherently bi-directional. Given that the two approaches
in establishing/reserving resources for a path in the network need not be
strictly the same.

Regards,
--Sitaram

----- Original Message -----
From: "Eric Gray" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 19, 2001 10:58 AM
Subject: Re: Bi-directional LSPs Incompatibility

> Manoj ,
>
>     George's point is that strict alignment does not need to be a goal.
> If you look at the O-UNI as a user of GMPLS services, there is no
> reason to expect this user to use all available services.
>
> --
> Eric Gray
>
> You wrote:
>
> > Hi George,
> >             As long as both the documents are not aligned, we can say
there
> > is some incompatibility. I think one can argue it in both ways. Is it a
> > incompatibility or a feature that GMPLS offers but UNI is unable to make
use
> > of it ?
> >
> > Regards,
> > manoj.
> >
> > >From: George Swallow <[email-masked]>
> > >To: "manoj juneja" <[email-masked]>
> > >CC: [email-masked], [email-masked]
> > >Subject: Re: Bi-directional LSPs Incompatibility
> > >Date: Wed, 18 Jul 2001 18:23:39 -0400
> > >
> > > > Hi All,
> > > >         There is some incompatibility in documents of OIF
> > > > (oif2000.125.5) and IETF
(draft-ietf-mpls-generalized-rsvp-te-03.txt)
> > > > related to bidirectional LSPs. OIF's O-UNI document says [docId
> > > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> > > > insert a RESV_CONFIRM object in the RESV message and should wait for
> > > > ResvConf message before start transmitting data.
> > > > But, the IETF document says the terminator node process path message
> > > > as usual with the exception that the upstream label can immediately
be
> > > > used to transport data traffic associated with the LSP upstream
towards
> > > > the initiator.
> > > >
> > > > Please Help.
> > > >
> > > > Regards,
> > > > manoj.
> > >
> > >I don't see a problem in this case.  Having the two ends more
> > >constrained than the middle as to when a circuit can be considered in
> > >service doesn't seem to present a problem.
> > >
> > >But my personal opinion is that the RESV Conf should be optional for
> > >the UNI.
> > >
> > >...George
> > >
> > >==================================================================
> > >George Swallow       Cisco Systems                   (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
>

Delivery-date: Thu, 19 Jul 2001 07:59:52 -0700
Date: Thu, 19 Jul 2001 10:58:02 -0400
From: Eric Gray <[email-masked]>
To: manoj juneja <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bi-directional LSPs Incompatibility

Manoj ,

    George's point is that strict alignment does not need to be a goal.
If you look at the O-UNI as a user of GMPLS services, there is no
reason to expect this user to use all available services.

--
Eric Gray

You wrote:

> Hi George,
>             As long as both the documents are not aligned, we can say there
> is some incompatibility. I think one can argue it in both ways. Is it a
> incompatibility or a feature that GMPLS offers but UNI is unable to make use
> of it ?
>
> Regards,
> manoj.
>
> >From: George Swallow <[email-masked]>
> >To: "manoj juneja" <[email-masked]>
> >CC: [email-masked], [email-masked]
> >Subject: Re: Bi-directional LSPs Incompatibility
> >Date: Wed, 18 Jul 2001 18:23:39 -0400
> >
> > > Hi All,
> > >         There is some incompatibility in documents of OIF
> > > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
> > > related to bidirectional LSPs. OIF's O-UNI document says [docId
> > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> > > insert a RESV_CONFIRM object in the RESV message and should wait for
> > > ResvConf message before start transmitting data.
> > > But, the IETF document says the terminator node process path message
> > > as usual with the exception that the upstream label can immediately be
> > > used to transport data traffic associated with the LSP upstream towards
> > > the initiator.
> > >
> > > Please Help.
> > >
> > > Regards,
> > > manoj.
> >
> >I don't see a problem in this case.  Having the two ends more
> >constrained than the middle as to when a circuit can be considered in
> >service doesn't seem to present a problem.
> >
> >But my personal opinion is that the RESV Conf should be optional for
> >the UNI.
> >
> >...George
> >
> >==================================================================
> >George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Thu, 19 Jul 2001 04:09:42 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-li-shared-mesh-restoration-00.txt
Date: Thu, 19 Jul 2001 07:04:48 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RSVP-TE Extensions For Shared-Mesh Restoration in 
                          Transport Networks
	Author(s)	: G. Li et al.
	Filename	: draft-li-shared-mesh-restoration-00.txt
	Pages		: 17
	Date		: 18-Jul-01
	
Efficient techniques for rapid restoration must be addressed within 
GMPLS. This document describes extensions to GMPLS and RSVP-TE 
signaling in support of shared mesh restoration. Shared mesh 
restoration describes restoration plans in which restoration capacity 
is shared across multiple independent failures. In particular, this 
document proposes extensions enabling reservation of restoration 
capacity, LSP restoration, LSP reversion and LSP deletion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-li-shared-mesh-restoration-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-li-shared-mesh-restoration-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-li-shared-mesh-restoration-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-li-shared-mesh-restoration-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 18 Jul 2001 17:00:13 -0700
From: Abhimanyu Das <[email-masked]>
To: 'Giora Unger' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: GMPLS questions
Date: Wed, 18 Jul 2001 16:58:00 -0700

Hi,
   Just replying to your first question about forcing explicit lambdas,
along with explicit route for an LSP. Couldnt the Explicit Label Control
subobject (mentioned in the GMPLS signaling functional description,
draft-ietf-mpls-generalized-signaling-04.txt  sec 6), within the explicit
route object be used for this purpose. It seems to me that thats the reason
the explicit label control subobject was introduced.

Regards,
Abhimanyu

> 
> The questions:
> 
> 1. Given such an LSR, can we FORCE it to switch between a two specific
> lambdas ? Two mechanisms described in the document imply that 
> it's possible,
> but both are not clear-cut:
> 
> a. "Explicit Route" - in section 9.13. As far as I 
> understood, if we define
> the Explicit Route with a list of "strict Simple Abstract 
> Nodes", and in
> case that the "abstract node" concept can also express a 
> specific lambda, we
> can achieve the above.
> Am I correct ? How is the Label Restriction mechanism (below) 
> related to
> this mechanism ?
> 
> The main doubt was raised due the following line (in 9.13):
> "Note also that an explicit route is altered by intermediate 
> LSRs during its
> progression towards the destination."
> Does it mean we can't define an Explicit Route that would be 
> obeyed all
> along the -being-established path ?
> 
> b. "Label Restriction by the Upstream Node" - in section 9.8 
> it is implied
> that such a restriction is possible to a set of lambdas. Can 
> "set" be also
> interpreted as a single lambda to be forced ? 
> Additionally - in the last paragraph of section 9.8, it's written:
> "A Label Set may be present across multiple hops. In this 
> case each node
> generates its own outgoing Label Set, possibly based on the 
> incoming Label
> Set and the node's hardware capabilities."
> Hence, is it possible to force specific lambdas in all the 
> LSRs along the
> path, according to decisions that are not subject to 
> manipulations by the
> LSR along the way ?
> 
> 
> specification a "Time To
> Live" and a message to disconnect an LSP. However, we didn't 
> find such a
> mechanism in CR-LDP.
> Which mechanism should be employed in order to disconnect an 
> LSP in GMPLS ?
> 

> 
> -------------------------------------------
> Giora Unger
> Orika Optical Networks Ltd.
> www.orikanetworks.com
> Phone: +972-3-6091665 ext. 29
> Fax:     +972-3-6091667
> E-mail: [email-masked] 
> -------------------------------------------
> 
> 

Delivery-date: Wed, 18 Jul 2001 15:47:30 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Bi-directional LSPs Incompatibility
Date: Wed, 18 Jul 2001 15:46:38 -0700

Hi George,
            As long as both the documents are not aligned, we can say there 
is some incompatibility. I think one can argue it in both ways. Is it a 
incompatibility or a feature that GMPLS offers but UNI is unable to make use 
of it ?

Regards,
manoj.

>From: George Swallow <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: Bi-directional LSPs Incompatibility
>Date: Wed, 18 Jul 2001 18:23:39 -0400
>
> > Hi All,
> >         There is some incompatibility in documents of OIF
> > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
> > related to bidirectional LSPs. OIF's O-UNI document says [docId
> > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> > insert a RESV_CONFIRM object in the RESV message and should wait for
> > ResvConf message before start transmitting data.
> > But, the IETF document says the terminator node process path message
> > as usual with the exception that the upstream label can immediately be
> > used to transport data traffic associated with the LSP upstream towards
> > the initiator.
> >
> > Please Help.
> >
> > Regards,
> > manoj.
>
>I don't see a problem in this case.  Having the two ends more
>constrained than the middle as to when a circuit can be considered in
>service doesn't seem to present a problem.
>
>But my personal opinion is that the RESV Conf should be optional for
>the UNI.
>
>...George
>
>==================================================================
>George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Envelope-to: [email-masked]
Delivery-date: Wed, 18 Jul 2001 15:24:32 -0700
Message-Id: <[email-masked]>
To: "manoj juneja" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Bi-directional LSPs Incompatibility 
Date: Wed, 18 Jul 2001 18:23:39 -0400
From: George Swallow <[email-masked]>

> Hi All,
>         There is some incompatibility in documents of OIF
> (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
> related to bidirectional LSPs. OIF's O-UNI document says [docId
> oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> insert a RESV_CONFIRM object in the RESV message and should wait for
> ResvConf message before start transmitting data.
> But, the IETF document says the terminator node process path message
> as usual with the exception that the upstream label can immediately be
> used to transport data traffic associated with the LSP upstream towards
> the initiator.
> 
> Please Help.
> 
> Regards,
> manoj.

I don't see a problem in this case.  Having the two ends more
constrained than the middle as to when a circuit can be considered in
service doesn't seem to present a problem.  

But my personal opinion is that the RESV Conf should be optional for
the UNI.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Wed, 18 Jul 2001 15:09:28 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Difference in IETF and OIF Signal Type Values
Date: Wed, 18 Jul 2001 15:06:47 -0700

Hi All,
      There is some mismatch in signal type values supported in
OIF and IETF. As per Service discovery procedure of LMP, it supports
SDH signal types as VC-3, VC-3 via AU-3, VC-4 etc. It does not support
VC-11/VC-12/VC-2 etc. The OIF document support the LOVCs only by means
of hierarchical LSPs where the HOVCs are established as forwarding
adjacency (FA). But GMPLS ccamp-gmpls-sdh-sonet-01.txt draft
supports these LOVCs (VC-11/VC-12 etc) without even supporting
hierarchical LSPs.

Please Help.

Regards,
manoj.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 18 Jul 2001 15:07:49 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bi-directional LSPs Incompatibility
Date: Wed, 18 Jul 2001 15:02:54 -0700

Hi All,
        There is some incompatibility in documents of OIF
(oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
related to bidirectional LSPs. OIF's O-UNI document says [docId
oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
insert a RESV_CONFIRM object in the RESV message and should wait for
ResvConf message before start transmitting data.
But, the IETF document says the terminator node process path message
as usual with the exception that the upstream label can immediately be
used to transport data traffic associated with the LSP upstream towards
the initiator.

Please Help.

Regards,
manoj.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 17 Jul 2001 10:25:36 -0700
From: The IESG <[email-masked]>
To: AAA Working Group <[email-masked]>, ACAP Working Group <[email-masked]>, ADSLMIB Working Group <[email-masked]>, AFT Working Group <[email-masked]>, AGENTX Working Group <[email-masked]>, APEX Working Group <[email-masked]>, ATOMMIB Working Group <[email-masked]>, AVT Working Group <[email-masked]>, BEEP Working Group <[email-masked]>, BGMP Working Group <[email-masked]>, BMWG Working Group <[email-masked]>, BRIDGE Working Group <[email-masked]>, CALSCH Working Group <[email-masked]>, CAT Working Group <[email-masked]>, CCAMP Working Group <[email-masked]>, CNRP Working Group <[email-masked]>, DELTAV Working Group <[email-masked]>, DHC Working Group <[email-masked]>, DIFFSERV Working Group <[email-masked]>, DISMAN Working Group <[email-masked]>, DNSEXT Working Group <[email-masked]>, DNSOP Working Group <[email-masked]>, ECM Working Group <[email-masked]>, EDIINT Working Group <[email-masked]>, ENTMIB Working Group <[email-masked]>, ENUM Working Group <[email-masked]>, EOS Working Group <[email-masked]>, FAX Working Group <[email-masked]>, FRNETMIB Working Group <[email-masked]>, FTPEXT Working Group <[email-masked]>, GEOPRIV Working Group <[email-masked]>, GRIP Working Group <[email-masked]>, GSMP Working Group <[email-masked]>, HUBMIB Working Group <[email-masked]>, IDMR Working Group <[email-masked]>, IDN Working Group <[email-masked]>, IDR Working Group <[email-masked]>, IDWG Working Group <[email-masked]>, IFMIB Working Group <[email-masked]>, IMAPEXT Working Group <[email-masked]>, IMPP Working Group <[email-masked]>, IPCDN Working Group <[email-masked]>, IPFC Working Group <[email-masked]>, IPNGWG Working Group <[email-masked]>, IPO Working Group <[email-masked]>, IPORPR Working Group <[email-masked]>, IPP Working Group <[email-masked]>, IPPM Working Group <[email-masked]>, IPS Working Group <[email-masked]>, IPSEC Working Group <[email-masked]>, IPSP Working Group <[email-masked]>, IPSRA Working Group <[email-masked]>, IPTEL Working Group <[email-masked]>, ISIS Working Group <[email-masked]>, ISSLL Working Group <[email-masked]>, ITRACE Working Group <[email-masked]>, KINK Working Group <[email-masked]>, KRB-WG Working Group <[email-masked]>, L2TPEXT Working Group <[email-masked]>, LDAPBIS Working Group <[email-masked]>, LDAPEXT Working Group <[email-masked]>, LDUP Working Group <[email-masked]>, MALLOC Working Group <[email-masked]>, MANET Working Group <[email-masked]>, MBONED Working Group <[email-masked]>, MEGACO Working Group <[email-masked]>, MIDCOM Working Group <[email-masked]>, MMUSIC Working Group <[email-masked]>, MOBILEIP Working Group <[email-masked]>, MPLS Working Group <[email-masked]>, MSDP Working Group <[email-masked]>, MSEC Working Group <[email-masked]>, MSGTRK Working Group <[email-masked]>, MULTI6 Working Group <[email-masked]>, NASREQ Working Group <[email-masked]>, NAT Working Group <[email-masked]>, NFSV4 Working Group <[email-masked]>, NGTRANS Working Group <[email-masked]>, NNTPEXT Working Group <[email-masked]>, OPENPGP Working Group <[email-masked]>, OSPF Working Group <[email-masked]>, OTP Working Group <[email-masked]>, PILC Working Group <[email-masked]>, PIM Working Group <[email-masked]>, PKIX Working Group <[email-masked]>, POISSON Working Group <[email-masked]>, POLICY Working Group <[email-masked]>, PPPEXT Working Group <[email-masked]>, PPVPN Working Group <[email-masked]>, PROVREG Working Group <[email-masked]>, PWE3 Working Group <[email-masked]>, RAP Working Group <[email-masked]>, RESCAP Working Group <[email-masked]>, RIP Working Group <[email-masked]>, RMONMIB Working Group <[email-masked]>, RMT Working Group <[email-masked]>, ROHC Working Group <[email-masked]>, RSERPOOL Working Group <[email-masked]>, RUN Working Group <[email-masked]>, SACRED Working Group <[email-masked]>, SEAMOBY Working Group <[email-masked]>, SECSH Working Group <[email-masked]>, SIGTRAN Working Group <[email-masked]>, SIMPLE Working Group <[email-masked]>, SIP Working Group <[email-masked]>, SMIME Working Group <[email-masked]>, SMING Working Group <[email-masked]>, SNMPCONF Working Group <[email-masked]>, SNMPV3 Working Group <[email-masked]>, SPIRITS Working Group <[email-masked]>, SSM Working Group <[email-masked]>, STIME Working Group <[email-masked]>, SYSLOG Working Group <[email-masked]>, TEWG Working Group <[email-masked]>, TLS Working Group <[email-masked]>, TN3270E Working Group <[email-masked]>, TRADE Working Group <[email-masked]>, TSVWG Working Group <[email-masked]>, UDLR Working Group <[email-masked]>, URN Working Group <[email-masked]>, USEFOR Working Group <[email-masked]>, USWG Working Group <[email-masked]>, VPIM Working Group <[email-masked]>, VRRP Working Group <[email-masked]>, WEBDAV Working Group <[email-masked]>, WEBI Working Group <[email-masked]>, WTS Working Group <[email-masked]>, XMLDSIG Working Group <[email-masked]>, ZEROCONF Working Group <[email-masked]>
cc: [email-masked]
Subject: Note Well
Message-Id: <[email-masked]>
Date: Tue, 17 Jul 2001 10:24:22 -0700

Greetings,

This is the revised text of the NOTE WELL statement.

------------------------------------------------------

				NOTE WELL

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026, which
grants to the IETF and its participants certain licenses and rights in
such statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which
are addressed to:

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

Delivery-date: Tue, 17 Jul 2001 10:25:31 -0700
From: The IESG <[email-masked]>
To: AAA Working Group <[email-masked]>, ACAP Working Group <[email-masked]>, ADSLMIB Working Group <[email-masked]>, AFT Working Group <[email-masked]>, AGENTX Working Group <[email-masked]>, APEX Working Group <[email-masked]>, ATOMMIB Working Group <[email-masked]>, AVT Working Group <[email-masked]>, BEEP Working Group <[email-masked]>, BGMP Working Group <[email-masked]>, BMWG Working Group <[email-masked]>, BRIDGE Working Group <[email-masked]>, CALSCH Working Group <[email-masked]>, CAT Working Group <[email-masked]>, CCAMP Working Group <[email-masked]>, CNRP Working Group <[email-masked]>, DELTAV Working Group <[email-masked]>, DHC Working Group <[email-masked]>, DIFFSERV Working Group <[email-masked]>, DISMAN Working Group <[email-masked]>, DNSEXT Working Group <[email-masked]>, DNSOP Working Group <[email-masked]>, ECM Working Group <[email-masked]>, EDIINT Working Group <[email-masked]>, ENTMIB Working Group <[email-masked]>, ENUM Working Group <[email-masked]>, EOS Working Group <[email-masked]>, FAX Working Group <[email-masked]>, FRNETMIB Working Group <[email-masked]>, FTPEXT Working Group <[email-masked]>, GEOPRIV Working Group <[email-masked]>, GRIP Working Group <[email-masked]>, GSMP Working Group <[email-masked]>, HUBMIB Working Group <[email-masked]>, IDMR Working Group <[email-masked]>, IDN Working Group <[email-masked]>, IDR Working Group <[email-masked]>, IDWG Working Group <[email-masked]>, IFMIB Working Group <[email-masked]>, IMAPEXT Working Group <[email-masked]>, IMPP Working Group <[email-masked]>, IPCDN Working Group <[email-masked]>, IPFC Working Group <[email-masked]>, IPNGWG Working Group <[email-masked]>, IPO Working Group <[email-masked]>, IPORPR Working Group <[email-masked]>, IPP Working Group <[email-masked]>, IPPM Working Group <[email-masked]>, IPS Working Group <[email-masked]>, IPSEC Working Group <[email-masked]>, IPSP Working Group <[email-masked]>, IPSRA Working Group <[email-masked]>, IPTEL Working Group <[email-masked]>, ISIS Working Group <[email-masked]>, ISSLL Working Group <[email-masked]>, ITRACE Working Group <[email-masked]>, KINK Working Group <[email-masked]>, KRB-WG Working Group <[email-masked]>, L2TPEXT Working Group <[email-masked]>, LDAPBIS Working Group <[email-masked]>, LDAPEXT Working Group <[email-masked]>, LDUP Working Group <[email-masked]>, MALLOC Working Group <[email-masked]>, MANET Working Group <[email-masked]>, MBONED Working Group <[email-masked]>, MEGACO Working Group <[email-masked]>, MIDCOM Working Group <[email-masked]>, MMUSIC Working Group <[email-masked]>, MOBILEIP Working Group <[email-masked]>, MPLS Working Group <[email-masked]>, MSDP Working Group <[email-masked]>, MSEC Working Group <[email-masked]>, MSGTRK Working Group <[email-masked]>, MULTI6 Working Group <[email-masked]>, NASREQ Working Group <[email-masked]>, NAT Working Group <[email-masked]>, NFSV4 Working Group <[email-masked]>, NGTRANS Working Group <[email-masked]>, NNTPEXT Working Group <[email-masked]>, OPENPGP Working Group <[email-masked]>, OSPF Working Group <[email-masked]>, OTP Working Group <[email-masked]>, PILC Working Group <[email-masked]>, PIM Working Group <[email-masked]>, PKIX Working Group <[email-masked]>, POISSON Working Group <[email-masked]>, POLICY Working Group <[email-masked]>, PPPEXT Working Group <[email-masked]>, PPVPN Working Group <[email-masked]>, PROVREG Working Group <[email-masked]>, PWE3 Working Group <[email-masked]>, RAP Working Group <[email-masked]>, RESCAP Working Group <[email-masked]>, RIP Working Group <[email-masked]>, RMONMIB Working Group <[email-masked]>, RMT Working Group <[email-masked]>, ROHC Working Group <[email-masked]>, RSERPOOL Working Group <[email-masked]>, RUN Working Group <[email-masked]>, SACRED Working Group <[email-masked]>, SEAMOBY Working Group <[email-masked]>, SECSH Working Group <[email-masked]>, SIGTRAN Working Group <[email-masked]>, SIMPLE Working Group <[email-masked]>, SIP Working Group <[email-masked]>, SMIME Working Group <[email-masked]>, SMING Working Group <[email-masked]>, SNMPCONF Working Group <[email-masked]>, SNMPV3 Working Group <[email-masked]>, SPIRITS Working Group <[email-masked]>, SSM Working Group <[email-masked]>, STIME Working Group <[email-masked]>, SYSLOG Working Group <[email-masked]>, TEWG Working Group <[email-masked]>, TLS Working Group <[email-masked]>, TN3270E Working Group <[email-masked]>, TRADE Working Group <[email-masked]>, TSVWG Working Group <[email-masked]>, UDLR Working Group <[email-masked]>, URN Working Group <[email-masked]>, USEFOR Working Group <[email-masked]>, USWG Working Group <[email-masked]>, VPIM Working Group <[email-masked]>, VRRP Working Group <[email-masked]>, WEBDAV Working Group <[email-masked]>, WEBI Working Group <[email-masked]>, WTS Working Group <[email-masked]>, XMLDSIG Working Group <[email-masked]>, ZEROCONF Working Group <[email-masked]>
cc: [email-masked]
Subject: Note Well
Message-Id: <[email-masked]>
Date: Tue, 17 Jul 2001 10:24:43 -0700

Greetings,

This is the revised text of the NOTE WELL statement.

------------------------------------------------------

				NOTE WELL

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026, which
grants to the IETF and its participants certain licenses and rights in
such statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which
are addressed to:

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

Delivery-date: Tue, 17 Jul 2001 06:59:01 -0700
From: Jimmy Gendron <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: UNI Generalized label 
Date: Tue, 17 Jul 2001 09:56:04 -0400

Hi,

I have a question regarding the Generalized label. For example, if I have an
LSR with 2 OC-192c line cards connected with a SONET equipment and that the
ports between are mapped. If I want to connect to another LSR connected to
the same optical network with 2 OC-192c line cards, I use RSVP to do it. I
request a G-label, for continuous concatenation. When the connection is
created throught the optical network, do the ingress LSR receive a
G-label...? And does it need to use that label to send packets over that
interface or the interface is just set to up and running and advertised in a
routing protocol as a TE link?

Thank you very much,

Jimmy

Delivery-date: Tue, 17 Jul 2001 03:56:37 -0700
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-many-ical-ski-04.txt
Date: Tue, 17 Jul 2001 06:52:56 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SKiCal - an extension of iCalendar
	Author(s)	: G. FitzPatrick, P. Lannero, N. Hjelm
	Filename	: draft-many-ical-ski-04.txt
	Pages		: 76
	Date		: 16-Jul-01
	
This Memo defines the SKiCal format.
SKiCal is a machine-readable format for the interchange of enhanced
yellow-page directory listings.  SkiCal expands the traditional
property-set of name, address, telephone number and business
category,  adding structured information about people, places,
things, activities  and the conditions and terms for interaction with
resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-many-ical-ski-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-many-ical-ski-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-many-ical-ski-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-many-ical-ski-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-many-ical-ski-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 16 Jul 2001 10:48:09 -0700
Reply-To: <[email-masked]>
From: "Mohan Verma" <[email-masked]>
To: "'Giora Unger'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: GMPLS questions
Date: Mon, 16 Jul 2001 22:58:28 +1000

Hi unger,
      My comments are inline and are to my best--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Giora Unger
Sent: Tuesday, July 17, 2001 12:45 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: GMPLS questions

Hi everybody,

It's going to be a long one. Sorry, but I couldn't contain everything I
don't understand in a shorter message :-)

After reading the GMPLS architecture draft, there are still some issues
regarding GMPLS that I'd like to clarify.
I'll start with the background, such that you'll have better understanding
of my questions:
We're working in the domain of wavelength switching networks (LSC interfaces
in the GMPLS terminology).

Lets examine (briefly) such a network;
Multiple optical switches are distributed in the network. They are GMPLS
LSRs, which contain LSC interfaces, capable of switching between an incoming
lambda and an outgoing lambda.
Those LSRs can be manufactured by various vendors, and the only thing one
can be sure about them is the fact that they claim to support GMPLS.
We'd like to build a system in which a centralized entity decides which
switching operations are to be performed in each of those LSRs, and further
would see to it that those switching operations were actually executed.
We're well aware that GMPLS is distributed in nature, and that we're taking
it to the centralized direction. However, we'd like to verify that we're not
missing anything.

The questions:

1. Given such an LSR, can we FORCE it to switch between a two specific
lambdas ? Two mechanisms described in the document imply that it's possible,
but both are not clear-cut:

a. "Explicit Route" - in section 9.13. As far as I understood, if we define
the Explicit Route with a list of "strict Simple Abstract Nodes", and in
case that the "abstract node" concept can also express a specific lambda, we
can achieve the above.
Am I correct ? How is the Label Restriction mechanism (below) related to
this mechanism ?

The main doubt was raised due the following line (in 9.13):
"Note also that an explicit route is altered by intermediate LSRs during its
progression towards the destination."
Does it mean we can't define an Explicit Route that would be obeyed all
along the -being-established path ?

b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied
that such a restriction is possible to a set of lambdas. Can "set" be also
interpreted as a single lambda to be forced ?
Additionally - in the last paragraph of section 9.8, it's written:
"A Label Set may be present across multiple hops. In this case each node
generates its own outgoing Label Set, possibly based on the incoming Label
Set and the node's hardware capabilities."
Hence, is it possible to force specific lambdas in all the LSRs along the
path, according to decisions that are not subject to manipulations by the
LSR along the way ?

mohan>The two ways you mentioned will work.

2. Lets assume that our centralized entity decided to create a lightpath
between two Edge Nodes, A and B. Must the GMPLS messages actually creating
the LSP be sent from A along the actual path, or can that centralized entity
function as the sender ?
In other words - can the messages for actual LSP creation be sent not along
the physical path of the LSP ?

mohan>I suppose you can do with the help of out of band control channel but
one has
to make sure of the cross connect updations at each LSR.

3. We understood that there is no problem with having uni-directional LSPs
also in GMPLS wavelength switching environments. We'd like to verify we
didn't miss anything.

mohan>We also thought the same way...

4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To
Live" and a message to disconnect an LSP. However, we didn't find such a
mechanism in CR-LDP.
Which mechanism should be employed in order to disconnect an LSP in GMPLS ?

mohan>In CRLDP you can send either abort message in response awaited state
or Release
message in established state to tear down the tunnel, however the trigger
should
be from the manager.

5. Do you see any flaws in the general scheme I described above ? That is -
in utilizing GMPLS optical switches (LSRs) as relatively dumb entities which
practically obey the commands of a centralized entity.

mohan>I think we can talk of the same pros and cons of centralized vs
distributed..The
only claim of GMPLS is to provide automatic provision switching and traffic
engineering which needs better restoration and resilence properties..Hence
people prefer distributed..

Thanks a lot and sorry for the flood of questions ;-)

-------------------------------------------
Giora Unger
Orika Optical Networks Ltd.
www.orikanetworks.com
Phone: +972-3-6091665 ext. 29
Fax:     +972-3-6091667
E-mail: [email-masked]
-------------------------------------------

Delivery-date: Mon, 16 Jul 2001 10:43:32 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Giora Unger" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: GMPLS questions
Date: Mon, 16 Jul 2001 10:41:00 -0700

Hi Giora,

I'll take a first stab at clarifying some of your doubts. I am sure others
will expand on
what I say.

Please see some responses below.

Thanks,
-Vishal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Giora Unger
>Sent: Monday, July 16, 2001 7:45 AM
>To: [email-masked]'
>Cc: [email-masked]'
>Subject: GMPLS questions
>
>
>Hi everybody,
>
>It's going to be a long one. Sorry, but I couldn't contain everything I
>don't understand in a shorter message :-)
>
>After reading the GMPLS architecture draft, there are still some issues
>regarding GMPLS that I'd like to clarify.
>I'll start with the background, such that you'll have better understanding
>of my questions:
>We're working in the domain of wavelength switching networks (LSC
>interfaces
>in the GMPLS terminology).
>
>Lets examine (briefly) such a network;
>Multiple optical switches are distributed in the network. They are GMPLS
>LSRs, which contain LSC interfaces, capable of switching between
>an incoming
>lambda and an outgoing lambda.
>Those LSRs can be manufactured by various vendors, and the only thing one
>can be sure about them is the fact that they claim to support GMPLS.
>We'd like to build a system in which a centralized entity decides which
>switching operations are to be performed in each of those LSRs, and further
>would see to it that those switching operations were actually executed.
>We're well aware that GMPLS is distributed in nature, and that we're taking
>it to the centralized direction. However, we'd like to verify that
>we're not
>missing anything.
>
>The questions:
>
>1. Given such an LSR, can we FORCE it to switch between a two specific
>lambdas ? Two mechanisms described in the document imply that it's
>possible,
>but both are not clear-cut:
>
>a. "Explicit Route" - in section 9.13. As far as I understood, if we define
>the Explicit Route with a list of "strict Simple Abstract Nodes", and in
>case that the "abstract node" concept can also express a specific
>lambda, we
>can achieve the above.
>Am I correct ? How is the Label Restriction mechanism (below) related to
>this mechanism ?

The abstract node will be able to represent an individual lambda if
each lambda is explicitly identified as an "interface" in the routing
protocol. For example, with an IP address (which would be wasteful)
or using router ID and unnumbered links (possibly as described in draft
http://search.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-01.txt;
which would help to conserve IP addresses).

If you are using link bundling, however, it may be more difficult to
force the selection of a particular wavelength at each hop, since the
choice of which wavelength to use would be a local decision. Actually,
even in this case, perhaps the label set can be used to restrict
the choice of the wavelength at each hop in the following way.
The first node (or central entity) picks the desired wavelength
and encodes it into the label set (which would be a singleton in
this case). At each subsequent hop, when making a local wavelength
selection decision, the node would ensure that it honored the
restrictions in the label set. This would guarantee that each
node picked the same wavelength for the lightpath.

>The main doubt was raised due the following line (in 9.13):
>"Note also that an explicit route is altered by intermediate LSRs
>during its
>progression towards the destination."
>Does it mean we can't define an Explicit Route that would be obeyed all
>along the -being-established path ?

I am not entirely sure what the above sentence means. Perhaps it alludes
to the fact that the abstract nodes are deleted from the list in the
explicit route as the setup message progresses towards the destination.
Or it may refer to the fact that in some cases an abstract node may
have to be expanded (by the node preceding the abstract node or by the
first node in the abstract node) to determine the exact sequence of nodes
that
the message is to pass through.

In any case, however, if the exact sequence of LSRs that the lightpath
is to pass through is known to the central entity, then it should be
possible to define an explicit route that is obeyed all along the
being-established path (in the sense that the message will pass through
the exact sequence of nodes specified; whether it will use the same
wavelength
at each hop may be determined either with the label set or bundling
considerations).

>b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied
>that such a restriction is possible to a set of lambdas. Can "set" be also
>interpreted as a single lambda to be forced ?

Yes, the "set" may contain a single element.

>Additionally - in the last paragraph of section 9.8, it's written:
>"A Label Set may be present across multiple hops. In this case each node
>generates its own outgoing Label Set, possibly based on the incoming Label
>Set and the node's hardware capabilities."
>Hence, is it possible to force specific lambdas in all the LSRs along the
>path, according to decisions that are not subject to manipulations by the
>LSR along the way ?

If the LSRs in question have no wavelength conversion capabilities then
simply selecting the desired wavelength and putting it in the label set
at the starting LSR will force the selection of the same wavelength
at all hops along the path (or the rejection of the lightpath, if
that wavelength is unavailable).

If, however, the intermediate nodes are
capable of wavlength conversion, then it is possible that a wavelength
conversion capable intermediate node may select a different outgoing
wavelength if the desired wavelength is unavailable but a different
one is available, and possibily drop the label set completely or
leave it unchanged, or change it to the outgoing wavelength
that it selected (depending on the implementation).
I am not sure off hand how one would force the choice of a specific
wavelength in that case.

>
>2. Lets assume that our centralized entity decided to create a lightpath
>between two Edge Nodes, A and B. Must the GMPLS messages actually creating
>the LSP be sent from A along the actual path, or can that
>centralized entity
>function as the sender ?
>In other words - can the messages for actual LSP creation be sent not along
>the physical path of the LSP ?

Not sure what you mean here. Do you mean you still want to use
RSVP-TE or CR-LDP for path setup, but you want the messages to
emanate from the central entity as opposed to the head end LSR?
If so, you could, technically, simply embed the specific protocol
messages into whatever protocol the central entity uses to "talk"
to each LSR along the lightpath, and let the LSR interpret
those protocol messages as it would if they had been received on
an interface connected to an upstream LSR along that lightpath.

Another option would be for the central entity to issue a "setup"
command to the head end LSR, together with the explicit route (and
wavelength chosen), and let the head end initiate the ligthpath setup.

>3. We understood that there is no problem with having uni-directional LSPs
>also in GMPLS wavelength switching environments. We'd like to verify we
>didn't miss anything.

Don't think unidirectional lightpaths should be a problem.

>4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To
>Live" and a message to disconnect an LSP. However, we didn't find such a
>mechanism in CR-LDP.
>Which mechanism should be employed in order to disconnect an LSP in GMPLS ?
>5. Do you see any flaws in the general scheme I described above ? That is -
>in utilizing GMPLS optical switches (LSRs) as relatively dumb
>entities which
>practically obey the commands of a centralized entity.

Not really, except that the GMPLS switches wouldn't be operating in
a truly distributed way, so that you may not derive some of the benefits
that come from doing that. Also, you'd have to worry about the reliability
of the central entity and of its communication path to the individual
LSRs in your network.

Delivery-date: Mon, 16 Jul 2001 06:45:42 -0700
From: Giora Unger <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: GMPLS questions
Date: Mon, 16 Jul 2001 16:45:21 +0200

Hi everybody,

It's going to be a long one. Sorry, but I couldn't contain everything I
don't understand in a shorter message :-)

After reading the GMPLS architecture draft, there are still some issues
regarding GMPLS that I'd like to clarify.
I'll start with the background, such that you'll have better understanding
of my questions:
We're working in the domain of wavelength switching networks (LSC interfaces
in the GMPLS terminology). 

Lets examine (briefly) such a network; 
Multiple optical switches are distributed in the network. They are GMPLS
LSRs, which contain LSC interfaces, capable of switching between an incoming
lambda and an outgoing lambda.
Those LSRs can be manufactured by various vendors, and the only thing one
can be sure about them is the fact that they claim to support GMPLS.
We'd like to build a system in which a centralized entity decides which
switching operations are to be performed in each of those LSRs, and further
would see to it that those switching operations were actually executed.
We're well aware that GMPLS is distributed in nature, and that we're taking
it to the centralized direction. However, we'd like to verify that we're not
missing anything.

The questions:

1. Given such an LSR, can we FORCE it to switch between a two specific
lambdas ? Two mechanisms described in the document imply that it's possible,
but both are not clear-cut:

a. "Explicit Route" - in section 9.13. As far as I understood, if we define
the Explicit Route with a list of "strict Simple Abstract Nodes", and in
case that the "abstract node" concept can also express a specific lambda, we
can achieve the above.
Am I correct ? How is the Label Restriction mechanism (below) related to
this mechanism ?

The main doubt was raised due the following line (in 9.13):
"Note also that an explicit route is altered by intermediate LSRs during its
progression towards the destination."
Does it mean we can't define an Explicit Route that would be obeyed all
along the -being-established path ?

b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied
that such a restriction is possible to a set of lambdas. Can "set" be also
interpreted as a single lambda to be forced ? 
Additionally - in the last paragraph of section 9.8, it's written:
"A Label Set may be present across multiple hops. In this case each node
generates its own outgoing Label Set, possibly based on the incoming Label
Set and the node's hardware capabilities."
Hence, is it possible to force specific lambdas in all the LSRs along the
path, according to decisions that are not subject to manipulations by the
LSR along the way ?

2. Lets assume that our centralized entity decided to create a lightpath
between two Edge Nodes, A and B. Must the GMPLS messages actually creating
the LSP be sent from A along the actual path, or can that centralized entity
function as the sender ?
In other words - can the messages for actual LSP creation be sent not along
the physical path of the LSP ?

3. We understood that there is no problem with having uni-directional LSPs
also in GMPLS wavelength switching environments. We'd like to verify we
didn't miss anything.

4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To
Live" and a message to disconnect an LSP. However, we didn't find such a
mechanism in CR-LDP.
Which mechanism should be employed in order to disconnect an LSP in GMPLS ?

5. Do you see any flaws in the general scheme I described above ? That is -
in utilizing GMPLS optical switches (LSRs) as relatively dumb entities which
practically obey the commands of a centralized entity.

Thanks a lot and sorry for the flood of questions ;-)

-------------------------------------------
Giora Unger
Orika Optical Networks Ltd.
www.orikanetworks.com
Phone: +972-3-6091665 ext. 29
Fax:     +972-3-6091667
E-mail: [email-masked] 
-------------------------------------------

Delivery-date: Mon, 16 Jul 2001 04:04:48 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-shared-fastreroute-00.txt
Date: Mon, 16 Jul 2001 06:59:43 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MPLS Signaling Extensions for Shared Fast Rerouting
	Author(s)	: A. Iwata
	Filename	: draft-iwata-mpls-shared-fastreroute-00.txt
	Pages		: 17
	Date		: 13-Jul-01
	
This document proposes an enhanced scheme for fast rerouting which
provides means of quickly repairing LSPs in cases of link/node
failures. It also provides for the sharing of backup LSPs and their
resources and thus allows minimization of requirements for backup
resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-iwata-mpls-shared-fastreroute-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-shared-fastreroute-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 13 Jul 2001 07:16:09 -0700
From: "Torsten Mueller" <[email-masked]>
To: [email-masked]
Date: Fri, 13 Jul 2001 16:12:12 +0200
Subject: splicing in draft-ietf-ccamp-gmpls-architecture-00.txt

Hallo,

draft-ietf-ccamp-gmpls-architecture-00.txt mentions in
   9.13 Explicit Routing and Explicit Label Control

  In particular, the explicit label control in the explicit route
   allows terminating an LSP on a particular outgoing port to an egress
   node.

   This can also be used when it is desirable to "splice" two LSPs
   together, i.e. where the tail of the first LSP would be "spliced"
   into the head of the second LSP.

Does this mean, that it is possible to splice different types of LSP into
each other?
E.g., could I terminate a PSC LSP, then use a SDH LSP and finally, again,
a PSC LSP
instead of using the hierarchical approach?
If not, what is the intent of "splicing"?

Thanks,
Torsten

Delivery-date: Thu, 12 Jul 2001 12:07:04 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bi-directional LSPs Incompatibility
Date: Thu, 12 Jul 2001 12:05:17 -0700

Hi All,
        There is some incompatibility in documents of OIF(oif2000.125.5) and 
IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
related to bidirectional LSPs. OIF's O-UNI document says [docId
oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must insert a
RESV_CONFIRM object in the RESV message and should wait for ResvConf
message before start transmitting data.
But, the IETF document says the terminator node process path message as
usual with the exception that the upstream label can immediately be
used to transport data traffic associated with the LSP upstream towards
the initiator.

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 11 Jul 2001 23:05:45 -0700
Reply-To: <[email-masked]>
From: "Srikanth" <[email-masked]>
To: <[email-masked]>
Subject: Associating an Entity with a non-PSC interface
Date: Thu, 12 Jul 2001 11:13:48 +0530

Hi All,

In the case of Generalized Cr-Ldp running between two routers, connected by
a non-PSC interface, LDP session should be present between the two for
establishment of tunnels. However, draft-ietf-mpls-ldp-mib-07.txt mentions
only PSC Parameters. Then, how do we associate an Entity with a non-PSC
Interface?

Thanks in advance,
Srikanth Narayanan.

Delivery-date: Wed, 11 Jul 2001 14:45:08 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Difference in IETF and OIF Signal Type Values
Date: Wed, 11 Jul 2001 14:42:11 -0700

Hi All,
        There is some mismatch in signal type values supported in OIF
and IETF. As per Service discovery procedure of LMP, it supports SDH
signal types as VC-3, VC-3 via AU-3, VC-4 etc. It does not support VC-
11/VC-12/VC-2 etc. But GMPLS ccamp-gmpls-sdh-sonet-01.txt draft
supports these LOVCs (VC-11/VC-12 etc).

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 10 Jul 2001 08:38:24 -0700
Cc: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Tue, 10 Jul 2001 17:36:50 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Malcolm Betts <[email-masked]>
Original-CC: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: arbitrary contiguous concatenation question

This is a multi-part message in MIME format.
--------------529A60BC86E4E9B37CA97F7E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Malcolm,

I agree with you, and that's why I wrote the email. I hadn't noticed this issue
of "STS-1 concatenation" until this morning unfortunately. As the
draft-ietf-ccamp-gmpls-sonet-sdh-01.txt document isn't approved yet, it isn't
too late to correct...

Some background for you. IETF is defining signalling support for concatenated
STS/VC signals, which are not defined in T1.105 or G.707. One of those is
"arbitrary contiguous concatenation" of STS-1 signals: STS-Xc, with X > 1 (e.g.
2,3,4,5,6,7,8,...). Refer to appendix 3 of
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt

Some background for other readers. In G.707 AU-3 concatenation has never been
defined, only AU-4 concatenation (G.707 1996 AU-4-2c, AU-4-3c, etc). In T1.105
1995 STS concatenation has been defined for STS-Nc with N restricted to
3,6,9,12,15,etc, but not for any other value of N. Essentially this is equal to
AU-4 concatenation.
Both G.707 and T1.105 have restricted this concatenation in their 2000 versions
to AU-4-4c/STS-12c, AU-4-16c/STS-48c, etc.

Arbitrary contiguous concatenation of STS-1 signals (STS-Xc, X>1) hasn't been
defined up to so far in any transport plane standard. And if we would define it
as true "contiguous" concatenation then an STS-Xc would use STS-1/AU-3 timeslots
TSi, TSi+1, .., TSi+X.

This would imply that the STS-1-3c and the STS-3c are not transported via the
same timeslots. Same for STS-1-6c and STS-3c-2c, etc.

The text in appendix 3 of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt should in this
case not mix AU-4 with STS-1. AU-4-Xc and STS-3c-Xc are equivalent. STS-1-Xc and
AU-3-Xc are equivalent. STS-1-(3X)c and STS-3c-Xc are NOT equivalent.

	Note that the STS SPEs associated with STS-1-(3X)c and STS-3c-Xc
	are the same. Those are simply STS-(3X)c SPE signals.

As I wasn't involved from the start in this work, I do not know what the
supporters of arbitrary contiguous concatenation of STS-1 signals intended to
define. I am looking forward to more input from those.

Regards,

Maarten

> Malcolm Betts wrote:
> 
> Maarten, the term "contiguous" may be confusing when applied in the context of
> the two stage multiplexing of AU-3's into an AUG (to occupy the same "space"
> as a AU-4) then into a STM-N (with N>1).  The  three STS-1 (AU-3) pointers for
> an STS-3c (VC-4) payload are adjacent (contiguous) within the OC-3N (STM-N)
> frame.  For AU-4N (or STS-3N) and above concatenation, the pointers and
> payloads are contiguous (adjacent) within the STM-N frame.
> 
> This is well know and has been in existence since about 1988 - the vintage of
> the first versions of the SONET standard T1.105 and the original SDH standards
> G.707, G.708 and G.709 - with numerous examples of interworking between SONET
> and SDH and between vendors.
> 
> Malcolm Betts
> 
> Advanced Network Technology
> Nortel Networks
> Phone: +1 613 763 7860 (ESN 393)
> FAX:   +1 613 763 6608 (ESN 393)
> email: [email-masked]
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 5:14 AM
> To: ccamp
> Cc: t1x1.5; q11/15
> Subject: arbitrary contiguous concatenation question
> 
> All,
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling support for
> arbitrary
> contiguous concatenation in appendix 3. Looking a bit more into this arbitrary
> 
> concatenation from the transport plane, I came across a question with respect
> to
> the definition of "contiguous STS-1/AU-3 timeslots". Let me introduce this
> question:
> 
> Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within an STM-4) as
> follows
> 
>      Time          111
>      Slot 123456789012123456789
> 
>         B 123412341234123412341...
>         A 111122223333111122223...
> 
> AU-3 timeslots have a TimeSlot number and a (B,A) number, with TS1 associated
> with (1,1) and TS12 associated with (4,3).
> 
>         Note - the figure in the pre-published version of G.707
>         doesn't show the timeslot numbering in a correct manner.
> 
> and the AU-4 numbering is as follows (figure 7-24/G.707)
> 
>      Time
>      Slot 123412341234123412341
> 
>         B 123412341234123412341...
>         A 000000000000000000000...
> 
> An AU-4 [STS-3c] is as such essentially a "non-contiguous" concatenation of
> AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4 (2,0) uses AU-3
> timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)].
> 
> If we define STS-1 contiguous concatenation, which timeslots are then used for
> 
> e.g. a STS-1-3c:
>         i)  timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or
>         ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9]
> 
> Similarly, for the case of a STS-1-6c do we use:
>         i)  (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2)
> [TS1,TS2,TS3,TS4,TS5,TS6] or
>         ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3)
> [TS1,TS2,TS5,TS6,TS9,TS10]
> 
> And which timeslots do we use for e.g. a STS-1-5c?
> 
> If this detail is not specified, interworking is not possible unless we
> include
> the list of timeslots as we do with virtual concatenation (and as discussed
> for
> flexible arbitrary concatenation).
> 
> Regards,
> 
> Maarten
--------------529A60BC86E4E9B37CA97F7E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------529A60BC86E4E9B37CA97F7E--

Delivery-date: Tue, 10 Jul 2001 04:23:08 -0700
From: "Tissa Senevirathne" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Could you comment on ID draft-tsenevir-bgp-l2vpn-00.txt
Date: Tue, 10 Jul 2001 11:21:12 

http://search.ietf.org/internet-drafts/draft-tsenevir-bgp-l2vpn-00.txt

The above draft present  BGP-MP based approach in providing Layer 2 VPN 
services. The work presented here extends the 2547bis to provide both Layer 
2VPN and Layer 3 VPN. Hence allowing providers to provision both Layer 2 and 
Layer 3VPN services using a single control protocol.

I appreciate if you could review and provide comments and feedback

Thanks

Tissa
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 10 Jul 2001 02:15:57 -0700
Cc: "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Tue, 10 Jul 2001 11:13:55 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Original-CC: "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: arbitrary contiguous concatenation question

This is a multi-part message in MIME format.
--------------D14641125D0EB5C8CF91DA1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling support for arbitrary
contiguous concatenation in appendix 3. Looking a bit more into this arbitrary
concatenation from the transport plane, I came across a question with respect to
the definition of "contiguous STS-1/AU-3 timeslots". Let me introduce this
question:

Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within an STM-4) as
follows

     Time          111
     Slot 123456789012123456789

	B 123412341234123412341...
	A 111122223333111122223...

AU-3 timeslots have a TimeSlot number and a (B,A) number, with TS1 associated
with (1,1) and TS12 associated with (4,3).

	Note - the figure in the pre-published version of G.707
	doesn't show the timeslot numbering in a correct manner.

and the AU-4 numbering is as follows (figure 7-24/G.707)

     Time
     Slot 123412341234123412341

	B 123412341234123412341...
	A 000000000000000000000...

An AU-4 [STS-3c] is as such essentially a "non-contiguous" concatenation of
AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4 (2,0) uses AU-3
timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)].

If we define STS-1 contiguous concatenation, which timeslots are then used for
e.g. a STS-1-3c:
	i)  timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or
	ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9]

Similarly, for the case of a STS-1-6c do we use:
	i)  (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2) [TS1,TS2,TS3,TS4,TS5,TS6] or
	ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3) [TS1,TS2,TS5,TS6,TS9,TS10]

And which timeslots do we use for e.g. a STS-1-5c?

If this detail is not specified, interworking is not possible unless we include
the list of timeslots as we do with virtual concatenation (and as discussed for
flexible arbitrary concatenation).

Regards,

Maarten
--------------D14641125D0EB5C8CF91DA1B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D14641125D0EB5C8CF91DA1B--

Envelope-to: [email-masked]
Delivery-date: Mon, 09 Jul 2001 23:43:15 -0700
Date: Mon, 9 Jul 2001 23:40:13 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-mpls-lmp-02.txt
Cc: [email-masked]

> there are two LMP drafts (both -02) at ietf.org website:
>   1. URL below (in Kireeti's email);

I screwed up.  draft-ietf-mpls-lmp-02.txt is the correct one.

Kireeti.

Delivery-date: Mon, 09 Jul 2001 14:35:36 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt
Date: Mon, 09 Jul 2001 14:32:34 -0700

Hi Marteen,
             You mean to say that hierarchical LSPs can be established
in 1st and 2nd case. Are these cases need to be pre-configured at the
time STM-N link is configured (i.e. the LOVC link ends at a fabric at
both sides etc.) ?
Also, in the following example u explained the allocation of VC-11 in
VC-11 link connection (3,1). How in signalling how do u specify that I
want VC-11 from (3,1) VC-11 link connection ?

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt
>Date: Mon, 09 Jul 2001 11:02:00 +0200
>
>Manoj,
>
>manoj juneja wrote:
> >
> > Hi All,
> >
> >         In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical
> > sonet/sdh LSPs has been described. It mentions that the higher order
> > sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC
> > -3). A lower order SDH/SONET LSP can be established through that higher
> > LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all
> > labels allocated between two ends of that LSP will have S, U and K set
> > to ZERO i.e. non-significant while L and M will be used to indicate the
> > signal allocated in that VC-3.
>
>In my opinion in all cases LOVC/VT connections will have S and U (and when
>transported in a VC-3/STS-1 also K) set to zero. This implies that examples 
>2 to
>5 in section 3 of the document present non-existing cases. Also example 1 
>is not
>correct. Are we misleading the reader here?
>
> > Please clarify how the higher order LSP will be established ?
>
>For a HO-VC-3 link connection the following values are applicable (case of 
>e.g.
>VC-3 (4,1) in a STM-4):
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  ST=5         |      RCC=0    |              NCC=0            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              NVC=0            |        Multiplier (MT)=0      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Transparency (T)=0                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               S=4             |   U=1 |   K=0 |   L=0 |   M=0 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>The above only results in the allocation of VC-3 link conneciton number 
>(4,1) in
>e.g. a STM-4 to a VC-3 connection. There might be many more VC-3 link
>connections and VC-3 matrix connections present in the total VC-3 path 
>between
>the VC-3 path termination functions.
>
>
>
> > Once the higher order LSP gets established, the lower order signals
> > within higher order signals will also gets allocated.
>
>Once two VC-3 path terminations are interconnected via a series of VC-3 
>matrix
>connections and VC-3 link connections, there is a LOVC link established. 
>The
>provisioning of the TU pointer processors at both VC-3 path termination
>endpoints determines now the LOVC link's substructure (i.e. TU-11, TU-12, 
>TU-2
>structure).
>
>Three cases:
>1) the LOVC link ends at a fabric at both sides:
>	Now there are no LOVC signals going over any of the LOVC
>	link connections in the LOVC link.
>
>2) the LOVC link ends at VC-11/12/2 termination functions at one side and a
>fabric at the other side:
>	Now LOVC signals are generated at one side and inserted into
>	the LOVC link connections in the LOVC link. At the other end
>	these signals end up at the ingress of a Fabric, where the transport
>	stops until the moment the matrix connections are provisioned
>	in the fabric. In the other direction, the fabric generates LOVC UNEQ
>	signals, which will cause LOVC-UNEQ alarms to be raised (unless
>	alarm reporting is disabled).
>
>3) the LOVC link ends at VC-11/12/2 termination functions at both sides:
>	Now LOVC signals are generated at both sides and inserted into
>	the LOVC link connections in the LOVC link. The creation of the
>	VC-3 path also has created the set of LOVC paths. Assumption is
>	that both endpoints have the same set of LOVC path termination
>	points; otherwise there will be TU-LOP alarms.
>
>
> > Then how can I again allocate the lower order signals ?
>
>This is only important in cases 1 and 2. Here you have no lower order 
>signals
>flowing, you have only LOVC link connections created which are waiting for 
>a
>LOVC signal to be transported over it.
>
>Assume you want to transport a VC-11 over VC-11 link connection number 
>(3,1),
>then you will see the following request
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  ST=1         |      RCC=0    |              NCC=0            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              NVC=0            |        Multiplier (MT)=0      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Transparency (T)=0                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               S=0             |   U=0 |   K=0 |   L=4 |   M=7 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>Regards,
>
>Maarten
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 09 Jul 2001 07:26:00 -0700
Date: Mon, 09 Jul 2001 10:27:15 -0400
From: Guangzhi Li <[email-masked]>
To: Vijay Gill <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Agenda Request: IETF Meeting for CCAMP

Hi, Vijay:

Please reserve me 10 ~15 min slot on the agenda for the London IETF
meeting. We will submit a new I-D with title "RSVP-TE extensions for
shared mesh restoration in transport networks".

Thanks,

Guangzhi

Vijay Gill wrote:

> Folks
>
> Are there any items people would like to put on the
> agenda for the London IETF meeting?
>
> Please send requests to Kireeti and myself.
>
> [email-masked]
> [email-masked]
>
> thanks
>
> your co-chairs
>
> kireeti and vijay

Delivery-date: Mon, 09 Jul 2001 02:05:55 -0700
Cc: [email-masked]
Date: Mon, 09 Jul 2001 11:02:00 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt

This is a multi-part message in MIME format.
--------------96536CF1E01F07425C8CBB94
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

manoj juneja wrote:
> 
> Hi All,
> 
>         In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical
> sonet/sdh LSPs has been described. It mentions that the higher order
> sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC
> -3). A lower order SDH/SONET LSP can be established through that higher
> LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all
> labels allocated between two ends of that LSP will have S, U and K set
> to ZERO i.e. non-significant while L and M will be used to indicate the
> signal allocated in that VC-3.

In my opinion in all cases LOVC/VT connections will have S and U (and when
transported in a VC-3/STS-1 also K) set to zero. This implies that examples 2 to
5 in section 3 of the document present non-existing cases. Also example 1 is not
correct. Are we misleading the reader here?

> Please clarify how the higher order LSP will be established ? 

For a HO-VC-3 link connection the following values are applicable (case of e.g.
VC-3 (4,1) in a STM-4):
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  ST=5         |      RCC=0    |              NCC=0            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              NVC=0            |        Multiplier (MT)=0      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Transparency (T)=0                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               S=4             |   U=1 |   K=0 |   L=0 |   M=0 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

The above only results in the allocation of VC-3 link conneciton number (4,1) in
e.g. a STM-4 to a VC-3 connection. There might be many more VC-3 link
connections and VC-3 matrix connections present in the total VC-3 path between
the VC-3 path termination functions.

> Once the higher order LSP gets established, the lower order signals 
> within higher order signals will also gets allocated. 

Once two VC-3 path terminations are interconnected via a series of VC-3 matrix
connections and VC-3 link connections, there is a LOVC link established. The
provisioning of the TU pointer processors at both VC-3 path termination
endpoints determines now the LOVC link's substructure (i.e. TU-11, TU-12, TU-2
structure).

Three cases: 
1) the LOVC link ends at a fabric at both sides:
	Now there are no LOVC signals going over any of the LOVC
	link connections in the LOVC link.

2) the LOVC link ends at VC-11/12/2 termination functions at one side and a
fabric at the other side:
	Now LOVC signals are generated at one side and inserted into
	the LOVC link connections in the LOVC link. At the other end
	these signals end up at the ingress of a Fabric, where the transport
	stops until the moment the matrix connections are provisioned
	in the fabric. In the other direction, the fabric generates LOVC UNEQ
	signals, which will cause LOVC-UNEQ alarms to be raised (unless
	alarm reporting is disabled).

3) the LOVC link ends at VC-11/12/2 termination functions at both sides:
	Now LOVC signals are generated at both sides and inserted into
	the LOVC link connections in the LOVC link. The creation of the 
	VC-3 path also has created the set of LOVC paths. Assumption is
	that both endpoints have the same set of LOVC path termination
	points; otherwise there will be TU-LOP alarms.

> Then how can I again allocate the lower order signals ?

This is only important in cases 1 and 2. Here you have no lower order signals
flowing, you have only LOVC link connections created which are waiting for a
LOVC signal to be transported over it.

Assume you want to transport a VC-11 over VC-11 link connection number (3,1),
then you will see the following request
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  ST=1         |      RCC=0    |              NCC=0            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              NVC=0            |        Multiplier (MT)=0      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Transparency (T)=0                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               S=0             |   U=0 |   K=0 |   L=4 |   M=7 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Regards,

Maarten
--------------96536CF1E01F07425C8CBB94
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------96536CF1E01F07425C8CBB94--

Delivery-date: Fri, 06 Jul 2001 22:40:48 -0700
Date: Fri, 06 Jul 2001 22:43:40 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: mpls-list <[email-masked]>, ccamp-list <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, Kireeti Kompella <[email-masked]>, George Swallow <[email-masked]>, Dimitrios Pendarakis <[email-masked]>, Fong Liaw <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-00.txt]

This is a multi-part message in MIME format.
--------------C3A36C92E1B580CFF12E760F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Here is a draft on minimizing the negative effects on MPLS traffic
caused by LSR's control plane restart. We think this is a valuable
feature for the LSR's. Look forward to hear from you.

Thanks!

- Ping
--------------C3A36C92E1B580CFF12E760F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

To: IETF-Announce: ;;:;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-pan-rsvp-te-restart-00.txt
Date: Fri, 06 Jul 2001 06:51:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Graceful Restart Mechanism for RSVP-TE
	Author(s)	: P. Pan et al.
	Filename	: draft-pan-rsvp-te-restart-00.txt
	Pages		: 
	Date		: 05-Jul-01
	
This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by LSR's control plane
restart, and specifically by the restart of its RSVP-TE component, on
LSRs that are capable of preserving the MPLS forwarding component
across the restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-rsvp-te-restart-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pan-rsvp-te-restart-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pan-rsvp-te-restart-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--------------C3A36C92E1B580CFF12E760F--

Delivery-date: Fri, 06 Jul 2001 15:26:10 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Doubt in ccamp-gmpls-sdh-sonet-01.txt
Date: Fri, 06 Jul 2001 15:24:16 -0700

Hi All,

        In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical
sonet/sdh LSPs has been described. It mentions that the higher order
sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC
-3). A lower order SDH/SONET LSP can be established through that higher
LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all
labels allocated between two ends of that LSP will have S, U and K set
to ZERO i.e. non-significant while L and M will be used to indicate the
signal allocated in that VC-3.
Please clarify how the higher order LSP will be established ? Once the
higher order LSP gets established, the lower order signals within
higher order signals will also gets allocated. Then how can I again
allocate the lower order signals ?

Is this the reason for having bandwidth encdoing parameter in GMPLS
signalling (i.e. establishment of hierarchical SDH/SONET LSPs) ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 06 Jul 2001 07:51:23 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt
Date: Tue, 26 Jun 2001 07:02:32 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: New TE LSAs to extend OSPF for Traffic Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-00.txt
	Pages		: 36
	Date		: 25-Jun-01
	
OSPF is a well established link state routing protocol used for 
topology discovery and computing forwarding table based on
shortest-Path criteria. Traffic Engineering extensions (OSPF-TE)
will use criteria different from shortest-path so as to route
traffic around congestion paths and meet varying Service Level
agreements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-srisuresh-ospf-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-srisuresh-ospf-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Delivery-date: Fri, 06 Jul 2001 07:51:20 -0700
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt
Date: Fri, 06 Jul 2001 06:50:43 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Routing Extensions for MPLS Signaling
	Author(s)	: A. Iwata, N. Fujita, G. Ash, A. Farrel
	Filename	: draft-iwata-mpls-crankback-01.txt
	Pages		: 30
	Date		: 05-Jul-01
	
This draft proposes crankback routing extensions for CR-LDP signaling
and for RSVP-TE signaling. Recently, several routing protocol
extensions for advertising resource information in addition to
topology information have been proposed for use in distributed
constraint-based routing. In such a distributed routing environment,
however, the information used to compute a constraint-based path may
be out of date. This means that LSP setup requests may be blocked by
links or nodes without sufficient resources. This draft specifies
crankback routing extensions for CR-LDP and RSVP-TE so that the label
request can be retried on an alternate path that detours around the
blocked link or node upon a setup failure. Furthermore, the crankback
routing schemes can also be applied to LSP restoration by indicating
the location of the failure link or node. This would significantly
improve the successful recovery ratio for failed LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-iwata-mpls-crankback-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-d

Delivery-date: Fri, 06 Jul 2001 05:36:46 -0700
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 06 Jul 2001 14:35:44 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Diego Caviglia <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Span Definition

This is a multi-part message in MIME format.
--------------E947154F1FB56A66677FE7EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Diego,

An OCh signal represents a single optical signal. It is as such not equivalent
to your optical link, which is multi-channel (i.e. multi-signal).
                          OCh_1                                     OCh_6
 |------------------------------------------------------------||---------------
     OCh_5                                    OCh_2
 ------------------||---------------------------------------------------------|
        OCh_4                        OCh_3
 ------------------||-----------------------------------------|
        OMSn_a                OMSn_b                OMSn_c          OMSn_d
 |-----------------||--------------------||-------------------||--------------|
 OTSn_A OTSn_B OTSn_C OTSn_D     OTSn_E   OTSn_F OTSn_G OTSn_H  OTSn_I  OTSn_J
 |-----||----||----||-------||-----------||-----||-----||-----||------||------|

n OCh signals are transported via one OMSn signal. One OMSn signal is
transported via one OTSn signal. At the endpoint of an OMSn, all n OCh signals
are accessible, and may be connected to another OMSn or terminated (3R
regeneration). Note that the termination of OCh signals doesn't have to be
performed at the same points in the network as shown in the figure above.
Nevertheless, in today's core network it is typical that all OCh signals are
terminated at the end of an OMSn section; but in the all-optical network of
tomorrow this will not longer be the case.

OMSn_a and OMSn_b (etc.) may have different values of n; e.g. OMS80_a and
OMS32_b.

Up to so far. Allow me to ask a question about the benefits for our telecom
industry of introducing a second set of terms to describe the optical transport
network. Wouldn't it be more efficient when we just use a single set of terms?

Regards,

Maarten

Diego Caviglia wrote:
> 
> Hi Marteen ,
>                 you're right, thank you for your clarification.
> Thus accordingly to your mail the Optical Link definition become:
> 
>  Optical   Link   "An   Optical  Link  consist  of  a number of channels between
> two adjacent 3R regeneration sites"
> An Optical Link is what in ITU-T is called Och
> 
> Regards.
> 
> Diego.
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modeling
> E-mail: [email-masked]
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
> 
> Maarten Vissers <[email-masked]> on 06/07/2001 10.55.51
> 
> 
> 
> 
> 
> 
> 
>  To:      Diego Caviglia/MAIN/MC1@MCMAIN
> 
>  cc:      [email-masked], [email-masked],
>           [email-masked]
> 
> 
> 
>  Subject: Re: Span Definition
> 
> 
> Diego,
> 
> 3R regeneration sites are in the OTN (G.872, G.709, G.798) represented
> by the OCh termination point; i.e. when the OCh signal is terminated 3R
> processing is performed including section monitoring (OTUk or OTUkV
> termination).
> The OMS termination point is not associated with 3R processing. It is
> only involved with optical multiplexing/demultiplexing (OCh signals are
> muxed/demuxed here) and termination of the OMS trail (OMSn_TT and
> OMSn/OCh_A functions). For more information on functionality of the OTN
> atomic functions you can have a look at draft G.798 version 0.8.1 at
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf
> 
> You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted
> in slide 15 of the following OTN/G.709 presentation
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/OTN/g709-intro.ppt
> 
> Regards,
> 
> Maarten
> 
> Diego Caviglia wrote:
> >
> > Ling-Zhong, Jonathan
> >
> >                                                  Could  you  please  review
> your
> > definition of span accordingly to the following one?
> >
> > Span  "A  span  consists  of  a  number of channels between two adjacent
> Optical
> > Amplification sites, a Span is a part of an Optical Link"
> > A Span is what in ITU-T is called OTS
> >
> > Optical  Link  "An  Optical  Link  consist  of  a number of channels between
> two
> > adjacent 3R regeneration sites"
> > An Optical Link is what in ITU-T is called OMS
> >
> > Regrads
> >
> > Diego.
> >
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modeling
> > E-mail: [email-masked]
> > Tel: +39 0 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
--------------E947154F1FB56A66677FE7EA
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------E947154F1FB56A66677FE7EA--

Delivery-date: Fri, 06 Jul 2001 03:51:56 -0700
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt
Date: Fri, 06 Jul 2001 06:50:43 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Routing Extensions for MPLS Signaling
	Author(s)	: A. Iwata, N. Fujita, G. Ash, A. Farrel
	Filename	: draft-iwata-mpls-crankback-01.txt
	Pages		: 30
	Date		: 05-Jul-01
	
This draft proposes crankback routing extensions for CR-LDP signaling
and for RSVP-TE signaling. Recently, several routing protocol
extensions for advertising resource information in addition to
topology information have been proposed for use in distributed
constraint-based routing. In such a distributed routing environment,
however, the information used to compute a constraint-based path may
be out of date. This means that LSP setup requests may be blocked by
links or nodes without sufficient resources. This draft specifies
crankback routing extensions for CR-LDP and RSVP-TE so that the label
request can be retried on an alternate path that detours around the
blocked link or node upon a setup failure. Furthermore, the crankback
routing schemes can also be applied to LSP restoration by indicating
the location of the failure link or node. This would significantly
improve the successful recovery ratio for failed LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-iwata-mpls-crankback-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 06 Jul 2001 03:09:04 -0700
From: "Diego Caviglia" <[email-masked]>
To: Maarten Vissers <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 6 Jul 2001 12:06:10 +0200
Subject: Re: Span Definition

--0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Marteen ,
                you're right, thank you for your clarification.
Thus accordingly to your mail the Optical Link definition become:

 Optical   Link   "An   Optical  Link  consist  of  a number of channels between
two adjacent 3R regeneration sites"
An Optical Link is what in ITU-T is called Och

Regards.

Diego.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Maarten Vissers <[email-masked]> on 06/07/2001 10.55.51

                                                                                

                                                              

 To:      Diego Caviglia/MAIN/MC1@MCMAIN                      
                                                              
 cc:      [email-masked], [email-masked],          
          [email-masked]                                  

                                                              
 Subject: Re: Span Definition                                 

Diego,

3R regeneration sites are in the OTN (G.872, G.709, G.798) represented
by the OCh termination point; i.e. when the OCh signal is terminated 3R
processing is performed including section monitoring (OTUk or OTUkV
termination).
The OMS termination point is not associated with 3R processing. It is
only involved with optical multiplexing/demultiplexing (OCh signals are
muxed/demuxed here) and termination of the OMS trail (OMSn_TT and
OMSn/OCh_A functions). For more information on functionality of the OTN
atomic functions you can have a look at draft G.798 version 0.8.1 at
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf

You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted
in slide 15 of the following OTN/G.709 presentation
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/OTN/g709-intro.ppt

Regards,

Maarten

Diego Caviglia wrote:
>
> Ling-Zhong, Jonathan
>
>                                                  Could  you  please  review
your
> definition of span accordingly to the following one?
>
> Span  "A  span  consists  of  a  number of channels between two adjacent
Optical
> Amplification sites, a Span is a part of an Optical Link"
> A Span is what in ITU-T is called OTS
>
> Optical  Link  "An  Optical  Link  consist  of  a number of channels between
two
> adjacent 3R regeneration sites"
> An Optical Link is what in ITU-T is called OMS
>
> Regrads
>
> Diego.
>
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modeling
> E-mail: [email-masked]
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com

--0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo
Content-type: application/octet-stream; 
	name="mvissers.vcf"
Content-Disposition: attachment; filename="mvissers.vcf"
Content-transfer-encoding: base64

YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1
DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7
d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO
ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K
ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i
ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh
dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh
cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K

--0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo--

Delivery-date: Fri, 06 Jul 2001 01:59:23 -0700
To: q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, ccamp <[email-masked]>
Date: Fri, 06 Jul 2001 10:57:52 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, ccamp <[email-masked]>
Subject: [G.707/Y.1322] ITU-T Recommendation G.707/Y.1322 (10/00) - Network node  interface for the synchronous digital hierarchy (SDH)

This is a multi-part message in MIME format.
--------------E755EAB22A204341F844BC52
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

FYI,

Recommendation G.707 (10/2000) is now available as a pre-published
document. You can get your copy from
http://www.itu.int/itudoc/itu-t/approved/g/g707-y13.html

Regards,

Maarten

http://www.itu.int/itudoc/itu-t/approved/g/g707-y13.html
--------------E755EAB22A204341F844BC52
Content-Type: text/html; charset=iso-8859-1;
 name="g707-y13.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="g707-y13.html"
Content-Base: "http://www.itu.int/itudoc/itu-t/approv
	ed/g/g707-y13.html"
Content-Location: "http://www.itu.int/itudoc/itu-t/approv
	ed/g/g707-y13.html"

<html><head><meta http-equiv=3DContent-Type content=3Dtext/html; charset=3D=
iso-8859-1><meta http-equiv=3DContent-Script-Type content=3Dtext/javascri=
pt><meta http-equiv=3DContent-Language content=3Den><title>[G.707/Y.1322]=
 ITU-T Recommendation G.707/Y.1322 (10/00) - Network node interface for t=
he synchronous digital hierarchy (SDH)</title><script language=3DJavaScri=
pt><!-- var NS4, IE4, ver4, isMac, isMenu; // --></script><script languag=
e=3DJavaScript src=3D/res/templates/js/browserversion.js></script><meta n=
ame=3D"price" value=3D"73"></head><body bgcolor=3D#FFFFFF text=3D#000000 =
link=3D#000066 vlink=3D#0099FF alink=3D#0099FF marginheight=3D0 marginwid=
th=3D0 leftmargin=3D0 topmargin=3D0 style=3Dmargin: 0px;><table border=3D=
0 cellpadding=3D0 cellspacing=3D0 width=3D100% class=3Dglobe><tr class=3D=
topritems valign=3Dtop><td align=3Dright valign=3Dbottom width=3D3% rowsp=
an=3D2 bgcolor=3D#000066><a href=3D/><img src=3D/res/templates/images/itu=
_t-105.gif border=3D0 width=3D105 height=3D46 alt=3DITU Home Page></a></t=
d><td valign=3Dtop bgcolor=3D#000066><a name=3Dtop></a><img src=3D/res/te=
mplates/images/itu.gif border=3D0 width=3D360 height=3D20 alt=3DInternati=
onal Telecommunication Union></td><td valign=3Dmiddle align=3Dcenter bgco=
lor=3D#000066 nowrap><small><a href=3Dg707-y13-fr.html class=3Dtopritems>=
<font color=3Dwhite>Fran=E7ais</font></a>&nbsp; <a href=3Dg707-y13-es.htm=
l class=3Dtopritems><font color=3Dwhite>Espa=F1ol</font></a></small></td>=
</tr><tr bgcolor=3D#000066 valign=3Dtop class=3Dsmalltext><td height=3D22=
><table border=3D0 cellpadding=3D0 cellspacing=3D0><tr valign=3Dtop><td w=
idth=3D87><a href=3D/ onmouseover=3DpopUp('elMenu1',event) onmouseout=3Dp=
opDown('elMenu1') class=3Ditumenu><img src=3D/res/templates/images/sites.=
gif border=3D0 width=3D87 height=3D20 alt=3DOur Sites></a></td><td width=3D=
55><a href=3D/newsroom/ onmouseover=3DpopUp('elMenu2',event) onmouseout=3D=
popDown('elMenu2') class=3Ditumenu><img src=3D/res/templates/images/news.=
gif border=3D0 width=3D55 height=3D20 alt=3DNews></a></td><td width=3D66>=
<a href=3D/events/ onmouseover=3DpopUp('elMenu3',event) onmouseout=3DpopD=
own('elMenu3') class=3Ditumenu><img src=3D/res/templates/images/events.gi=
f border=3D0 width=3D66 height=3D20 alt=3DEvents></a></td><td width=3D104=
><a href=3D/publications/ onmouseover=3DpopUp('elMenu4',event) onmouseout=
=3DpopDown('elMenu4') class=3Ditumenu><img src=3D/res/templates/images/pu=
blications.gif border=3D0 width=3D104 height=3D20 alt=3DPublications></a>=
</td><td width=3D79><a href=3D/topics/ onmouseover=3DpopUp('elMenu5',even=
t) onmouseout=3DpopDown('elMenu5') class=3Ditumenu><img src=3D/res/templa=
tes/images/sitemap.gif border=3D0 width=3D79 height=3D20 alt=3DSite Map >=
</a></td><td width=3D70><a href=3D/aboutitu/ onmouseover=3DpopUp('elMenu6=
',event) onmouseout=3DpopDown('elMenu6') class=3Ditumenu><img src=3D/res/=
templates/images/about.gif border=3D0 width=3D70 height=3D20 alt=3DAbout =
Us></a></td></tr></table></td><td align=3Dcenter nowrap><small><a href=3D=
p_index.print class=3Dtopritems><font color=3Dwhite>Print Version</a></fo=
nt></small></td></tr><tr><td align=3Dright valign=3Dtop width=3D105 rowsp=
an=3D2 bgcolor=3D#0099FF class=3Dglobe-l><a href=3D/><img src=3D/res/temp=
lates/images/itubl_b-105.gif border=3D0 width=3D105 height=3D46 alt=3DITU=
 Home Page></a><br><center><table border=3D0 cellpadding=3D0 cellspacing=3D=
0 width=3D100%><tr><td align=3Dright valign=3Dtop width=3D100 class=3Dnav=
left><small><a href=3D/osg/ class=3Dnavleft>Office of the<BR>Secretary<BR=
>General</a><p><a href=3D/itu-r/ class=3Dnavleft>Radio-<BR>communication<=
BR>(ITU-R)</a><p><a href=3D/itu-t/ class=3Dnavleft>Telecom<BR>Standardiza=
tion<BR>(ITU-T)</a><p><a href=3D/itu-d/ class=3Dnavleft>Telecom<BR>Develo=
pment<BR>(ITU-D)</a><p><a href=3D/telecom/ class=3Dnavleft>TELECOM<BR>Exh=
ibitions and<BR>Forum</a><p><a href=3D/members/ class=3Dnavleft>Membershi=
p</a><p></small></td></tr></table></center></td><td valign=3Dtop colspan=3D=
2 class=3Dsmalltext><table border=3D0 cellpadding=3D0 cellspacing=3D3 wid=
th=3D100% height=3D100%><tr valign=3Dtop><td class=3Dlocator><A HREF=3D/h=
ome/>Home Page</A> : <A HREF=3D/publications/>Publications</A></td><td va=
lign=3Dmiddle align=3Dright><form name=3DQform action=3D/search/index.asp=
 method=3Dget><input type=3Dtext name=3DSearchString size=3D13 class=3Dfo=
rmdisplay><input type=3Dsubmit value=3DSearch name=3DSearchAction class=3D=
formdisplay><input type=3Dhidden name=3DAction value=3DSearch><input type=
=3Dhidden name=3Dindexdocs value=3DY><input type=3Dhidden name=3DScope va=
lue=3D&quot;/&quot;><input type=3Dhidden name=3DAbstract value=3DY><input=
 type=3Dhidden name=3Dlanguage value=3DY><input type=3Dhidden name=3Ddocl=
anguage value=3DAny Language><input type=3Dhidden name=3DFMMod value=3Dan=
y><input type=3Dhidden name=3DFMModDate value=3D><input type=3Dhidden nam=
e=3DRecordsPerPage value=3D10><input type=3Dhidden name=3DSortBy value=3D=
" order by rank desc"><input type=3Dhidden name=3DColChoice value=3D1><in=
put type=3Dhidden name=3Dpagelanguage value=3Den></form></td></tr><tr><td=
 valign=3Dtop colspan=3D2 class=3Dbluebordertable height=3D100%><table bo=
rder=3D0 cellspacing=3D1 cellpadding=3D3 width=3D100%><tr><td class=3Dch-=
blue-white>[G.707/Y.1322] ITU-T Recommendation G.707/Y.1322 (10/00) - Net=
work node interface for the synchronous digital hierarchy (SDH)</td></tr>=
<tr><td valign=3Dtop height=3D350><!-- Print Section // --><table =3D0 wi=
dth=3D100%><tr><td width=3D100%><p align=3Dleft>&nbsp;<br><font color=3D#=
000066><b>Availability : </b></font><a href=3Dhttp://www.itu.int/POD/how-=
to-buy.html> Electronic Bookshop</a> &nbsp;<a href=3D/publications/online=
=2Ehtm>Subscription Service</a> &nbsp; (ITU-T Recommendations Online) &nb=
sp; <br><strong><font color=3Dred>Price:</font><font color=3D#FF0000 face=
=3Darial,hevetica,sans-serif></font></strong><font color=3D#FF0000>73 CHF=
 (Swiss Francs)</font></p></td><td width=3D0 bgcolor=3Dwhite valign=3Dtop=
><p align=3Dcenter><b><font color=3D#FFFFFF></td></tr></table><p align=3D=
left><p align=3Dleft><font color=3D#000066><b> To add item to your shoppi=
ng basket click on <i>Add to Cart</i> </b></font></p><p align=3Dleft><fon=
t color=3D#000066><b>View or Download Document</b></font></p><table borde=
r=3D0 width=3D100% cellspacing=3D0 cellpadding=3D0><tr><td align=3Dcenter=
 valign=3Dtop></td><td valign=3Dtop align=3Dcenter><p align=3Dleft><stron=
g><font color=3D#000066>Format</font></strong></p></td><td align=3Dcenter=
 valign=3Dtop><p align=3Dcenter><strong><font color=3D#000066>Size</font>=
</strong></p></td><td align=3Dcenter valign=3Dtop><p align=3Dcenter><stro=
ng><font color=3D#000066>Posted</font></strong></p></td><td valign=3Dtop =
align=3Dcenter><p align=3Dcenter><b><font color=3D#000066>E-Bookshop</fon=
t></b></p></td><td valign=3Dtop align=3Dcenter><p align=3Dcenter><b><font=
 color=3D#000066>Subscribers</font></b></p></td></tr><tr><td align=3Drigh=
t height=3D2 bgcolor=3Dblack><spacer type=3Dblock width=3D1 height=3D2></=
td><td align=3Dright height=3D2 bgcolor=3Dblack colspan=3D5><spacer type=3D=
block width=3D1 height=3D2></td></tr><tr><td align=3Dcenter><p align=3Dce=
nter><strong>English</strong>&nbsp;</p></td><td align=3Dcenter><p align=3D=
left>Word for Windows 2000</p></td><td align=3Dcenter><p align=3Dcenter>1=
=2E2 mb</p></td><td align=3Dcenter><p align=3Dcenter>Jul 04 2001</p></td>=
<td align=3Dcenter><p align=3Dcenter><A HREF=3D"http://ecs.itu.ch/cgi-bin=
/run/bookshop?145876">Add to Cart</a></p></td><td align=3Dcenter><p align=
=3Dcenter><b><a href=3D/itudocs/itu-t/approved/g/g707-y13_ww9.doc onclick=
=3D""> <img src=3D"http://www.itu.int/templates/graphics/imedwnld.gif" al=
t=3DDownload TITLE=3D"... via Subscription Service" border=3D0 WIDTH=3D12=
 HEIGHT=3D12></a></b></p></td></tr><tr><td align=3Dright height=3D2 ><spa=
cer type=3Dblock width=3D1 height=3D2></td><td align=3Dright height=3D2  =
colspan=3D5><spacer type=3Dblock width=3D1 height=3D2></td></tr><tr><td a=
lign=3Dcenter><p align=3Dcenter><strong></strong>&nbsp;</p></td><td align=
=3Dcenter><p align=3Dleft>ZIPPED Word for Windows 2000</p></td><td align=3D=
center><p align=3Dcenter>512.2 kb</p></td><td align=3Dcenter><p align=3Dc=
enter>Jul 04 2001</p></td><td align=3Dcenter><p align=3Dcenter><A HREF=3D=
"http://ecs.itu.ch/cgi-bin/run/bookshop?145880">Add to Cart</a></p></td><=
td align=3Dcenter><p align=3Dcenter><b><a href=3D/itudocs/itu-t/approved/=
g/g707-y13_ww9.zip onclick=3D""> <img src=3D"http://www.itu.int/templates=
/graphics/imedwnld.gif" alt=3DDownload TITLE=3D"... via Subscription Serv=
ice" border=3D0 WIDTH=3D12 HEIGHT=3D12></a></b></p></td></tr><tr><td alig=
n=3Dright height=3D2 bgcolor=3Dblack><spacer type=3Dblock width=3D1 heigh=
t=3D2></td><td align=3Dright height=3D2 bgcolor=3Dblack colspan=3D5><spac=
er type=3Dblock width=3D1 height=3D2></td></tr><tr><td colspan=3D4></td><=
td colspan=3D2 align=3Dcenter><p><br><a href=3Dhttp://ecs.itu.ch/cgi-bin/=
checkout>Checkout (Pay)</a><br><a href=3Dhttp://ecs.itu.ch/cgi-bin/booksh=
op?status>Basket Status</a></p></td></tr></table></td></tr></table><!-- P=
rint Section // --></td></tr></table></td></tr><tr><script> if (navigator=
=2EappName =3D=3D "Netscape") { document.write('<td valign=3Dbottom colsp=
an=3D2 height=3D1><img src=3D/res/templates/images/blueline.gif width=3D'=
+(screen.width-120)+' height=3D1></td>'); } else { document.write('<td va=
lign=3Dbottom colspan=3D2 height=3D1 width=3D100% class=3Dbottomline>&nbs=
p;</td>'); } </script></tr></table></td></tr></table><p><table border=3D0=
 cellpadding=3D0 cellspacing=3D0 width=3D100%><tr valign=3Dtop><td align=3D=
right class=3Dfooteritems><a href=3D#top class=3Dfooteritems>Top</a>&nbsp=
;-&nbsp; <a href=3D/home/feedback/index.html class=3Dfooteritems>Feedback=
</a>&nbsp;-&nbsp; <a href=3D/home/privacy/index.html class=3Dfooteritems>=
Privacy</a>&nbsp;-&nbsp; <a href=3D/home/copyright/index.html class=3Dfoo=
teritems>Copyright =A9 ITU&nbsp;2001</a>&nbsp;All Rights Reserved <br>Con=
tact for this page :&nbsp;<a href=3Dmailto:[email-masked] class=3Dfoot=
eritems>[email-masked]</a><br>Updated :&nbsp;2001-07-06</td><td>&nbsp;=
</td></tr></table></body></html>
--------------E755EAB22A204341F844BC52
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------E755EAB22A204341F844BC52--

Delivery-date: Fri, 06 Jul 2001 01:57:27 -0700
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 06 Jul 2001 10:55:51 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Diego Caviglia <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Span Definition

This is a multi-part message in MIME format.
--------------BD970029CBAB8023FD4F73AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Diego,

3R regeneration sites are in the OTN (G.872, G.709, G.798) represented
by the OCh termination point; i.e. when the OCh signal is terminated 3R
processing is performed including section monitoring (OTUk or OTUkV
termination). 
The OMS termination point is not associated with 3R processing. It is
only involved with optical multiplexing/demultiplexing (OCh signals are
muxed/demuxed here) and termination of the OMS trail (OMSn_TT and
OMSn/OCh_A functions). For more information on functionality of the OTN
atomic functions you can have a look at draft G.798 version 0.8.1 at
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf

You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted
in slide 15 of the following OTN/G.709 presentation
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/OTN/g709-intro.ppt

Regards,

Maarten

Diego Caviglia wrote:
> 
> Ling-Zhong, Jonathan
> 
>                                                  Could  you  please  review your
> definition of span accordingly to the following one?
> 
> Span  "A  span  consists  of  a  number of channels between two adjacent Optical
> Amplification sites, a Span is a part of an Optical Link"
> A Span is what in ITU-T is called OTS
> 
> Optical  Link  "An  Optical  Link  consist  of  a number of channels between two
> adjacent 3R regeneration sites"
> An Optical Link is what in ITU-T is called OMS
> 
> Regrads
> 
> Diego.
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modeling
> E-mail: [email-masked]
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
--------------BD970029CBAB8023FD4F73AA
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------BD970029CBAB8023FD4F73AA--

Delivery-date: Fri, 06 Jul 2001 00:58:59 -0700
From: "Diego Caviglia" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Date: Fri, 6 Jul 2001 09:49:54 +0200
Subject: Span Definition

Ling-Zhong, Jonathan

                                                 Could  you  please  review your
definition of span accordingly to the following one?

Span  "A  span  consists  of  a  number of channels between two adjacent Optical
Amplification sites, a Span is a part of an Optical Link"
A Span is what in ITU-T is called OTS

Optical  Link  "An  Optical  Link  consist  of  a number of channels between two
adjacent 3R regeneration sites"
An Optical Link is what in ITU-T is called OMS

Regrads

Diego.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Delivery-date: Thu, 05 Jul 2001 16:38:01 -0700
Date: Thu, 5 Jul 2001 16:34:32 -0700 (PDT)
From: Pyda Srisuresh <[email-masked]>
Subject: Re: Agenda Request: IETF Meeting for CCAMP
To: Vijay Gill <[email-masked]>, [email-masked]
Cc: [email-masked]

Hi,

We would like 10 to 15 mins to discuss the following draft.

    Title:    New TE LSAs to extend OSPF for Traffic Engineering
    http URL: draft-srisuresh-ospf-te-00.txt

Thanks.

regards,
suresh
      
--- Vijay Gill <[email-masked]> wrote:
> 
> Folks
> 
> Are there any items people would like to put on the
> agenda for the London IETF meeting?
> 
> Please send requests to Kireeti and myself.
> 
> [email-masked]
> [email-masked]
> 
> 
> thanks
> 
> your co-chairs
> 
> kireeti and vijay
> 
> 
> 
> 

=====

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Delivery-date: Thu, 05 Jul 2001 08:23:37 -0700
From: [email-masked]
Date: Thu, 5 Jul 2001 10:19:26 -0500
Subject: RE: Re: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00
TO: [email-masked]
CC: [email-masked]

Hi Kireeti,

Thanks for the input. 
Does this mean that in the GMPLS hierarchal model we will have (PSC or
L2SC) over TDM over LSC over FSC layers?

Thanks.
-Wesam
-----Original Message-----
From: k.kompella [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 4:05 AM
To: wesam.alanqar; ccamp
Subject: Re: doubts about PSC and L2SC in
draft-ietf-ccamp-gmpls-architecture-00

Hi,

PSC is for Layer 3 packets encapsulated in an MPLS
header.  L2SC is for Layer 2 packets (as you say,
ATM and Frame Relay) where the MPLS label reflects
the layer 2 address.  L2SC is *not* for ATM/Frame
transport over MPLS (for that, see the PWE3 WG).

Kireeti.

PS.  Incidentally, L2SC was introduced in the GMPLS
*routing* documents, not in the architecture doc.

--- [email-masked] wrote:
> Hi,
> 
> In the original GMPLS architecture, PSC interfaces
> were introduced for
> the packet layer. Why in this document L2SC
> interfaces are introduced?

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Delivery-date: Wed, 04 Jul 2001 06:26:19 -0700
Cc: "'manoj juneja'" <[email-masked]>, [email-masked], "Igor Danilovich (E-mail)" <[email-masked]>
Date: Wed, 04 Jul 2001 15:23:54 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sasha Vainshtein <[email-masked]>
Original-CC: "'manoj juneja'" <[email-masked]>, [email-masked], "Igor Danilovich (E-mail)" <[email-masked]>
Subject: Re: sdh Doubt

This is a multi-part message in MIME format.
--------------C72F1189578629BE3D686ECC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj, Sasha,

Once you have connected two STM-N (e.g. STM-256) ports together you have
created a MSn (e.g. MS256) trail. Such MSn trail supports a HOVC
topological link (G.85x terminology). This HOVC link contains a number
of HOVC link connections. 

An STM-256 trail may support the following link connection types: VC-3,
VC-4, VC-4-4c, VC-4-16c, VC-4-64c and VC-4-256c. 

The specific set of HOVC link connections supported by a particular HOVC
link is STM-N port pair dependent. This depends on the capabilities
supported by the AU pointer processor circuits in these ports and the
capabilities supported by the fabrics to which these ports are
connected.

E.g. STM-256 port A may support AU-4, AU-4-4c and AU-4-16 pointer
processing, whereas the STM-256 port B to which it is A is connected may
support AU-3, AU-4 and AU-4-4c pointer processing. The STM-256 port pair
then supports VC-4 and VC-4-4c link connections within this HOVC
topological link.

If at time Ta a particular AUG-4 entity within the STM-256 is
provisioned to operate as AU-4-4c and transport a VC-4-4c signal, and
the associated connection is removed at time Tb, then this AUG-4
bandwidth may be used at Tc > Tb for wither 4 VC-4 connections or 1
VC-4-4c connection. For the former case (4x VC-4) the VC-4-4c link
connection supported by AU-4-4c pointer processing must be converted
into 4 VC-4 link connections supported by 4x AU-4 pointer processing.

The same is applicable if a STM-256 trail supporting a HOVC link with
VC-4-256c link connection capability has to transport e.g. a VC-4-64c.
The transport of a VC-4-64c is only possible if the VC-4-256c connection
is not longer present. If not longer present, the whole HOVC link
bandwidth is available for other services, and to support a VC-4-46c the
VC-4-256c link connection is replaced by a VC-4-64c link connection
(supported by AU-4-64c pointer processing) and the remainder of the
bandwidth is set to support e.g. VC-3 link connections. These latter
ones will then carry VC-3 UNEQ signals. But any other VC-n level may
also be choosen... but both ends of the HOVC link must decide one the
same VC-n type; otherwise you get a series of AU-LOP alarms from these
endpoints.

Note that according G.707 the AUG-X isn't a signal; it is only a means
to describe the ordering and multiplex structure of AUs. In reality, you
have a mix of AU-3, AU-4, AU-4-4c, AU-4-16c, AU-4-64c or one AU-4-256c
processing active. In most equipment you can change this mix when
required.

Regards,

Maarten

Sasha Vainshtein wrote:
> 
> Manoj,
> AFAIK, the answer is YES. In SDH, once you have performed concatenation,
> on a certain stream, you cannot allocate access separate substreams.
> 
> With best regards,
>                                    Sasha Vainshtein
> email:     [email-masked] <mailto:[email-masked]>
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
> 
> 
> > -----Original Message-----
> > From: manoj juneja [mailto:[email-masked]]
> > Sent: Wednesday, June 27, 2001 9:12 PM
> > To: [email-masked]
> > Subject: sdh Doubt
> >
> >
> > Hi All,
> >          AUG-256 may consist of :
> >                   1. 4 AUG-64
> >                   2. 1 AU-4-256c
> >
> >   If AUG-256 consists of 1 AU-4-256c, does this mean it can't
> > allocate
> > signals of less granularity than this (viz. one VC-4 or
> > VC-4-64c or VC-4-16c
> > etc) ?
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >
--------------C72F1189578629BE3D686ECC
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------C72F1189578629BE3D686ECC--

Delivery-date: Wed, 04 Jul 2001 04:55:09 -0700
Cc: [email-masked]
Date: Wed, 04 Jul 2001 13:53:38 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: SDH/SONET Doubt

This is a multi-part message in MIME format.
--------------D749F44EDBDB516FB2AA2DA9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

A STM-N signal may contain of a set of HOVC signals. 
HOVC signals are VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c and VC-4-256c
signals. A VC-3 or VC-4 signal may contains a set of LOVC signals. 
LOVC signals for the case of HO-VC-3 are VC-11, VC-12 and VC-2. LOVC
signals for the cae of VC-4 are VC-11, VC-12, VC-2 and VC-3.

At STM-N level, you only have visibility in the HOVC signal structure;
you don't care about the content of the HOVC signal. At HO-VC-3 and VC-4
level you have visibility in the LOVC signal structure.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi All,
>           Can the STM-N link consist of mix of VC-4, VC-3, VC-11, VC-12,
> VC-2 signals ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------D749F44EDBDB516FB2AA2DA9
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D749F44EDBDB516FB2AA2DA9--

Delivery-date: Wed, 04 Jul 2001 02:07:14 -0700
Date: Wed, 4 Jul 2001 02:05:06 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Subject: Re: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00
To: [email-masked], [email-masked]

Hi,

PSC is for Layer 3 packets encapsulated in an MPLS
header.  L2SC is for Layer 2 packets (as you say,
ATM and Frame Relay) where the MPLS label reflects
the layer 2 address.  L2SC is *not* for ATM/Frame
transport over MPLS (for that, see the PWE3 WG).

Kireeti.

PS.  Incidentally, L2SC was introduced in the GMPLS
*routing* documents, not in the architecture doc.

--- [email-masked] wrote:
> Hi,
> 
> In the original GMPLS architecture, PSC interfaces
> were introduced for
> the packet layer. Why in this document L2SC
> interfaces are introduced?

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Delivery-date: Tue, 03 Jul 2001 17:24:14 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Explicit Label Control
Date: Tue, 03 Jul 2001 17:23:15 -0700

Hi All,

In GMPLS drafts, the concept of Egress/explicit Label
control is described. Is this valid only at egress or intermediate
nodes also ?
I mean to say whether the Egress Label object will only be at the end
of ERO or it can appear in between ?

Regards,
manoj.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 03 Jul 2001 16:33:21 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: SDH/SONET Doubt
Date: Tue, 03 Jul 2001 16:27:44 -0700

Hi All,
          Can the STM-N link consist of mix of VC-4, VC-3, VC-11, VC-12, 
VC-2 signals ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 03 Jul 2001 12:26:16 -0700
From: [email-masked]
Date: Tue, 3 Jul 2001 13:39:24 -0500
Subject: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00
TO: [email-masked]

Hi,

In the original GMPLS architecture, PSC interfaces were introduced for
the packet layer. Why in this document L2SC interfaces are introduced? 

Why do we need to introduce a new level of hierarchy?
In the original GMPLS architecture, we had PSC,TDM, LSC, FSC. In this
draft we have L2SC added.

Is this to make GMPLS more applicable for ATM and Ethernet "MPLS
capable" in addition to IP-based networks. 

Do we need to use one type of interfaces (PSC or L2SC) above the TDM
layer or we could use both?

Thanks

-----------------------------------------------------
Wesam Alanqar         Member of Technical Staff
Technology Research Group
Technology Planning & Integration Dept. (TP&I)
Sprint
9300 Metcalf Avenue, KS 66212 
Phone: 913-534-5623 Work, Fax: 913-534-3485
------------------------------------------------------
-----Original Message-----
From: Internet-Drafts [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 5:56 AM
To: IETF-Announce: .
Cc: ccamp; Internet-Drafts
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.

      Title       : Generalized Multi-Protocol Label Switching (GMPLS) 
                          Architecture
      Author(s)   : E. Mannie et al.
      Filename    : draft-ietf-ccamp-gmpls-architecture-00.txt
      Pages       : 48
      Date        : 02-Jul-01
      
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-
00.txt

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
      "get draft-ietf-ccamp-gmpls-architecture-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
      [email-masked].
In the body type:
      "FILE
/internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt".
      
NOTE: The mail server at ietf.org can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail
readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e. documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Tue, 03 Jul 2001 12:05:56 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked],  [email-masked]
Subject: RE: draft-ietf-mpls-lmp-02.txt
Date: Tue, 3 Jul 2001 12:03:43 -0700 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103F2.E10E8A40
Content-Type: text/plain;
	charset="iso-8859-1"

Dear Jonathan,

there are two LMP drafts (both -02) at ietf.org website:
  1. URL below (in Kireeti's email);
  2. URL:  http://search.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt

URL 1 has an outdatd version.
i think someone should remove it to avoid confusion.
Dan Guo
Turin Networks.

Kireeti Kompella wrote:
> 
> Hi All,
> 
> Once upon a time, there was consensus to make the above document
> (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
> an MPLS WG document.
> 
> It now falls under the purvey of CCAMP.  Question: do you think this
> document should be a CCAMP WG document?  (You know the drill ....)
> 
> Kireeti & Vijay.

------_=_NextPart_001_01C103F2.E10E8A40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: draft-ietf-mpls-lmp-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dear Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>there are two LMP drafts (both -02) at ietf.org =
website:</FONT>
<BR><FONT SIZE=3D2>&nbsp; 1. URL below (in Kireeti's email);</FONT>
<BR><FONT SIZE=3D2>&nbsp; 2. URL:&nbsp; <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.tx=
t" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-ietf-mpls=
-lmp-02.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>URL 1 has an outdatd version.</FONT>
<BR><FONT SIZE=3D2>i think someone should remove it to avoid =
confusion.</FONT>
<BR><FONT SIZE=3D2>Dan Guo</FONT>
<BR><FONT SIZE=3D2>Turin Networks.</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Once upon a time, there was consensus to make =
the above document</FONT>
<BR><FONT SIZE=3D2>&gt; (URL: <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.tx=
t" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-lang-mpls=
-lmp-02.txt</A> )</FONT>
<BR><FONT SIZE=3D2>&gt; an MPLS WG document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It now falls under the purvey of CCAMP.&nbsp; =
Question: do you think this</FONT>
<BR><FONT SIZE=3D2>&gt; document should be a CCAMP WG document?&nbsp; =
(You know the drill ....)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kireeti &amp; Vijay.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103F2.E10E8A40--

Delivery-date: Tue, 03 Jul 2001 10:19:23 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-bellato-ccamp-g709-framework-00.txt
Date: Tue, 03 Jul 2001 13:13:08 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: G.709 Optical Transport Networks GMPLS Control 
                          Framework
	Author(s)	: A. Bellato et al.
	Filename	: draft-bellato-ccamp-g709-framework-00.txt
	Pages		: 27
	Date		: 02-Jul-01
	
Along with the current development of packet over lambda switching
(referred to as MPLambdaS), there are considerable developments in
optical transport systems based on the ITU-T G.872 [ITUT-G872] and
G.709 [ITUT-G709] specification. The Optical Transport Network (OTN)
defined in G.872 and G.709 enables ultra-long-haul transmission of
various client signal types through the use of Forward Error
Correction (FEC) bytes. G.709 specifies the data plane transport
structure and allocates overhead bytes for the OTN control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bellato-ccamp-g709-framework-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-bellato-ccamp-g709-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-bellato-ccamp-g709-framework-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-bellato-ccamp-g709-framework-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-bellato-ccamp-g709-framework-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 03 Jul 2001 07:16:46 -0700
Date: Tue, 03 Jul 2001 10:13:49 -0400
From: Eric Gray <[email-masked]>
To: Bert Wijnen <[email-masked]>, Scott Bradner <[email-masked]>, Kireeti Kompella <[email-masked]>, George Swallow <[email-masked]>, Vijay Gill <[email-masked]>, Vijay Srinivasan <[email-masked]>
Cc: MPLS Mailing List <[email-masked]>, Common Control and Measurement Protocols <[email-masked]>
Subject: Working Group tasks and charter cleanup

Any chance that we will see how the tasks are divided between the
MPLS and CCAMP working groups - including cleanup of the group
charters, moving Internet Drafts to the right places (and names?),
and so on before the next IETF meeting?

--
Eric Gray

Delivery-date: Tue, 03 Jul 2001 05:50:10 -0700
Date: Tue, 03 Jul 2001 08:52:13 -0400
To: Vijay Gill <[email-masked]>, [email-masked], <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Agenda Request: IETF Meeting for CCAMP

         Vijay

         A discussion of which drafts
have been kept/added/deleted from the WG as a
result of the rest IESG review would be useful.
Also, if there are any charter changes, these
would be interesting to discuss.

         --Tom

>Are there any items people would like to put on the
>agenda for the London IETF meeting?
>
>Please send requests to Kireeti and myself.
>
>[email-masked]
>[email-masked]
>
>
>thanks
>
>your co-chairs
>
>kireeti and vijay

Delivery-date: Tue, 03 Jul 2001 03:59:25 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-fontana-ccamp-gmpls-g709-00.txt
Date: Tue, 03 Jul 2001 06:57:16 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS Signalling Extensions for G.709 Optical 
                          Transport Networks Control
	Author(s)	: A. Bellato et al.
	Filename	: draft-fontana-ccamp-gmpls-g709-00.txt
	Pages		: 7
	Date		: 02-Jul-01
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It
describes the G.709 technology specific information needed to
extend GMPLS signalling to control Optical Transport Networks
(OTN) including the so-called pre-OTN developments both described
in [G709-FRM].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-fontana-ccamp-gmpls-g709-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-fontana-ccamp-gmpls-g709-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 03 Jul 2001 03:59:21 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-00.txt
Date: Tue, 03 Jul 2001 06:56:09 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) 
                          Architecture
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-architecture-00.txt
	Pages		: 48
	Date		: 02-Jul-01
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-architecture-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-architecture-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 02 Jul 2001 16:08:40 -0700
Date: Mon, 02 Jul 2001 19:08:18 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: manoj juneja <[email-masked]>
CC: [email-masked]
Subject: Re: Bandwidth Encoding Type Doubt .....

Manoj,

It seems to me a redundancy.

Thanks,

Yangguang

manoj juneja wrote:
> 
> Hi,
>     Can someone please tell me the reason for bandwidth encoding
> parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> will be drived from the signal type field. How the bandwidth
> encoding type will be interpreted in case of other LSP encoding types ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 02 Jul 2001 16:04:57 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bandwidth Encoding Type Doubt .....
Date: Mon, 02 Jul 2001 14:41:16 -0700

Hi,
    Can someone please tell me the reason for bandwidth encoding
parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
will be drived from the signal type field. How the bandwidth
encoding type will be interpreted in case of other LSP encoding types ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 02 Jul 2001 14:06:01 -0700
Date: Mon, 2 Jul 2001 17:02:12 -0400
From: Vijay Gill <[email-masked]>
To: <[email-masked]>
Subject: Agenda Request: IETF Meeting for CCAMP

Folks

Are there any items people would like to put on the
agenda for the London IETF meeting?

Please send requests to Kireeti and myself.

[email-masked]
[email-masked]

thanks

your co-chairs

kireeti and vijay

Delivery-date: Mon, 02 Jul 2001 09:40:05 -0700
From: "Diego Caviglia" <[email-masked]>
To: Yangguang Xu <[email-masked]>
cc: Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 2 Jul 2001 17:37:14 +0200
Subject: Re: Suggested Label Doubt

--0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Yangguang,
                                  please see my comment in-line.

Regards.

Diego.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Yangguang Xu <[email-masked]> on 02/07/2001 16.35.11

                                                                                

                                                              

 To:      Eric Gray <[email-masked]>                 
                                                              
 cc:      "[email-masked]" <[email-masked]>(bcc:      
          Diego Caviglia/MAIN/MC1)                            

                                                              
 Subject: Re: Suggested Label Doubt                           

--0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Eric,

I was about to keep quite... Because of recent discussions, here is my =
comments
to your previous example in-lines.

I am OK with current suggested label, label set etc. However I want to =
figure
out the real application in circuit switching network and please help m=
e about
it. Thanks a lot.

[snipped]
> > >
> >
> > Would you please give me an example that what I said is not true?
>
>
> Local significance - not every switch in an optical domain is necessa=
rily
> capable of performing the same kind of "optical switching".  This doe=
s not
> mean that they cannot interoperate - but it does mean that they may n=
ot
> interoperate in the way that you expect.

Can you give me an "example", I mean a real one? Please specify what ty=
pe of
circuit switches you are talking about, what's their functions etc. I h=
ave heard
too many hyperthetical applications that don't exist at all.

/[dc]  Could you please give us, or at least to me, a definition and so=
me
examples of "?too many hyperthetical applications that don't exist at a=
ll."
/[dc]

> Under these circumstances, the
> choice of "label" may have greater than local significance.

Then that's routing constrains and you can specify certain routing cons=
trains at
the signaling time. Label itself only has local significance.

> Moreover, you
> cannot end up lambda switching two light beams of the same color into=

> a single piece of glass.

If you don't have any type of multiplexing mechanisms. It doesn't matte=
r they
are the same color or not.

Otherwise, indeed you can, and it depends on your multiplexing and modu=
lation
mechanisms (. You are probably only talking about wavelength multiplexi=
ng. For
that specific case, you may be right.

Sorry, this is just a side topic.

>
> Upstream/Downstream indifference of choice - true in optical networks=
 (at
> least "Normally"), but not particularly relevant.  One or the other M=
UST
> have the final say and the model to-date has been that the final word=
 is
> given by the downstream.  Given that there MAY BE a scenario in which=
 one
> or the other has less than complete knowledge, it is necessary to hav=
e a
> negotiation/arbitration mechanism.
>

I think the upstream/downstream nodes are symmetric in circuit switchin=
g
network. I am looking an example to show me that your "MAY BE" is true.=

BTW, I have concern about the definition of upstream/downstream. Their
definitions in RFC 3031 need modifications for GMPLS.

Thanks,

Yangguang

=

--0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk--

Delivery-date: Mon, 02 Jul 2001 08:07:15 -0700
Date: Mon, 02 Jul 2001 11:03:15 -0400
From: Eric Gray <[email-masked]>
To: Yangguang Xu <[email-masked]>
Cc: Common Control and Measurement Protocols <[email-masked]>
Subject: Re: Suggested Label Doubt

Yangguang,

    We should take this discussion off-line.

--
Eric Gray

You wrote:

> Eric,
>
> I was about to keep quite... Because of recent discussions, here is my comments
> to your previous example in-lines.
>
> I am OK with current suggested label, label set etc. However I want to figure
> out the real application in circuit switching network and please help me about
> it. Thanks a lot.
>
> [snipped]
> > > >

Delivery-date: Mon, 02 Jul 2001 08:02:18 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-01.txt
Date: Mon, 02 Jul 2001 10:55:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS Extensions for SONET and SDH Control
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-01.txt
	Pages		: 25
	Date		: 29-Jun-01
	
This document is a companion to the Generalized MPLS signaling
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines
the SONET/SDH technology specific information needed when using
GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 02 Jul 2001 07:57:46 -0700
Date: Mon, 02 Jul 2001 16:00:12 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>, ccamp <[email-masked]>
Subject: Re: Fwd: RE: {SUKLM} numbering scheme

This is a multi-part message in MIME format.
--------------796300C60EC73EF388C167C9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj, Eric,

Attached is a copy of the SU - EDCBA conversion formula and tables, as
it was included in draft-lin-ccamp-ipo-common-label-request-01.txt. It
could be made apendix 6 of the GMPLs SOENT/sDH extensions document. We
should verify if the recent modifications require changes to the formula
and tables.

Regards,

Maarten
--------------796300C60EC73EF388C167C9
Content-Type: text/plain; charset=us-ascii;
 name="untitled.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="untitled.txt"

Appenix 6: Conversion formula for EDCBA <-> SU

For the EDCBA to SU conversion, the following formula can be used:

        S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] +
              max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1

                      B
        U = ceiling[ --- , 0 ] + A
                     B+1

For the SU to EDCBA conversion, the following formula can be used:

                           S
        E = max[ ceiling[ --- ], 0 ]
                          64

              or 0 {for AU-4-256c & STM-64 or lower}

                               S
        D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
                              16

              or 0 {for AU-4-64c or above & STM-16 or lower}

                               S
        C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
                               4

              or 0 {for AU-4-16c or above & STM-4 or lower}

        B = [ ( S-1 ) modulo 4 ] + 1
              or 0 {for AU-4-4c or above & STM-1 or lower}

        A = U - 1
              or 0 (for AU-4 or above)

Sample conversion table

The following table provides the explicit mapping between the SU and the
EDCBA numbering scheme:

Conversion table (E,D,C,B,A) (ITU-T G.707) to SU:

G.707
EDCBA     S U   Signal Type
=========================================
00000     1 0   AU-4-256c/STS-768c in STM-256/OC-768

10000     1 0   AU-4-64c/STS-192c in STM-256/OC-768
20000    65 0   AU-4-64c/STS-192c in STM-256/OC-768
30000   129 0   AU-4-64c/STS-192c in STM-256/OC-768
40000   193 0   AU-4-64c/STS-192c in STM-256/OC-768

11000     1 0   AU-4-16c/STS-48c in STM-256/OC-768
12000    17 0   AU-4-16c/STS-48c in STM-256/OC-768
13000    33 0   AU-4-16c/STS-48c in STM-256/OC-768
14000    49 0   AU-4-16c/STS-48c in STM-256/OC-768
21000    65 0   AU-4-16c/STS-48c in STM-256/OC-768
22000    81 0   AU-4-16c/STS-48c in STM-256/OC-768
23000    97 0   AU-4-16c/STS-48c in STM-256/OC-768
24000   113 0   AU-4-16c/STS-48c in STM-256/OC-768
31000   129 0   AU-4-16c/STS-48c in STM-256/OC-768
32000   145 0   AU-4-16c/STS-48c in STM-256/OC-768
33000   161 0   AU-4-16c/STS-48c in STM-256/OC-768
34000   177 0   AU-4-16c/STS-48c in STM-256/OC-768
41000   193 0   AU-4-16c/STS-48c in STM-256/OC-768
42000   209 0   AU-4-16c/STS-48c in STM-256/OC-768
43000   225 0   AU-4-16c/STS-48c in STM-256/OC-768
44000   241 0   AU-4-16c/STS-48c in STM-256/OC-768

11100     1 0   AU-4-4c/STS-12c in STM-256/OC-768
11200     5 0   AU-4-4c/STS-12c in STM-256/OC-768
11300     9 0   AU-4-4c/STS-12c in STM-256/OC-768
11400    13 0   AU-4-4c/STS-12c in STM-256/OC-768
12100    17 0   AU-4-4c/STS-12c in STM-256/OC-768
12200    21 0   AU-4-4c/STS-12c in STM-256/OC-768
12300    25 0   AU-4-4c/STS-12c in STM-256/OC-768
12400    29 0   AU-4-4c/STS-12c in STM-256/OC-768
13100    33 0   AU-4-4c/STS-12c in STM-256/OC-768
13200    37 0   AU-4-4c/STS-12c in STM-256/OC-768
13300    41 0   AU-4-4c/STS-12c in STM-256/OC-768
13400    45 0   AU-4-4c/STS-12c in STM-256/OC-768
14100    49 0   AU-4-4c/STS-12c in STM-256/OC-768
14200    53 0   AU-4-4c/STS-12c in STM-256/OC-768
14300    57 0   AU-4-4c/STS-12c in STM-256/OC-768
14400    61 0   AU-4-4c/STS-12c in STM-256/OC-768
21100    65 0   AU-4-4c/STS-12c in STM-256/OC-768
21200    69 0   AU-4-4c/STS-12c in STM-256/OC-768
21300    73 0   AU-4-4c/STS-12c in STM-256/OC-768
21400    77 0   AU-4-4c/STS-12c in STM-256/OC-768
22100    81 0   AU-4-4c/STS-12c in STM-256/OC-768
22200    69 0   AU-4-4c/STS-12c in STM-256/OC-768
22300    73 0   AU-4-4c/STS-12c in STM-256/OC-768
22400    77 0   AU-4-4c/STS-12c in STM-256/OC-768
23100    97 0   AU-4-4c/STS-12c in STM-256/OC-768
23200    69 0   AU-4-4c/STS-12c in STM-256/OC-768
23300    73 0   AU-4-4c/STS-12c in STM-256/OC-768
23400    77 0   AU-4-4c/STS-12c in STM-256/OC-768
24100   113 0   AU-4-4c/STS-12c in STM-256/OC-768
24200   117 0   AU-4-4c/STS-12c in STM-256/OC-768
24300   121 0   AU-4-4c/STS-12c in STM-256/OC-768
24400   125 0   AU-4-4c/STS-12c in STM-256/OC-768
31100   129 0   AU-4-4c/STS-12c in STM-256/OC-768
31200   133 0   AU-4-4c/STS-12c in STM-256/OC-768
31300   137 0   AU-4-4c/STS-12c in STM-256/OC-768
31400   141 0   AU-4-4c/STS-12c in STM-256/OC-768
32100   145 0   AU-4-4c/STS-12c in STM-256/OC-768
32200   149 0   AU-4-4c/STS-12c in STM-256/OC-768
32300   153 0   AU-4-4c/STS-12c in STM-256/OC-768
32400   157 0   AU-4-4c/STS-12c in STM-256/OC-768
33100   161 0   AU-4-4c/STS-12c in STM-256/OC-768
33200   165 0   AU-4-4c/STS-12c in STM-256/OC-768
33300   169 0   AU-4-4c/STS-12c in STM-256/OC-768
33400   173 0   AU-4-4c/STS-12c in STM-256/OC-768
34100   177 0   AU-4-4c/STS-12c in STM-256/OC-768
34200   181 0   AU-4-4c/STS-12c in STM-256/OC-768
34300   185 0   AU-4-4c/STS-12c in STM-256/OC-768
34400   189 0   AU-4-4c/STS-12c in STM-256/OC-768
41100   193 0   AU-4-4c/STS-12c in STM-256/OC-768
41200   197 0   AU-4-4c/STS-12c in STM-256/OC-768
41300   201 0   AU-4-4c/STS-12c in STM-256/OC-768
41400   205 0   AU-4-4c/STS-12c in STM-256/OC-768
42100   209 0   AU-4-4c/STS-12c in STM-256/OC-768
42200   213 0   AU-4-4c/STS-12c in STM-256/OC-768
42300   217 0   AU-4-4c/STS-12c in STM-256/OC-768
42400   221 0   AU-4-4c/STS-12c in STM-256/OC-768
43100   225 0   AU-4-4c/STS-12c in STM-256/OC-768
43200   229 0   AU-4-4c/STS-12c in STM-256/OC-768
43300   233 0   AU-4-4c/STS-12c in STM-256/OC-768
43400   237 0   AU-4-4c/STS-12c in STM-256/OC-768
44100   241 0   AU-4-4c/STS-12c in STM-256/OC-768
44200   245 0   AU-4-4c/STS-12c in STM-256/OC-768
44300   249 0   AU-4-4c/STS-12c in STM-256/OC-768
44400   253 0   AU-4-4c/STS-12c in STM-256/OC-768

11110     1 1   AU-4/STS-3c in STM-256/OC-768
11120     2 1   AU-4/STS-3c in STM-256/OC-768
11130     3 1   AU-4/STS-3c in STM-256/OC-768
11140     4 1   AU-4/STS-3c in STM-256/OC-768
11210     5 1   AU-4/STS-3c in STM-256/OC-768
11220     6 1   AU-4/STS-3c in STM-256/OC-768
11220     7 1   AU-4/STS-3c in STM-256/OC-768
11220     8 1   AU-4/STS-3c in STM-256/OC-768
11310     9 1   AU-4/STS-3c in STM-256/OC-768
:
11410    13 1   AU-4/STS-3c in STM-256/OC-768
:
12110    17 1   AU-4/STS-3c in STM-256/OC-768
:
12210    21 1   AU-4/STS-3c in STM-256/OC-768
:
12310    25 1   AU-4/STS-3c in STM-256/OC-768
:
12410    29 1   AU-4/STS-3c in STM-256/OC-768
:
13110    33 1   AU-4/STS-3c in STM-256/OC-768
:
13210    37 1   AU-4/STS-3c in STM-256/OC-768
:
13310    41 1   AU-4/STS-3c in STM-256/OC-768
:
13410    45 1   AU-4/STS-3c in STM-256/OC-768
:
14110    49 1   AU-4/STS-3c in STM-256/OC-768
:
14210    53 1   AU-4/STS-3c in STM-256/OC-768
:
14310    57 1   AU-4/STS-3c in STM-256/OC-768
:
14410    61 1   AU-4/STS-3c in STM-256/OC-768
:
21110    65 1   AU-4/STS-3c in STM-256/OC-768
:
21210    69 1   AU-4/STS-3c in STM-256/OC-768
:
21310    73 1   AU-4/STS-3c in STM-256/OC-768
:
21410    77 1   AU-4/STS-3c in STM-256/OC-768
:
22110    81 1   AU-4/STS-3c in STM-256/OC-768
:
22210    85 1   AU-4/STS-3c in STM-256/OC-768
:
22310    89 1   AU-4/STS-3c in STM-256/OC-768
:
22410    93 1   AU-4/STS-3c in STM-256/OC-768
:
23110    97 1   AU-4/STS-3c in STM-256/OC-768
:
23210   101 1   AU-4/STS-3c in STM-256/OC-768
:
23310   105 1   AU-4/STS-3c in STM-256/OC-768
:
23410   109 1   AU-4/STS-3c in STM-256/OC-768
:
24110   113 1   AU-4/STS-3c in STM-256/OC-768
:
24210   117 1   AU-4/STS-3c in STM-256/OC-768
:
24310   121 1   AU-4/STS-3c in STM-256/OC-768
:
24410   125 1   AU-4/STS-3c in STM-256/OC-768
:
31110   129 1   AU-4/STS-3c in STM-256/OC-768
:
31210   133 1   AU-4/STS-3c in STM-256/OC-768
:
31310   137 1   AU-4/STS-3c in STM-256/OC-768
:
31410   141 1   AU-4/STS-3c in STM-256/OC-768
:
32110   145 1   AU-4/STS-3c in STM-256/OC-768
:
32210   149 1   AU-4/STS-3c in STM-256/OC-768
:
32310   153 1   AU-4/STS-3c in STM-256/OC-768
:
32410   157 1   AU-4/STS-3c in STM-256/OC-768
:
33110   161 1   AU-4/STS-3c in STM-256/OC-768
:
33210   165 1   AU-4/STS-3c in STM-256/OC-768
:
33310   169 1   AU-4/STS-3c in STM-256/OC-768
:
33410   173 1   AU-4/STS-3c in STM-256/OC-768
:
34110   177 1   AU-4/STS-3c in STM-256/OC-768
:
34210   181 1   AU-4/STS-3c in STM-256/OC-768
:
34310   185 1   AU-4/STS-3c in STM-256/OC-768
:
34410   189 1   AU-4/STS-3c in STM-256/OC-768
:
41110   193 1   AU-4/STS-3c in STM-256/OC-768
:
41210   197 1   AU-4/STS-3c in STM-256/OC-768
:
41310   201 1   AU-4/STS-3c in STM-256/OC-768
:
41410   205 1   AU-4/STS-3c in STM-256/OC-768
:
42110   209 1   AU-4/STS-3c in STM-256/OC-768
:
42210   213 1   AU-4/STS-3c in STM-256/OC-768
:
42310   217 1   AU-4/STS-3c in STM-256/OC-768
:
42410   221 1   AU-4/STS-3c in STM-256/OC-768
:
43110   225 1   AU-4/STS-3c in STM-256/OC-768
:
43210   229 1   AU-4/STS-3c in STM-256/OC-768
:
43310   233 1   AU-4/STS-3c in STM-256/OC-768
:
43410   237 1   AU-4/STS-3c in STM-256/OC-768
:
44110   241 1   AU-4/STS-3c in STM-256/OC-768
:
44210   245 1   AU-4/STS-3c in STM-256/OC-768
:
44310   249 1   AU-4/STS-3c in STM-256/OC-768
:
44410   253 1   AU-4/STS-3c in STM-256/OC-768
44420   254 1   AU-4/STS-3c in STM-256/OC-768
44430   255 1   AU-4/STS-3c in STM-256/OC-768
44440   256 1   AU-4/STS-3c in STM-256/OC-768

11111     1 2   AU-3/STS-1 in STM-256/OC-768
11112     1 3   AU-3/STS-1 in STM-256/OC-768
11113     1 4   AU-3/STS-1 in STM-256/OC-768
11121     2 2   AU-3/STS-1 in STM-256/OC-768
11122     2 3   AU-3/STS-1 in STM-256/OC-768
11123     2 4   AU-3/STS-1 in STM-256/OC-768
:
11131     3 2   AU-3/STS-1 in STM-256/OC-768
:
11141     4 2   AU-3/STS-1 in STM-256/OC-768
:
11211     5 2   AU-3/STS-1 in STM-256/OC-768
:
11311     9 2   AU-3/STS-1 in STM-256/OC-768
:
11411    13 2   AU-3/STS-1 in STM-256/OC-768
:
12111    17 2   AU-3/STS-1 in STM-256/OC-768
:
12211    21 2   AU-3/STS-1 in STM-256/OC-768
:
12311    25 2   AU-3/STS-1 in STM-256/OC-768
:
12411    29 2   AU-3/STS-1 in STM-256/OC-768
:
13111    33 2   AU-3/STS-1 in STM-256/OC-768
:
13211    37 2   AU-3/STS-1 in STM-256/OC-768
:
13311    41 2   AU-3/STS-1 in STM-256/OC-768
:
13411    45 2   AU-3/STS-1 in STM-256/OC-768
:
14111    49 2   AU-3/STS-1 in STM-256/OC-768
:
14211    53 2   AU-3/STS-1 in STM-256/OC-768
:
14311    57 2   AU-3/STS-1 in STM-256/OC-768
:
14411    61 2   AU-3/STS-1 in STM-256/OC-768
:
21111    65 2   AU-3/STS-1 in STM-256/OC-768
:
21211    69 2   AU-3/STS-1 in STM-256/OC-768
:
21311    73 2   AU-3/STS-1 in STM-256/OC-768
:
21411    77 2   AU-3/STS-1 in STM-256/OC-768
:
22111    81 2   AU-3/STS-1 in STM-256/OC-768
:
22211    85 2   AU-3/STS-1 in STM-256/OC-768
:
22311    89 2   AU-3/STS-1 in STM-256/OC-768
:
22411    93 2   AU-3/STS-1 in STM-256/OC-768
:
23111    97 2   AU-3/STS-1 in STM-256/OC-768
:
23211   101 2   AU-3/STS-1 in STM-256/OC-768
:
23311   105 2   AU-3/STS-1 in STM-256/OC-768
:
23411   109 2   AU-3/STS-1 in STM-256/OC-768
:
24111   113 2   AU-3/STS-1 in STM-256/OC-768
:
24211   117 2   AU-3/STS-1 in STM-256/OC-768
:
24311   121 2   AU-3/STS-1 in STM-256/OC-768
:
24411   125 2   AU-3/STS-1 in STM-256/OC-768
:
31111   129 2   AU-3/STS-1 in STM-256/OC-768
:
31211   133 2   AU-3/STS-1 in STM-256/OC-768
:
31311   137 2   AU-3/STS-1 in STM-256/OC-768
:
31411   141 2   AU-3/STS-1 in STM-256/OC-768
:
32111   145 2   AU-3/STS-1 in STM-256/OC-768
:
32211   149 2   AU-3/STS-1 in STM-256/OC-768
:
32311   153 2   AU-3/STS-1 in STM-256/OC-768
:
32411   157 2   AU-3/STS-1 in STM-256/OC-768
:
33111   161 2   AU-3/STS-1 in STM-256/OC-768
:
33211   165 2   AU-3/STS-1 in STM-256/OC-768
:
33311   169 2   AU-3/STS-1 in STM-256/OC-768
:
33411   173 2   AU-3/STS-1 in STM-256/OC-768
:
34111   177 2   AU-3/STS-1 in STM-256/OC-768
:
34211   181 2   AU-3/STS-1 in STM-256/OC-768
:
34311   185 2   AU-3/STS-1 in STM-256/OC-768
:
34411   189 2   AU-3/STS-1 in STM-256/OC-768
:
41111   193 2   AU-3/STS-1 in STM-256/OC-768
:
41211   197 2   AU-3/STS-1 in STM-256/OC-768
:
41311   211 2   AU-3/STS-1 in STM-256/OC-768
:
41411   215 2   AU-3/STS-1 in STM-256/OC-768
:
42111   219 2   AU-3/STS-1 in STM-256/OC-768
:
42211   213 2   AU-3/STS-1 in STM-256/OC-768
:
42311   217 2   AU-3/STS-1 in STM-256/OC-768
:
42411   221 2   AU-3/STS-1 in STM-256/OC-768
:
43111   225 2   AU-3/STS-1 in STM-256/OC-768
:
43211   229 2   AU-3/STS-1 in STM-256/OC-768
:
43311   233 2   AU-3/STS-1 in STM-256/OC-768
:
43411   237 2   AU-3/STS-1 in STM-256/OC-768
:
44111   241 2   AU-3/STS-1 in STM-256/OC-768
:
44211   245 2   AU-3/STS-1 in STM-256/OC-768
:
44311   249 2   AU-3/STS-1 in STM-256/OC-768
:
44411   253 2   AU-3/STS-1 in STM-256/OC-768
:
44421   254 2   AU-3/STS-1 in STM-256/OC-768
:
44431   255 2   AU-3/STS-1 in STM-256/OC-768
:
44441   256 2   AU-3/STS-1 in STM-256/OC-768
44442   256 3   AU-3/STS-1 in STM-256/OC-768
44443   256 4   AU-3/STS-1 in STM-256/OC-768

G.707
DCBA      S U   Signal Type
=========================================
0000      1 0   AU-4-64c/STS-192c in STM-64/OC-192

1000      1 0   AU-4-16c/STS-48c in STM-64/OC-192
2000     17 0   AU-4-16c/STS-48c in STM-64/OC-192
3000     33 0   AU-4-16c/STS-48c in STM-64/OC-192
4000     49 0   AU-4-16c/STS-48c in STM-64/OC-192

1100      1 0   AU-4-4c/STS-12c in STM-64/OC-192
1200      5 0   AU-4-4c/STS-12c in STM-64/OC-192
1300      9 0   AU-4-4c/STS-12c in STM-64/OC-192
1400     13 0   AU-4-4c/STS-12c in STM-64/OC-192
2100     17 0   AU-4-4c/STS-12c in STM-64/OC-192
2200     21 0   AU-4-4c/STS-12c in STM-64/OC-192
2300     25 0   AU-4-4c/STS-12c in STM-64/OC-192
2400     29 0   AU-4-4c/STS-12c in STM-64/OC-192
3100     33 0   AU-4-4c/STS-12c in STM-64/OC-192
3200     37 0   AU-4-4c/STS-12c in STM-64/OC-192
3300     41 0   AU-4-4c/STS-12c in STM-64/OC-192
3400     45 0   AU-4-4c/STS-12c in STM-64/OC-192
4100     49 0   AU-4-4c/STS-12c in STM-64/OC-192
4200     53 0   AU-4-4c/STS-12c in STM-64/OC-192
4300     57 0   AU-4-4c/STS-12c in STM-64/OC-192
4400     61 0   AU-4-4c/STS-12c in STM-64/OC-192

1110      1 1   AU-4/STS-3c in STM-64/OC-192
1120      2 1   AU-4/STS-3c in STM-64/OC-192
1130      3 1   AU-4/STS-3c in STM-64/OC-192
1140      4 1   AU-4/STS-3c in STM-64/OC-192
1210      5 1   AU-4/STS-3c in STM-64/OC-192
1220      6 1   AU-4/STS-3c in STM-64/OC-192
1220      7 1   AU-4/STS-3c in STM-64/OC-192
1220      8 1   AU-4/STS-3c in STM-64/OC-192
1310      9 1   AU-4/STS-3c in STM-64/OC-192
:
1410     13 1   AU-4/STS-3c in STM-64/OC-192
:
2110     17 1   AU-4/STS-3c in STM-64/OC-192
:
2210     21 1   AU-4/STS-3c in STM-64/OC-192
:
2310     25 1   AU-4/STS-3c in STM-64/OC-192
:
2410     29 1   AU-4/STS-3c in STM-64/OC-192
:
3110     33 1   AU-4/STS-3c in STM-64/OC-192
:
3210     37 1   AU-4/STS-3c in STM-64/OC-192
:
3310     41 1   AU-4/STS-3c in STM-64/OC-192
:
3410     45 1   AU-4/STS-3c in STM-64/OC-192
:
4110     49 1   AU-4/STS-3c in STM-64/OC-192
:
4210     53 1   AU-4/STS-3c in STM-64/OC-192
:
4310     57 1   AU-4/STS-3c in STM-64/OC-192
:
4410     61 1   AU-4/STS-3c in STM-64/OC-192
4420     62 1   AU-4/STS-3c in STM-64/OC-192
4430     63 1   AU-4/STS-3c in STM-64/OC-192
4440     64 1   AU-4/STS-3c in STM-64/OC-192

1111      1 2   AU-3/STS-1 in STM-64/OC-192
1112      1 3   AU-3/STS-1 in STM-64/OC-192
1113      1 4   AU-3/STS-1 in STM-64/OC-192
1121      2 2   AU-3/STS-1 in STM-64/OC-192
1122      2 3   AU-3/STS-1 in STM-64/OC-192
1123      2 4   AU-3/STS-1 in STM-64/OC-192
:
1131      3 2   AU-3/STS-1 in STM-64/OC-192
:
1141      4 2   AU-3/STS-1 in STM-64/OC-192
:
1211      5 2   AU-3/STS-1 in STM-64/OC-192
:
1311      9 2   AU-3/STS-1 in STM-64/OC-192
:
1411     13 2   AU-3/STS-1 in STM-64/OC-192
:
2111     17 2   AU-3/STS-1 in STM-64/OC-192
:
2211     21 2   AU-3/STS-1 in STM-64/OC-192
:
2311     25 2   AU-3/STS-1 in STM-64/OC-192
:
2411     29 2   AU-3/STS-1 in STM-64/OC-192
:
3111     33 2   AU-3/STS-1 in STM-64/OC-192
:
3211     37 2   AU-3/STS-1 in STM-64/OC-192
:
3311     41 2   AU-3/STS-1 in STM-64/OC-192
:
3411     45 2   AU-3/STS-1 in STM-64/OC-192
:
4111     49 2   AU-3/STS-1 in STM-64/OC-192
:
4211     53 2   AU-3/STS-1 in STM-64/OC-192
:
4311     57 2   AU-3/STS-1 in STM-64/OC-192
:
4411     61 2   AU-3/STS-1 in STM-64/OC-192
:
4441     63 2   AU-3/STS-1 in STM-64/OC-192
4442     64 3   AU-3/STS-1 in STM-64/OC-192
4443     65 4   AU-3/STS-1 in STM-64/OC-192

G.707
CBA       S U   Signal Type
=========================================
000       1 0   AU-4-16c/STS-48c in STM-16/OC-48

100       1 0   AU-4-4c/STS-12c in STM-16/OC-48
200       5 0   AU-4-4c/STS-12c in STM-16/OC-48
300       9 0   AU-4-4c/STS-12c in STM-16/OC-48
400      13 0   AU-4-4c/STS-12c in STM-16/OC-48

110       1 1   AU-4/STS-3c in STM-16/OC-48
120       2 1   AU-4/STS-3c in STM-16/OC-48
130       3 1   AU-4/STS-3c in STM-16/OC-48
140       4 1   AU-4/STS-3c in STM-16/OC-48
210       5 1   AU-4/STS-3c in STM-16/OC-48
220       6 1   AU-4/STS-3c in STM-16/OC-48
220       7 1   AU-4/STS-3c in STM-16/OC-48
220       8 1   AU-4/STS-3c in STM-16/OC-48
310       9 1   AU-4/STS-3c in STM-16/OC-48
320      10 1   AU-4/STS-3c in STM-16/OC-48
330      11 1   AU-4/STS-3c in STM-16/OC-48
340      12 1   AU-4/STS-3c in STM-16/OC-48
410      13 1   AU-4/STS-3c in STM-16/OC-48
420      14 1   AU-4/STS-3c in STM-16/OC-48
430      15 1   AU-4/STS-3c in STM-16/OC-48
440      16 1   AU-4/STS-3c in STM-16/OC-48

111       1 2   AU-3/STS-1 in STM-16/OC-48
112       1 3   AU-3/STS-1 in STM-16/OC-48
113       1 4   AU-3/STS-1 in STM-16/OC-48
121       2 2   AU-3/STS-1 in STM-16/OC-48
122       2 3   AU-3/STS-1 in STM-16/OC-48
123       2 4   AU-3/STS-1 in STM-16/OC-48
131       3 2   AU-3/STS-1 in STM-16/OC-48
132       3 3   AU-3/STS-1 in STM-16/OC-48
133       3 4   AU-3/STS-1 in STM-16/OC-48
141       4 2   AU-3/STS-1 in STM-16/OC-48
:
211       5 2   AU-3/STS-1 in STM-16/OC-48
:
311       9 2   AU-3/STS-1 in STM-16/OC-48
:
411      13 2   AU-3/STS-1 in STM-16/OC-48
:
441      16 2   AU-3/STS-1 in STM-16/OC-48
442      16 3   AU-3/STS-1 in STM-16/OC-48
443      16 4   AU-3/STS-1 in STM-16/OC-48

G.707
BA        S U   Signal Type
=========================================
00        1 0   AU-4-4c/STS-12c in STM-4/OC-12

10        1 1   AU-4/STS-3c in STM-4/OC-12
20        2 1   AU-4/STS-3c in STM-4/OC-12
30        3 1   AU-4/STS-3c in STM-4/OC-12
40        4 1   AU-4/STS-3c in STM-4/OC-12

11        1 2   AU-3/STS-1 in STM-4/OC-12
12        1 3   AU-3/STS-1 in STM-4/OC-12
13        1 4   AU-3/STS-1 in STM-4/OC-12
21        2 2   AU-3/STS-1 in STM-4/OC-12
22        2 3   AU-3/STS-1 in STM-4/OC-12
23        2 4   AU-3/STS-1 in STM-4/OC-12
31        3 2   AU-3/STS-1 in STM-4/OC-12
32        3 3   AU-3/STS-1 in STM-4/OC-12
33        3 4   AU-3/STS-1 in STM-4/OC-12
41        4 2   AU-3/STS-1 in STM-4/OC-12
42        4 3   AU-3/STS-1 in STM-4/OC-12
43        4 4   AU-3/STS-1 in STM-4/OC-12

G.707
A         S U   Signal Type
=========================================
0         1 1   AU-4/STS-3c in STM-1/OC-3

1         1 2   AU-3/STS-1 in STM-1/OC-3
2         1 3   AU-3/STS-1 in STM-1/OC-3
3         1 4   AU-3/STS-1 in STM-1/OC-3

--------------796300C60EC73EF388C167C9
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------796300C60EC73EF388C167C9--

Delivery-date: Mon, 02 Jul 2001 07:39:34 -0700
Date: Mon, 02 Jul 2001 10:35:11 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Eric Gray <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Eric,

I was about to keep quite... Because of recent discussions, here is my comments
to your previous example in-lines. 

I am OK with current suggested label, label set etc. However I want to figure
out the real application in circuit switching network and please help me about
it. Thanks a lot.

[snipped]
> > >
> >
> > Would you please give me an example that what I said is not true?
> 
> 
> Local significance - not every switch in an optical domain is necessarily
> capable of performing the same kind of "optical switching".  This does not
> mean that they cannot interoperate - but it does mean that they may not
> interoperate in the way that you expect.  

Can you give me an "example", I mean a real one? Please specify what type of
circuit switches you are talking about, what's their functions etc. I have heard
too many hyperthetical applications that don't exist at all.

> Under these circumstances, the
> choice of "label" may have greater than local significance.  

Then that's routing constrains and you can specify certain routing constrains at
the signaling time. Label itself only has local significance.

> Moreover, you
> cannot end up lambda switching two light beams of the same color into
> a single piece of glass.

If you don't have any type of multiplexing mechanisms. It doesn't matter they
are the same color or not.

Otherwise, indeed you can, and it depends on your multiplexing and modulation
mechanisms (. You are probably only talking about wavelength multiplexing. For
that specific case, you may be right.

Sorry, this is just a side topic.

> 
> Upstream/Downstream indifference of choice - true in optical networks (at
> least "Normally"), but not particularly relevant.  One or the other MUST
> have the final say and the model to-date has been that the final word is
> given by the downstream.  Given that there MAY BE a scenario in which one
> or the other has less than complete knowledge, it is necessary to have a
> negotiation/arbitration mechanism.
> 

I think the upstream/downstream nodes are symmetric in circuit switching
network. I am looking an example to show me that your "MAY BE" is true.

BTW, I have concern about the definition of upstream/downstream. Their
definitions in RFC 3031 need modifications for GMPLS.

Thanks,

Yangguang

Delivery-date: Mon, 02 Jul 2001 07:06:00 -0700
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: GMPLS Doubt
Date: Mon, 2 Jul 2001 10:04:43 -0400 

Agree with Maarten to support as a single type.

Also, the versions of the standards should not be differentiated. I had
posted a previous mail questioning the need for this to the exploder. The
latest versions provide for interworking with legacy equipment. E.g.
T1.105-2000 defines J0 as 1-byte or 16-byte and provides for interworking
with equipment not supporting J0. Defining a label for the 1995 version and
the 2000 version does not add any descriptive value and only will confuse
interworking. As Maarten notes, these differences need to be treated in a
generic manner.

Deborah Brungard
AT&T

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 02, 2001 7:29 AM
To: manoj juneja
Cc: [email-masked]
Subject: Re: GMPLS Doubt

Manoj,

manoj juneja wrote:
> 
> Hi All,
>         In the draft draft-ietf-mpls-generalized-signalling-04.txt,
> different values of LSP encoding type are defined. What all values
> of LSP encoding type are currently supported by GMPLS ?
> 
> The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH
> etc.

More work is to be done here it seems... It should be possible to
request e.g. a DS1 or DS3 connection through a SDH/SONET network. When
crossing the UNI, the DS1/DS3 connection request is converted into a
VT1.5/STS1 connection request within the SDH/SONET network. So perhaps
only the UNI format is required.

> I think the only supported values of LSP encoding type are :
> 
> SDH ITU-T G.707 1996
> SONET ANSI T1.105-1995
> SDH ITU-T G.707 2000
> SONET ANSI T1.105-2000

SDH and SONET can be treated as a single type, and this is the direction
in the development of G.ason (ITU-T). Let's make sure that GMPLS does
follow this; otherwise confusion will be the result.

Note that a number of the presumed differences between SONET and SDH may
also be present between SDH and SDH (e.g. 16/64 byte trace identifiers).
And similarly, some of the presumed SONET/SDH differences may also be
present between SONET and SONET (e.g. PDI, E-RDI).

The interworking issues associated with these "differences" must thus be
treated in a generic SONET/SDH independent manner.

Regards,

Maarten

> Fiber
> Lambda
> Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ]
> 
> Please comment.
> 
> Regards,
> manoj.
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 02 Jul 2001 06:44:15 -0700
Date: Mon, 02 Jul 2001 09:44:00 -0400
From: Eric Gray <[email-masked]>
To: Suresh Katukam <[email-masked]>
Cc: [email-masked]
Subject: Re: Label Set and Suggested Label

Suresh,

    Unfortunately, the current wording is:

"There are four cases where a Label Set is useful in the optical domain."

It is arguable that your examples are more properly in the TDM  domain,
but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not
seem to leave much room for generalizing the label set in this way.  It
should probably say either that these are examples that apply to the
optical domain (other uses may exist for other domains) or - better -
still it should simply state these as a few examples and leave it at that.

    There is nothing to be gained by guessing what the authors meant -
they must make it clear.

--
Eric Gray

You wrote:

> Manoj,
>
> >         In the GMPLS drafts, it is mentioned that the use of label set
> > is in the following cases :
> >
> >            a) End equipment is only capable of transmitting and
> >               receiving on a small set of wavelengths.
> >            b) There are sequence of interfaces which can't support
> >               wavelength conversion.
> >            c) It is desireable to limit the amount of wavelength
> >               conversion to reduce the distortion on the optical
> >               signals.
> >            d) Two ends of a link support different sets of wavelengths.
> >
> > All the above four points are valid only in case LSP encoding type is
> > lambda. Does this mean if a label set is received in cases where LSP
> > encoding type is other than Lambda, it should be ignored or considered
> > protocol error ?
>
> I am not sure whether it is the intention of GMPLS authors to list
> all possible scenerios under which a label set is used. There are
> other scenerios under which label set can be used. In TDM, for example,
> one may want to use same time slot (for BLSRs) assigned along the
> entire BLSR segment. In such a scenerio, BLSR headend lists all available
> labels and forwards the PATH message. Each node in BLSR knows what
> label to use when it receives a RESV message.
>
> There may be other reasons too. In anycase, you should not consider
> that to be a protocol error.
>
> Thanks,
> Suresh
> >
> > What about the suggested Label ? Is it also defined to take care of
> > specific LSP encoding type ?
> >
> > Please Clarify.
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 02 Jul 2001 06:42:25 -0700
Date: Mon, 02 Jul 2001 09:45:04 -0400
To: Eric Gray <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: lmp mib
Cc: [email-masked], [email-masked]

--=====================_3390825==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>    Does it make sense that we would ever need a negative
>enumeration?

         I don't think so. Let me know if you do.

         --Tom

>--
>Eric Gray
>
>You wrote:
>>
>>         I believe that the correct value should be
>>INTEGER due to it being an enumeration. We will
>>fix this in the next revision.
>>
>>         --Tom
>>
>>
>>
>>>In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , 
>>>lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and 
>>>when it is
>>>
>>>defined it is given as INTEGER type.  which one is correct?
>>>
>>>thanks
>>>regards
>>>bhaskara

--=====================_3390825==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<blockquote type=cite cite>&nbsp;&nbsp; Does it make sense that we would
ever need a negative <br>
enumeration? </blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I don't
think so. Let me know if you do.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>-- <br>
Eric Gray <br>
<br>
You wrote: <br>
<blockquote type=cite cite>&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">I
believe that the correct value should be</font> <br>
<font face="Arial, Helvetica">INTEGER due to it being an enumeration. We
will</font> <br>
<font face="Arial, Helvetica">fix this in the next revision.</font> 
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">--Tom</font> <br>
&nbsp; <br>
&nbsp; <br>
&nbsp; <br>
<blockquote type=cite cite><font face="Arial, Helvetica" size=2>In lmpTeLinkTable of&nbsp; &quot;draft-dubuc-lmp-mib-02.txt&quot; , lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and when it is</font> <br>
<br>
<font face="Arial, Helvetica" size=2>defined it is given as INTEGER type.&nbsp; which one is correct?</font> <br>
<br>
<font face="Arial, Helvetica" size=2>thanks</font> <br>
<font face="Arial, Helvetica" size=2>regards</font> <br>
<font face="Arial, Helvetica" size=2>bhaskara</font></blockquote></blockquote></blockquote></html>

--=====================_3390825==_.ALT--

Delivery-date: Mon, 02 Jul 2001 06:30:30 -0700
Date: Mon, 02 Jul 2001 09:29:29 -0400
From: Eric Gray <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: lmp mib

--------------0F7430FDF298EA1B78D85C6B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

    Does it make sense that we would ever need a negative
enumeration?

--
Eric Gray

You wrote:

>
> I believe that the correct value should be
> INTEGER due to it being an enumeration. We will
> fix this in the next revision.
>
> --Tom
>
>
>
>
>> In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType
>> SYNTAX is given as uint32 in table entry index and when it is
>>
>> defined it is given as INTEGER type.  which one is correct?
>>
>> thanks
>> regards
>> bhaskara
>

--------------0F7430FDF298EA1B78D85C6B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tom,
<p>&nbsp;&nbsp;&nbsp; Does it make sense that we would ever need a negative
<br>enumeration?
<p>--
<br>Eric Gray
<p>You wrote:
<blockquote TYPE=CITE>&nbsp;
<br><x-tab></x-tab><font face="Arial, Helvetica">I believe that the correct
value should be</font>
<br><font face="Arial, Helvetica">INTEGER due to it being an enumeration.
We will</font>
<br><font face="Arial, Helvetica">fix this in the next revision.</font>
<p><x-tab></x-tab><font face="Arial, Helvetica">--Tom</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote type=cite cite><font face="Arial, Helvetica"><font size=-1>In
lmpTeLinkTable of&nbsp; "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType
SYNTAX is given as uint32 in table entry index and when it is</font></font>
<p><font face="Arial, Helvetica"><font size=-1>defined it is given as INTEGER
type.&nbsp; which one is correct?</font></font>
<p><font face="Arial, Helvetica"><font size=-1>thanks</font></font>
<br><font face="Arial, Helvetica"><font size=-1>regards</font></font>
<br><font face="Arial, Helvetica"><font size=-1>bhaskara</font></font></blockquote>
</blockquote>
</html>

--------------0F7430FDF298EA1B78D85C6B--

Delivery-date: Mon, 02 Jul 2001 04:30:46 -0700
Cc: [email-masked]
Date: Mon, 02 Jul 2001 13:28:46 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: GMPLS Doubt

This is a multi-part message in MIME format.
--------------3F984BDEC16F0909332410FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

manoj juneja wrote:
> 
> Hi All,
>         In the draft draft-ietf-mpls-generalized-signalling-04.txt,
> different values of LSP encoding type are defined. What all values
> of LSP encoding type are currently supported by GMPLS ?
> 
> The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH
> etc.

More work is to be done here it seems... It should be possible to
request e.g. a DS1 or DS3 connection through a SDH/SONET network. When
crossing the UNI, the DS1/DS3 connection request is converted into a
VT1.5/STS1 connection request within the SDH/SONET network. So perhaps
only the UNI format is required.

> 
> I think the only supported values of LSP encoding type are :
> 
> SDH ITU-T G.707 1996
> SONET ANSI T1.105-1995
> SDH ITU-T G.707 2000
> SONET ANSI T1.105-2000

SDH and SONET can be treated as a single type, and this is the direction
in the development of G.ason (ITU-T). Let's make sure that GMPLS does
follow this; otherwise confusion will be the result.

Note that a number of the presumed differences between SONET and SDH may
also be present between SDH and SDH (e.g. 16/64 byte trace identifiers).
And similarly, some of the presumed SONET/SDH differences may also be
present between SONET and SONET (e.g. PDI, E-RDI).

The interworking issues associated with these "differences" must thus be
treated in a generic SONET/SDH independent manner.

Regards,

Maarten

> Fiber
> Lambda
> Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ]
> 
> Please comment.
> 
> Regards,
> manoj.
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------3F984BDEC16F0909332410FA
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3F984BDEC16F0909332410FA--

Delivery-date: Mon, 02 Jul 2001 00:50:03 -0700
Cc: "'manoj juneja'" <[email-masked]>, [email-masked]
Date: Mon, 02 Jul 2001 09:49:25 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: {SUKLM} numbering scheme

This is a multi-part message in MIME format.
--------------EFE993FBDD9E9E60453FD418
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

I would like to propose to include the conversion scheme (formula and/or
table) in an appendix to GMPLS SONET/SDH extension document. Might be
helpful to readers of both G.707 and GMPLS. Otherwise I fear people keep
asking for it.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Manoj,
> 
> The label is the same of course.
> 
> The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a
> small bug coming from an old version. That should be removed by Lou. We
> should have only one SDH LSP encoding type value for SDH (same for SONET).
> 
> Lou: thanks to correct it.
> 
> For the conversion table, Maarten should still have it.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 8:28 PM
> To: [email-masked]
> Subject: {SUKLM} numbering scheme
> 
> Hi All,
>           I have a doubt regarding {SUKLM} numbering scheme. If I
> allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
> different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
> ITU-T G.707 2000 ?
> 
> Eric, on the ipo u and marteen once exchanged the conversion table for
> EDCBA and SU, If that table is correct, can u please tell me the
> formula from which u derived that table ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------EFE993FBDD9E9E60453FD418
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------EFE993FBDD9E9E60453FD418--

Delivery-date: Mon, 02 Jul 2001 00:46:17 -0700
Cc: [email-masked]
Date: Mon, 02 Jul 2001 09:44:12 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LSP Encoding Type

This is a multi-part message in MIME format.
--------------DE3989A67A8F0498A3DB6ADF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

The G.707 1996 and 2000 indications are artificial indications not
supported by ITU-T. SDH equipment is not designed to meet either 1996 or
2000 versions of G.707. IETF better drops this from GMPLS as it will
only cause confusion in my opnion.

For your implementation, my recommendation is to simply ignore this.

Concerning AUG-X support, G.707 doesn't support it and neither does
T1.105. It's a proprietary extension of SDH/SONET.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi All,
>          If a particular implementation supports LSP encoding type as
> SDH ITU-T G-707 1996, Does this mean it can't support signals like
> AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------DE3989A67A8F0498A3DB6ADF
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DE3989A67A8F0498A3DB6ADF--

Delivery-date: Sun, 01 Jul 2001 07:14:04 -0700
Date: Sun, 01 Jul 2001 10:11:27 -0400
To: [email-masked], [email-masked], [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: lmp mib

--=====================_2930684==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

         I believe that the correct value should be
INTEGER due to it being an enumeration. We will
fix this in the next revision.

         --Tom

>In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType 
>SYNTAX is given as uint32 in table entry index and when it is
>
>defined it is given as INTEGER type.  which one is correct?
>
>thanks
>regards
>bhaskara

--=====================_2930684==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Arial, Helvetica"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I believe
that the correct value should be <br>
INTEGER due to it being an enumeration. We will<br>
fix this in the next revision.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
</font><blockquote type=cite cite><font face="Arial, Helvetica" size=2>In
lmpTeLinkTable of&nbsp; &quot;draft-dubuc-lmp-mib-02.txt&quot; ,
lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and
when it is<br>
</font><br>
<font face="Arial, Helvetica" size=2>defined it is given as INTEGER
type.&nbsp; which one is correct?</font> <br>
<br>
<font face="Arial, Helvetica" size=2>thanks</font> <br>
<font face="Arial, Helvetica" size=2>regards</font> <br>
<font face="Arial, Helvetica" size=2>bhaskara</font>
</blockquote></html>

--=====================_2930684==_.ALT--