Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Aug 2001 04:05:44 -0700 Message-ID: From: Heiles Juergen To: "'Silman Lionel'" , Heiles Juergen , "'Karmakar, Soumen'" , "'ccamp@ops.ietf.org'" Subject: RE: SDH hierarchy Date: Thu, 30 Aug 2001 13:02:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13143.40A99530" 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_01C13143.40A99530 Content-Type: text/plain; charset="iso-8859-1" Does anyone know of any publicly available documents which describe the properties of the referenced proprietary solutions? If so, would you please provide pointers. Am I correct in thinking that this is what is called "Transparency" in draft-ietf-ccamp-gmpls-sonet-sdh-01.txt? It is one of many implementations. It has its drawbacks as it is only transparent for some overhead and not transparent for the timing. Other implementations with better transparency are direct transport over WDM or mapping into the ODU of a OTN system. Juergen Can you point to any further material beyond appendix 5 of the draft which explains for what transparency is used and what types of transparency are required for what applications? Lionel Silman Enavis Networks > -----Original Message----- > From: Heiles Juergen [ mailto:Juergen.Heiles@icn.siemens.de ] > Sent: Thursday, August 30, 2001 9:46 AM > To: 'Karmakar, Soumen'; 'ccamp@ops.ietf.org' > Subject: RE: SDH hierarchy > > > > Soumen, > > a standard STM-256 doesn't support a STM-64, it supports the > VC-3/4 that are transported within the STM-64. This means > that the STM-64 section overhead is terminated and only the > VC-3/4 are passed to the STM-256. The STM-256 adds its own > section overhead. > I know of proprietary solutions that also allow to transport > some of the STM-64 section overhead over the STM-256. > > > Juergen > > > -----Original Message----- > > From: Karmakar, Soumen [ mailto:soumen@trillium.com ] > > Sent: Thursday, August 30, 2001 1:19 AM > > To: 'ccamp@ops.ietf.org' > > Subject: SDH hierarchy > > > > > > Hello, > > Can a STM 64 signal be supported on the STM 256 link ? What > > would be the > > case if the link supports / not support transparency ? > > I would appreciate if someone throws light on it. > > Thanks > > Soumen > > > > > > > > > ------_=_NextPart_001_01C13143.40A99530 Content-Type: text/html; charset="iso-8859-1" RE: SDH hierarchy
 

Does anyone know of any publicly available documents which describe the properties of the referenced proprietary solutions? If so, would you please provide pointers.

Am I correct in thinking that this is what is called "Transparency" in draft-ietf-ccamp-gmpls-sonet-sdh-01.txt?  

It is one of many implementations. It has its drawbacks as it is only transparent for some overhead and not transparent for the timing. Other implementations with better transparency are direct transport over WDM or mapping into the ODU of a OTN system.

Juergen 

Can you point to any further material beyond appendix 5 of the draft which explains for what transparency is used and what types of transparency are required for what applications?

Lionel Silman
Enavis Networks

> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> Sent: Thursday, August 30, 2001 9:46 AM
> To: 'Karmakar, Soumen'; 'ccamp@ops.ietf.org'
> Subject: RE: SDH hierarchy
>
>
>
> Soumen,
>
> a standard STM-256 doesn't support a STM-64, it supports the
> VC-3/4 that are transported within the STM-64. This means
> that the STM-64 section overhead is terminated and only the
> VC-3/4 are passed to the STM-256. The STM-256 adds its own
> section overhead.
> I know of proprietary solutions that also allow to transport
> some of the STM-64 section overhead over the STM-256.
>
>
> Juergen
>
> > -----Original Message-----
> > From: Karmakar, Soumen [mailto:soumen@trillium.com]
> > Sent: Thursday, August 30, 2001 1:19 AM
> > To: 'ccamp@ops.ietf.org'
> > Subject: SDH hierarchy
> >
> >
> > Hello,
> > Can a  STM 64 signal be supported on the STM 256 link ? What
> > would be the
> > case if the link supports / not support transparency ?
> > I would appreciate if someone throws light on it.
> > Thanks
> > Soumen
> >
> >
> >
> >
>

------_=_NextPart_001_01C13143.40A99530-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Aug 2001 02:09:22 -0700 Message-ID: From: Silman Lionel To: "'Heiles Juergen'" , "'Karmakar, Soumen'" , "'ccamp@ops.ietf.org'" Subject: RE: SDH hierarchy Date: Thu, 30 Aug 2001 11:59:27 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13132.12E13740" 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_01C13132.12E13740 Content-Type: text/plain; charset="iso-8859-1" Does anyone know of any publicly available documents which describe the properties of the referenced proprietary solutions? If so, would you please provide pointers. Am I correct in thinking that this is what is called "Transparency" in draft-ietf-ccamp-gmpls-sonet-sdh-01.txt? Can you point to any further material beyond appendix 5 of the draft which explains for what transparency is used and what types of transparency are required for what applications? Lionel Silman Enavis Networks > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Thursday, August 30, 2001 9:46 AM > To: 'Karmakar, Soumen'; 'ccamp@ops.ietf.org' > Subject: RE: SDH hierarchy > > > > Soumen, > > a standard STM-256 doesn't support a STM-64, it supports the > VC-3/4 that are transported within the STM-64. This means > that the STM-64 section overhead is terminated and only the > VC-3/4 are passed to the STM-256. The STM-256 adds its own > section overhead. > I know of proprietary solutions that also allow to transport > some of the STM-64 section overhead over the STM-256. > > > Juergen > > > -----Original Message----- > > From: Karmakar, Soumen [mailto:soumen@trillium.com] > > Sent: Thursday, August 30, 2001 1:19 AM > > To: 'ccamp@ops.ietf.org' > > Subject: SDH hierarchy > > > > > > Hello, > > Can a STM 64 signal be supported on the STM 256 link ? What > > would be the > > case if the link supports / not support transparency ? > > I would appreciate if someone throws light on it. > > Thanks > > Soumen > > > > > > > > > ------_=_NextPart_001_01C13132.12E13740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SDH hierarchy

Does anyone know of any publicly available documents = which describe the properties of the referenced proprietary solutions? = If so, would you please provide pointers.

Am I correct in thinking that this is what is called = "Transparency" in = draft-ietf-ccamp-gmpls-sonet-sdh-01.txt?

Can you point to any further material beyond appendix = 5 of the draft which explains for what transparency is used and what = types of transparency are required for what applications?

Lionel Silman
Enavis Networks

> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.= siemens.de]
> Sent: Thursday, August 30, 2001 9:46 AM
> To: 'Karmakar, Soumen'; = 'ccamp@ops.ietf.org'
> Subject: RE: SDH hierarchy
>
>
>
> Soumen,
>
> a standard STM-256 doesn't support a STM-64, it = supports the
> VC-3/4 that are transported within the STM-64. = This means
> that the STM-64 section overhead is terminated = and only the
> VC-3/4 are passed to the STM-256. The STM-256 = adds its own
> section overhead.
> I know of proprietary solutions that also allow = to transport
> some of the STM-64 section overhead over the = STM-256.
>
>
> Juergen
>
> > -----Original Message-----
> > From: Karmakar, Soumen [mailto:soumen@trillium.com]
> > Sent: Thursday, August 30, 2001 1:19 = AM
> > To: 'ccamp@ops.ietf.org'
> > Subject: SDH hierarchy
> >
> >
> > Hello,
> > Can a  STM 64 signal be supported on = the STM 256 link ? What
> > would be the
> > case if the link supports / not support = transparency ?
> > I would appreciate if someone throws light = on it.
> > Thanks
> > Soumen
> >
> >
> >
> >
>

------_=_NextPart_001_01C13132.12E13740-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 23:49:26 -0700 Message-ID: From: Heiles Juergen To: "'Karmakar, Soumen'" , "'ccamp@ops.ietf.org'" Subject: RE: SDH hierarchy Date: Thu, 30 Aug 2001 08:46:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Soumen, a standard STM-256 doesn't support a STM-64, it supports the VC-3/4 that are transported within the STM-64. This means that the STM-64 section overhead is terminated and only the VC-3/4 are passed to the STM-256. The STM-256 adds its own section overhead. I know of proprietary solutions that also allow to transport some of the STM-64 section overhead over the STM-256. Juergen > -----Original Message----- > From: Karmakar, Soumen [mailto:soumen@trillium.com] > Sent: Thursday, August 30, 2001 1:19 AM > To: 'ccamp@ops.ietf.org' > Subject: SDH hierarchy > > > Hello, > Can a STM 64 signal be supported on the STM 256 link ? What > would be the > case if the link supports / not support transparency ? > I would appreciate if someone throws light on it. > Thanks > Soumen > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 16:22:20 -0700 Message-ID: From: "Karmakar, Soumen" To: "'ccamp@ops.ietf.org'" Subject: SDH hierarchy Date: Wed, 29 Aug 2001 16:19:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello, Can a STM 64 signal be supported on the STM 256 link ? What would be the case if the link supports / not support transparency ? I would appreciate if someone throws light on it. Thanks Soumen Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 08:31:21 -0700 Message-ID: From: John Drake To: 'Hang Liu' , 'Guangzhi Li' , Karthik Subramanian , "'eric.gray@sandburst.com'" Cc: John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Wed, 29 Aug 2001 08:29:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I think this is Guangzhi's #7, which he indicated could be derived from the existing text. (I wasn't sure that it could.) The correct resolution may be to indicate that a Resv always beats a Path and that for two Paths, the higher node always wins? ----Original Message----- From: Hang Liu [mailto:hliu@tellium.com] Sent: Wednesday, August 29, 2001 8:18 AM To: 'Guangzhi Li'; Karthik Subramanian; 'eric.gray@sandburst.com' Cc: Hang Liu; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Hi. One observation is When the I/O ports are paired, the contention between a uni-directional LSP and a bi-directional LSP is similar to the contention of two bi-directional LSPs. When a uni-directional LSP wants a label (I am not sure how common a uni-directional LSP is needed in the case of paired I/O), it actually contends that I/O pair with the bi-directional LSP. Hang -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Tuesday, August 28, 2001 7:45 PM To: Karthik Subramanian Cc: 'Hang Liu'; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Karthik: I understand your argument. But (1) It it legal not to suggest a label in PATH for a uni-directional LSP but to suggest a label for a bi-directional LSP especially I/O ports are paired. (2) If this is too weak, then assume another scenario: the PATH message of LSP A suggested a label but was rejected by N2 due to race condition of other LSPs, (such as a bi-directional LSP C from N2 to N1), then it is up to the RESV message of LSP A to assign the label. At this time, the condition happens between LSP A and LSP B. You may say why LSP A is so unlucky and it may not happen two race conditions in a short time. But it may although the probability is very small :=) If you draw pictures, you may find other scenarios. -- Guangzhi Karthik Subramanian wrote: > Guangzhi, > Let me try to understand what you are suggesting here. Please correct me if > I'm wrong. > > m------------>n > N1 N2 > o<------------p > > m,n,o,p are the labels for a bidirectional port. > LSP A is an uni-directional LSP whose direction is from N1 to N2 > LSP B is a bi-directional LSP whose direction is from N1 to N2. > > The sequence of operations is > > 1. N1 suggests 'n' for LSP A. > 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve > 'n' yet. > 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to > N1. > Simultaneously, for LSP B, N1 allocates 'o' as upstream label, > suggests 'n' for the forward direction and forwards the PATH. > > The problem is caused due to N1 suggesting the same label 'n' for 2 lsps. > With regard to suggested labels you can take 2 approaches. > > 1. Suggested Label is reserved by the upstream node when the PATH is > forwarded: > In this case, the problem won't arise, since during step 1, the link > (m,n) is reserved and hence for LSP B, this port is unavailable (since the > I/O ports of a bi-directional LSP are paired). > > 2. Suggested Label is NOT reserved by the upstream node until RESV comes: > In this case, during step 3, you are contradicting yourself by making > the cross-connect in N1 and hence reserving the port. I understand that the > I/O port pairing for bi-directional lsp might be a hardware restriction, but > its a contradiction nonetheless. > > You need to decide which approach to take and no violations must be made. > The first approach seems logical to me. > > Karthik > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > I did not make it clear. I assume that the I/O ports of > > Bi-directional LSP > > are > > paired. After node 1 configured the cross-connect with the > > upstream label > > (of course > > suggested label) for LSP B, node 1 received the uni-directional RESV > > message for > > LSP A, is it obviously defined in GMPLS that node 1 should > > accept LSP A and > > give up > > LSP B or simply is it a local decision/policy implementation? > > > > -- Guangzhi > > > > Guangzhi Li wrote: > > > > > Hang: > > > > > > NO. The PATH message is bi-directional and the RESV is > > uni-directional. If > > there > > > is a contention, the contention happens with LSP A and the > > upstream label > > of > > > LSP B. > > > > > > In your suggestion, you used IF. IF GMPLS specifies a > > consisten way to > > resolve > > > it, such as Resv wins Path message in all cases, there is > > no problem. A > > simply > > > local decision is NOT enough. > > > > > > Please draw pictures and apply current GMPLS contention > > resolution schemes > > ONLY. > > > You will see something needs to be fixed. > > > > > > Guangzhi Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 08:21:45 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040402088951@mail1.tellium.com> From: Hang Liu To: "'Guangzhi Li'" , Karthik Subramanian , "'eric.gray@sandburst.com'" Cc: Hang Liu , John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Wed, 29 Aug 2001 11:17:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi. One observation is When the I/O ports are paired, the contention between a uni-directional LSP and a bi-directional LSP is similar to the contention of two bi-directional LSPs. When a uni-directional LSP wants a label (I am not sure how common a uni-directional LSP is needed in the case of paired I/O), it actually contends that I/O pair with the bi-directional LSP. Hang -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Tuesday, August 28, 2001 7:45 PM To: Karthik Subramanian Cc: 'Hang Liu'; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Karthik: I understand your argument. But (1) It it legal not to suggest a label in PATH for a uni-directional LSP but to suggest a label for a bi-directional LSP especially I/O ports are paired. (2) If this is too weak, then assume another scenario: the PATH message of LSP A suggested a label but was rejected by N2 due to race condition of other LSPs, (such as a bi-directional LSP C from N2 to N1), then it is up to the RESV message of LSP A to assign the label. At this time, the condition happens between LSP A and LSP B. You may say why LSP A is so unlucky and it may not happen two race conditions in a short time. But it may although the probability is very small :=) If you draw pictures, you may find other scenarios. -- Guangzhi Karthik Subramanian wrote: > Guangzhi, > Let me try to understand what you are suggesting here. Please correct me if > I'm wrong. > > m------------>n > N1 N2 > o<------------p > > m,n,o,p are the labels for a bidirectional port. > LSP A is an uni-directional LSP whose direction is from N1 to N2 > LSP B is a bi-directional LSP whose direction is from N1 to N2. > > The sequence of operations is > > 1. N1 suggests 'n' for LSP A. > 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve > 'n' yet. > 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to > N1. > Simultaneously, for LSP B, N1 allocates 'o' as upstream label, > suggests 'n' for the forward direction and forwards the PATH. > > The problem is caused due to N1 suggesting the same label 'n' for 2 lsps. > With regard to suggested labels you can take 2 approaches. > > 1. Suggested Label is reserved by the upstream node when the PATH is > forwarded: > In this case, the problem won't arise, since during step 1, the link > (m,n) is reserved and hence for LSP B, this port is unavailable (since the > I/O ports of a bi-directional LSP are paired). > > 2. Suggested Label is NOT reserved by the upstream node until RESV comes: > In this case, during step 3, you are contradicting yourself by making > the cross-connect in N1 and hence reserving the port. I understand that the > I/O port pairing for bi-directional lsp might be a hardware restriction, but > its a contradiction nonetheless. > > You need to decide which approach to take and no violations must be made. > The first approach seems logical to me. > > Karthik > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > I did not make it clear. I assume that the I/O ports of > > Bi-directional LSP > > are > > paired. After node 1 configured the cross-connect with the > > upstream label > > (of course > > suggested label) for LSP B, node 1 received the uni-directional RESV > > message for > > LSP A, is it obviously defined in GMPLS that node 1 should > > accept LSP A and > > give up > > LSP B or simply is it a local decision/policy implementation? > > > > -- Guangzhi > > > > Guangzhi Li wrote: > > > > > Hang: > > > > > > NO. The PATH message is bi-directional and the RESV is > > uni-directional. If > > there > > > is a contention, the contention happens with LSP A and the > > upstream label > > of > > > LSP B. > > > > > > In your suggestion, you used IF. IF GMPLS specifies a > > consisten way to > > resolve > > > it, such as Resv wins Path message in all cases, there is > > no problem. A > > simply > > > local decision is NOT enough. > > > > > > Please draw pictures and apply current GMPLS contention > > resolution schemes > > ONLY. > > > You will see something needs to be fixed. > > > > > > Guangzhi Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 06:48:23 -0700 Message-ID: <3B8CF354.89D8B639@research.att.com> Date: Wed, 29 Aug 2001 09:51:16 -0400 From: Guangzhi Li MIME-Version: 1.0 To: John Drake Cc: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fong: What is your opinion? Is this a simple "local policy/implementation" issue or both node1 and node2 are required to interperate the same way? In your first email, you proposed one possible solution (Resv message wins Path message always). Is this solution simply a "local decision" or global requirement? Also how about race condition between uni-PATH and Bi-PATH? Your opinion is very much appreciated. Thanks, -- Guangzhi John Drake wrote: > What this requires is an RSVP implementation in which the Resv processing > checks to see whether there is any outstanding Path request specifying a > upstream label that is tied to the downstream label received in the Resv, > and if there is to tear down the LSP that was just established with the > Resv, as opposed to an implementation that would process Resvs serially. I > don't know how sensible this may or may not be. > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Tuesday, August 28, 2001 6:52 AM > To: John Drake > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > John: > > No. Node 1 may send out the PATH message to node 2 as the same time as node > 2 > sends out the RESV message to node 1. If the contention resolution is a > local > decision or policy implementation, node 1 may decide to fail LSP A since > node 1 > has the higher node ID. Then both LSP A and LSP B are failed. This is not > what > we want. So, a consistent decision is required between these two nodes. > > Thanks, > > -- Guangzhi > > John Drake wrote: > > > Guangzhi, > > > > In Fong's note she indicated that the contention can be completely > resolved > > by node 2, so I'm not sure that there's an interoperability issue. I.e., > > node 1 is told the result of node 2's decision making process. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Monday, August 27, 2001 2:13 PM > > To: Fong Liaw > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: Question on GMPLS contentions resolution > > > > Fong: > > > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs > both > > uni-directional and bi-directional together and uses the same port pool, > > then a PATH and a RESV may cross each other. I think that it should be > legal > > based on current GMPLS specification. IF this scenario happens, GMPLS has > to > > provide one standard way to handle this situation. > > > > Your suggestion works but it still involves the implementations of node 1 > > and node 2. Both nodes should interperate the same way. That means RESV > > message always wins PATH message. No problem. > > > > I assume that the I/O ports of bi-didrectional LSP are paired together, > then > > suggested_label = upstream_label and suggested_label is hard binding. Note > > that contention happens in either this case or lack of resource. If > > suggested_label could be different upstream_label, no contention problem > at > > all. > > > > -- Guangzhi > > > > Fong Liaw wrote: > > > > > Guangzhi > > > > > > The GMPLS contention resolution applies to the scenario > > > that two Path messages cross each other. Your example > > > have Resv and Path cross each other so the rule in the > > > contention resolution does not directly apply and is more > > > of a policy and implementation issue. > > > > > > Here is one possible solution and is within the > > > interpretation of the draft, IMHO. here it is. > > > If node 2 already sends Resv to node 1, LSP A should > > > be considered established and therefore LSP B should > > > be rejected by node 2. If node 2 hasn't sent back Resv, > > > LSP A is still in establishing mode and node 2 can resolve > > > the contention internally by rejecting LSP A or LSP B, based > > > on their setting up priority or it can change LSP A's > > > label and reprogram the cross-connect without ever noticed > > > by any external node. In both cases, node 2 is the one > > > that resolve this contention. Hope this helps. > > > > > > p.s. I think you meant to use LABEL_SET since > > > Suggested label is a suggestion, not a hard binding. > > > > > > Regards > > > -Fong > > > > > > > -----Original Message----- > > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > Sent: Monday, August 27, 2001 6:17 AM > > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > > Cc: gli@research.att.com > > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > > > During GMPLS last call, I posted the same question on the > > > > mailing list > > > > without response. Please somebody spend a little time and > > > > check with the > > > > following example? Something seems not clear when the current GMPLS > > > > contention resution schemes are applied on a framework with both > > > > bi-directional and uni-directional LSPs. Your clarification > > > > is very much > > > > appreciated. > > > > > > > > Sincerely, > > > > > > > > Guangzhi > > > > > > > > ------------------------------------------------------------- > > > > ------------------------------------- > > > > > > > > The issue arises because contention is resolved between > > > > bi-directional > > > > LSPs by the node with the higher node index while for uni-directional > > > > LSPs, contention is resolved by the downstream node. Consider the > > > > following example of two nodes with paired, bi-directional interfaces > > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > > transmitter port and > > > > label 2 for the receiver port; node 2 uses label 4 for the > > > > transmitter > > > > port and label 3 for the receiver port. We assume that a > > > > bi-directional LSP requires a single I/O interface. > > > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > > to node 2, > > > > with the uni-directional LSP setup request arriving marginally before > > > > the bi-directional LSP. LSP A does not use a suggested > > > > label, and thus > > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > > contention resolution rule for bi-directional LSPs) that LSP > > > > B wins the > > > > contention and thus label 3 is assigned to LSP B. Thus > > > > label 1 at node > > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > > LSPs have "won" the contention. > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Aug 2001 06:42:11 -0700 Message-ID: <3B8CEF8B.94618B76@sandburst.com> Date: Wed, 29 Aug 2001 09:35:07 -0400 From: Eric Gray MIME-Version: 1.0 To: John Drake Cc: 'Guangzhi Li' , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, Even in processing Resv messages serially, it is quite reasonable (if not actually required) for an implementation to want to retrieve the PSB. It is conceivable that the delta in such a case for checking outstanding Path requests is not that great. Moreover, how much work is node 2 going to have to go through to ascertain that - as Fong had implied - the completion of LSP A means that LSP B does not have to be completed? It seems to me that - once again - it is be left open to the implementer to determine where the work gets done in this case. If options may be ugly, ambiguity can be hideous. -- Eric Gray You wrote: > What this requires is an RSVP implementation in which the Resv processing > checks to see whether there is any outstanding Path request specifying a > upstream label that is tied to the downstream label received in the Resv, > and if there is to tear down the LSP that was just established with the > Resv, as opposed to an implementation that would process Resvs serially. I > don't know how sensible this may or may not be. > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Tuesday, August 28, 2001 6:52 AM > To: John Drake > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > John: > > No. Node 1 may send out the PATH message to node 2 as the same time as node > 2 > sends out the RESV message to node 1. If the contention resolution is a > local > decision or policy implementation, node 1 may decide to fail LSP A since > node 1 > has the higher node ID. Then both LSP A and LSP B are failed. This is not > what > we want. So, a consistent decision is required between these two nodes. > > Thanks, > > -- Guangzhi > > John Drake wrote: > > > Guangzhi, > > > > In Fong's note she indicated that the contention can be completely > resolved > > by node 2, so I'm not sure that there's an interoperability issue. I.e., > > node 1 is told the result of node 2's decision making process. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Monday, August 27, 2001 2:13 PM > > To: Fong Liaw > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: Question on GMPLS contentions resolution > > > > Fong: > > > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs > both > > uni-directional and bi-directional together and uses the same port pool, > > then a PATH and a RESV may cross each other. I think that it should be > legal > > based on current GMPLS specification. IF this scenario happens, GMPLS has > to > > provide one standard way to handle this situation. > > > > Your suggestion works but it still involves the implementations of node 1 > > and node 2. Both nodes should interperate the same way. That means RESV > > message always wins PATH message. No problem. > > > > I assume that the I/O ports of bi-didrectional LSP are paired together, > then > > suggested_label = upstream_label and suggested_label is hard binding. Note > > that contention happens in either this case or lack of resource. If > > suggested_label could be different upstream_label, no contention problem > at > > all. > > > > -- Guangzhi > > > > Fong Liaw wrote: > > > > > Guangzhi > > > > > > The GMPLS contention resolution applies to the scenario > > > that two Path messages cross each other. Your example > > > have Resv and Path cross each other so the rule in the > > > contention resolution does not directly apply and is more > > > of a policy and implementation issue. > > > > > > Here is one possible solution and is within the > > > interpretation of the draft, IMHO. here it is. > > > If node 2 already sends Resv to node 1, LSP A should > > > be considered established and therefore LSP B should > > > be rejected by node 2. If node 2 hasn't sent back Resv, > > > LSP A is still in establishing mode and node 2 can resolve > > > the contention internally by rejecting LSP A or LSP B, based > > > on their setting up priority or it can change LSP A's > > > label and reprogram the cross-connect without ever noticed > > > by any external node. In both cases, node 2 is the one > > > that resolve this contention. Hope this helps. > > > > > > p.s. I think you meant to use LABEL_SET since > > > Suggested label is a suggestion, not a hard binding. > > > > > > Regards > > > -Fong > > > > > > > -----Original Message----- > > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > Sent: Monday, August 27, 2001 6:17 AM > > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > > Cc: gli@research.att.com > > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > > > During GMPLS last call, I posted the same question on the > > > > mailing list > > > > without response. Please somebody spend a little time and > > > > check with the > > > > following example? Something seems not clear when the current GMPLS > > > > contention resution schemes are applied on a framework with both > > > > bi-directional and uni-directional LSPs. Your clarification > > > > is very much > > > > appreciated. > > > > > > > > Sincerely, > > > > > > > > Guangzhi > > > > > > > > ------------------------------------------------------------- > > > > ------------------------------------- > > > > > > > > The issue arises because contention is resolved between > > > > bi-directional > > > > LSPs by the node with the higher node index while for uni-directional > > > > LSPs, contention is resolved by the downstream node. Consider the > > > > following example of two nodes with paired, bi-directional interfaces > > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > > transmitter port and > > > > label 2 for the receiver port; node 2 uses label 4 for the > > > > transmitter > > > > port and label 3 for the receiver port. We assume that a > > > > bi-directional LSP requires a single I/O interface. > > > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > > to node 2, > > > > with the uni-directional LSP setup request arriving marginally before > > > > the bi-directional LSP. LSP A does not use a suggested > > > > label, and thus > > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > > contention resolution rule for bi-directional LSPs) that LSP > > > > B wins the > > > > contention and thus label 3 is assigned to LSP B. Thus > > > > label 1 at node > > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > > LSPs have "won" the contention. > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 18:34:41 -0700 Message-ID: From: John Drake To: 'Guangzhi Li' , John Drake Cc: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Tue, 28 Aug 2001 18:28:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" What this requires is an RSVP implementation in which the Resv processing checks to see whether there is any outstanding Path request specifying a upstream label that is tied to the downstream label received in the Resv, and if there is to tear down the LSP that was just established with the Resv, as opposed to an implementation that would process Resvs serially. I don't know how sensible this may or may not be. -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Tuesday, August 28, 2001 6:52 AM To: John Drake Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution John: No. Node 1 may send out the PATH message to node 2 as the same time as node 2 sends out the RESV message to node 1. If the contention resolution is a local decision or policy implementation, node 1 may decide to fail LSP A since node 1 has the higher node ID. Then both LSP A and LSP B are failed. This is not what we want. So, a consistent decision is required between these two nodes. Thanks, -- Guangzhi John Drake wrote: > Guangzhi, > > In Fong's note she indicated that the contention can be completely resolved > by node 2, so I'm not sure that there's an interoperability issue. I.e., > node 1 is told the result of node 2's decision making process. > > Thanks, > > John > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Monday, August 27, 2001 2:13 PM > To: Fong Liaw > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > Fong: > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both > uni-directional and bi-directional together and uses the same port pool, > then a PATH and a RESV may cross each other. I think that it should be legal > based on current GMPLS specification. IF this scenario happens, GMPLS has to > provide one standard way to handle this situation. > > Your suggestion works but it still involves the implementations of node 1 > and node 2. Both nodes should interperate the same way. That means RESV > message always wins PATH message. No problem. > > I assume that the I/O ports of bi-didrectional LSP are paired together, then > suggested_label = upstream_label and suggested_label is hard binding. Note > that contention happens in either this case or lack of resource. If > suggested_label could be different upstream_label, no contention problem at > all. > > -- Guangzhi > > Fong Liaw wrote: > > > Guangzhi > > > > The GMPLS contention resolution applies to the scenario > > that two Path messages cross each other. Your example > > have Resv and Path cross each other so the rule in the > > contention resolution does not directly apply and is more > > of a policy and implementation issue. > > > > Here is one possible solution and is within the > > interpretation of the draft, IMHO. here it is. > > If node 2 already sends Resv to node 1, LSP A should > > be considered established and therefore LSP B should > > be rejected by node 2. If node 2 hasn't sent back Resv, > > LSP A is still in establishing mode and node 2 can resolve > > the contention internally by rejecting LSP A or LSP B, based > > on their setting up priority or it can change LSP A's > > label and reprogram the cross-connect without ever noticed > > by any external node. In both cases, node 2 is the one > > that resolve this contention. Hope this helps. > > > > p.s. I think you meant to use LABEL_SET since > > Suggested label is a suggestion, not a hard binding. > > > > Regards > > -Fong > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Monday, August 27, 2001 6:17 AM > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > Cc: gli@research.att.com > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > During GMPLS last call, I posted the same question on the > > > mailing list > > > without response. Please somebody spend a little time and > > > check with the > > > following example? Something seems not clear when the current GMPLS > > > contention resution schemes are applied on a framework with both > > > bi-directional and uni-directional LSPs. Your clarification > > > is very much > > > appreciated. > > > > > > Sincerely, > > > > > > Guangzhi > > > > > > ------------------------------------------------------------- > > > ------------------------------------- > > > > > > The issue arises because contention is resolved between > > > bi-directional > > > LSPs by the node with the higher node index while for uni-directional > > > LSPs, contention is resolved by the downstream node. Consider the > > > following example of two nodes with paired, bi-directional interfaces > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > transmitter port and > > > label 2 for the receiver port; node 2 uses label 4 for the > > > transmitter > > > port and label 3 for the receiver port. We assume that a > > > bi-directional LSP requires a single I/O interface. > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > to node 2, > > > with the uni-directional LSP setup request arriving marginally before > > > the bi-directional LSP. LSP A does not use a suggested > > > label, and thus > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > contention resolution rule for bi-directional LSPs) that LSP > > > B wins the > > > contention and thus label 3 is assigned to LSP B. Thus > > > label 1 at node > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > LSPs have "won" the contention. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 16:42:52 -0700 Message-ID: <3B8C2CED.526B20E8@research.att.com> Date: Tue, 28 Aug 2001 19:44:45 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Karthik Subramanian Cc: "'Hang Liu'" , John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karthik: I understand your argument. But (1) It it legal not to suggest a label in PATH for a uni-directional LSP but to suggest a label for a bi-directional LSP especially I/O ports are paired. (2) If this is too weak, then assume another scenario: the PATH message of LSP A suggested a label but was rejected by N2 due to race condition of other LSPs, (such as a bi-directional LSP C from N2 to N1), then it is up to the RESV message of LSP A to assign the label. At this time, the condition happens between LSP A and LSP B. You may say why LSP A is so unlucky and it may not happen two race conditions in a short time. But it may although the probability is very small :=) If you draw pictures, you may find other scenarios. -- Guangzhi Karthik Subramanian wrote: > Guangzhi, > Let me try to understand what you are suggesting here. Please correct me if > I'm wrong. > > m------------>n > N1 N2 > o<------------p > > m,n,o,p are the labels for a bidirectional port. > LSP A is an uni-directional LSP whose direction is from N1 to N2 > LSP B is a bi-directional LSP whose direction is from N1 to N2. > > The sequence of operations is > > 1. N1 suggests 'n' for LSP A. > 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve > 'n' yet. > 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to > N1. > Simultaneously, for LSP B, N1 allocates 'o' as upstream label, > suggests 'n' for the forward direction and forwards the PATH. > > The problem is caused due to N1 suggesting the same label 'n' for 2 lsps. > With regard to suggested labels you can take 2 approaches. > > 1. Suggested Label is reserved by the upstream node when the PATH is > forwarded: > In this case, the problem won't arise, since during step 1, the link > (m,n) is reserved and hence for LSP B, this port is unavailable (since the > I/O ports of a bi-directional LSP are paired). > > 2. Suggested Label is NOT reserved by the upstream node until RESV comes: > In this case, during step 3, you are contradicting yourself by making > the cross-connect in N1 and hence reserving the port. I understand that the > I/O port pairing for bi-directional lsp might be a hardware restriction, but > its a contradiction nonetheless. > > You need to decide which approach to take and no violations must be made. > The first approach seems logical to me. > > Karthik > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > I did not make it clear. I assume that the I/O ports of > > Bi-directional LSP > > are > > paired. After node 1 configured the cross-connect with the > > upstream label > > (of course > > suggested label) for LSP B, node 1 received the uni-directional RESV > > message for > > LSP A, is it obviously defined in GMPLS that node 1 should > > accept LSP A and > > give up > > LSP B or simply is it a local decision/policy implementation? > > > > -- Guangzhi > > > > Guangzhi Li wrote: > > > > > Hang: > > > > > > NO. The PATH message is bi-directional and the RESV is > > uni-directional. If > > there > > > is a contention, the contention happens with LSP A and the > > upstream label > > of > > > LSP B. > > > > > > In your suggestion, you used IF. IF GMPLS specifies a > > consisten way to > > resolve > > > it, such as Resv wins Path message in all cases, there is > > no problem. A > > simply > > > local decision is NOT enough. > > > > > > Please draw pictures and apply current GMPLS contention > > resolution schemes > > ONLY. > > > You will see something needs to be fixed. > > > > > > Guangzhi Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 11:31:12 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040402088950@mail1.tellium.com> From: Hang Liu To: "'Guangzhi Li'" , Hang Liu , John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Tue, 28 Aug 2001 14:19:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Guangzhi, It is true that a consistent way is needed to handle this case. Otherwise, as you mentioned, both LSP A and LSP B may fail. Hang -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Tuesday, August 28, 2001 1:39 PM To: Hang Liu; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Hang: I did not make it clear. I assume that the I/O ports of Bi-directional LSP are paired. After node 1 configured the cross-connect with the upstream label (of course suggested label) for LSP B, node 1 received the uni-directional RESV message for LSP A, is it obviously defined in GMPLS that node 1 should accept LSP A and give up LSP B or simply is it a local decision/policy implementation? -- Guangzhi Guangzhi Li wrote: > Hang: > > NO. The PATH message is bi-directional and the RESV is uni-directional. If there > is a contention, the contention happens with LSP A and the upstream label of > LSP B. > > In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve > it, such as Resv wins Path message in all cases, there is no problem. A simply > local decision is NOT enough. > > Please draw pictures and apply current GMPLS contention resolution schemes ONLY. > You will see something needs to be fixed. > > Guangzhi > > Hang Liu wrote: > > > Guangzhi, > > > > For this case, if Node 1 always maps the label in the RESV message and > > creates RSB. LSP A will be set up. The suggested label in the PATH message > > from Node 1 is only preference. LSP B will be rejected by Node 2. > > > > Hang > > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Tuesday, August 28, 2001 9:52 AM > > To: John Drake > > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: Question on GMPLS contentions resolution > > > > John: > > > > No. Node 1 may send out the PATH message to node 2 as the same time as node > > 2 > > sends out the RESV message to node 1. If the contention resolution is a > > local > > decision or policy implementation, node 1 may decide to fail LSP A since > > node 1 > > has the higher node ID. Then both LSP A and LSP B are failed. This is not > > what > > we want. So, a consistent decision is required between these two nodes. > > > > Thanks, > > > > -- Guangzhi > > > > John Drake wrote: > > > > > Guangzhi, > > > > > > In Fong's note she indicated that the contention can be completely > > resolved > > > by node 2, so I'm not sure that there's an interoperability issue. I.e., > > > node 1 is told the result of node 2's decision making process. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Monday, August 27, 2001 2:13 PM > > > To: Fong Liaw > > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > > Subject: Re: Question on GMPLS contentions resolution > > > > > > Fong: > > > > > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs > > both > > > uni-directional and bi-directional together and uses the same port pool, > > > then a PATH and a RESV may cross each other. I think that it should be > > legal > > > based on current GMPLS specification. IF this scenario happens, GMPLS has > > to > > > provide one standard way to handle this situation. > > > > > > Your suggestion works but it still involves the implementations of node 1 > > > and node 2. Both nodes should interperate the same way. That means RESV > > > message always wins PATH message. No problem. > > > > > > I assume that the I/O ports of bi-didrectional LSP are paired together, > > then > > > suggested_label = upstream_label and suggested_label is hard binding. Note > > > that contention happens in either this case or lack of resource. If > > > suggested_label could be different upstream_label, no contention problem > > at > > > all. > > > > > > -- Guangzhi > > > > > > Fong Liaw wrote: > > > > > > > Guangzhi > > > > > > > > The GMPLS contention resolution applies to the scenario > > > > that two Path messages cross each other. Your example > > > > have Resv and Path cross each other so the rule in the > > > > contention resolution does not directly apply and is more > > > > of a policy and implementation issue. > > > > > > > > Here is one possible solution and is within the > > > > interpretation of the draft, IMHO. here it is. > > > > If node 2 already sends Resv to node 1, LSP A should > > > > be considered established and therefore LSP B should > > > > be rejected by node 2. If node 2 hasn't sent back Resv, > > > > LSP A is still in establishing mode and node 2 can resolve > > > > the contention internally by rejecting LSP A or LSP B, based > > > > on their setting up priority or it can change LSP A's > > > > label and reprogram the cross-connect without ever noticed > > > > by any external node. In both cases, node 2 is the one > > > > that resolve this contention. Hope this helps. > > > > > > > > p.s. I think you meant to use LABEL_SET since > > > > Suggested label is a suggestion, not a hard binding. > > > > > > > > Regards > > > > -Fong > > > > > > > > > -----Original Message----- > > > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > > Sent: Monday, August 27, 2001 6:17 AM > > > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > > > Cc: gli@research.att.com > > > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > > > > > During GMPLS last call, I posted the same question on the > > > > > mailing list > > > > > without response. Please somebody spend a little time and > > > > > check with the > > > > > following example? Something seems not clear when the current GMPLS > > > > > contention resution schemes are applied on a framework with both > > > > > bi-directional and uni-directional LSPs. Your clarification > > > > > is very much > > > > > appreciated. > > > > > > > > > > Sincerely, > > > > > > > > > > Guangzhi > > > > > > > > > > ------------------------------------------------------------- > > > > > ------------------------------------- > > > > > > > > > > The issue arises because contention is resolved between > > > > > bi-directional > > > > > LSPs by the node with the higher node index while for uni-directional > > > > > LSPs, contention is resolved by the downstream node. Consider the > > > > > following example of two nodes with paired, bi-directional interfaces > > > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > > > transmitter port and > > > > > label 2 for the receiver port; node 2 uses label 4 for the > > > > > transmitter > > > > > port and label 3 for the receiver port. We assume that a > > > > > bi-directional LSP requires a single I/O interface. > > > > > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > > > to node 2, > > > > > with the uni-directional LSP setup request arriving marginally before > > > > > the bi-directional LSP. LSP A does not use a suggested > > > > > label, and thus > > > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > > > contention resolution rule for bi-directional LSPs) that LSP > > > > > B wins the > > > > > contention and thus label 3 is assigned to LSP B. Thus > > > > > label 1 at node > > > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > > > LSPs have "won" the contention. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 10:43:11 -0700 Message-ID: <3B8BD716.1BBCE7D8@research.att.com> Date: Tue, 28 Aug 2001 13:38:30 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Hang Liu , John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hang: I did not make it clear. I assume that the I/O ports of Bi-directional LSP are paired. After node 1 configured the cross-connect with the upstream label (of course suggested label) for LSP B, node 1 received the uni-directional RESV message for LSP A, is it obviously defined in GMPLS that node 1 should accept LSP A and give up LSP B or simply is it a local decision/policy implementation? -- Guangzhi Guangzhi Li wrote: > Hang: > > NO. The PATH message is bi-directional and the RESV is uni-directional. If there > is a contention, the contention happens with LSP A and the upstream label of > LSP B. > > In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve > it, such as Resv wins Path message in all cases, there is no problem. A simply > local decision is NOT enough. > > Please draw pictures and apply current GMPLS contention resolution schemes ONLY. > You will see something needs to be fixed. > > Guangzhi > > Hang Liu wrote: > > > Guangzhi, > > > > For this case, if Node 1 always maps the label in the RESV message and > > creates RSB. LSP A will be set up. The suggested label in the PATH message > > from Node 1 is only preference. LSP B will be rejected by Node 2. > > > > Hang > > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Tuesday, August 28, 2001 9:52 AM > > To: John Drake > > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: Question on GMPLS contentions resolution > > > > John: > > > > No. Node 1 may send out the PATH message to node 2 as the same time as node > > 2 > > sends out the RESV message to node 1. If the contention resolution is a > > local > > decision or policy implementation, node 1 may decide to fail LSP A since > > node 1 > > has the higher node ID. Then both LSP A and LSP B are failed. This is not > > what > > we want. So, a consistent decision is required between these two nodes. > > > > Thanks, > > > > -- Guangzhi > > > > John Drake wrote: > > > > > Guangzhi, > > > > > > In Fong's note she indicated that the contention can be completely > > resolved > > > by node 2, so I'm not sure that there's an interoperability issue. I.e., > > > node 1 is told the result of node 2's decision making process. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Monday, August 27, 2001 2:13 PM > > > To: Fong Liaw > > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > > Subject: Re: Question on GMPLS contentions resolution > > > > > > Fong: > > > > > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs > > both > > > uni-directional and bi-directional together and uses the same port pool, > > > then a PATH and a RESV may cross each other. I think that it should be > > legal > > > based on current GMPLS specification. IF this scenario happens, GMPLS has > > to > > > provide one standard way to handle this situation. > > > > > > Your suggestion works but it still involves the implementations of node 1 > > > and node 2. Both nodes should interperate the same way. That means RESV > > > message always wins PATH message. No problem. > > > > > > I assume that the I/O ports of bi-didrectional LSP are paired together, > > then > > > suggested_label = upstream_label and suggested_label is hard binding. Note > > > that contention happens in either this case or lack of resource. If > > > suggested_label could be different upstream_label, no contention problem > > at > > > all. > > > > > > -- Guangzhi > > > > > > Fong Liaw wrote: > > > > > > > Guangzhi > > > > > > > > The GMPLS contention resolution applies to the scenario > > > > that two Path messages cross each other. Your example > > > > have Resv and Path cross each other so the rule in the > > > > contention resolution does not directly apply and is more > > > > of a policy and implementation issue. > > > > > > > > Here is one possible solution and is within the > > > > interpretation of the draft, IMHO. here it is. > > > > If node 2 already sends Resv to node 1, LSP A should > > > > be considered established and therefore LSP B should > > > > be rejected by node 2. If node 2 hasn't sent back Resv, > > > > LSP A is still in establishing mode and node 2 can resolve > > > > the contention internally by rejecting LSP A or LSP B, based > > > > on their setting up priority or it can change LSP A's > > > > label and reprogram the cross-connect without ever noticed > > > > by any external node. In both cases, node 2 is the one > > > > that resolve this contention. Hope this helps. > > > > > > > > p.s. I think you meant to use LABEL_SET since > > > > Suggested label is a suggestion, not a hard binding. > > > > > > > > Regards > > > > -Fong > > > > > > > > > -----Original Message----- > > > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > > Sent: Monday, August 27, 2001 6:17 AM > > > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > > > Cc: gli@research.att.com > > > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > > > > > During GMPLS last call, I posted the same question on the > > > > > mailing list > > > > > without response. Please somebody spend a little time and > > > > > check with the > > > > > following example? Something seems not clear when the current GMPLS > > > > > contention resution schemes are applied on a framework with both > > > > > bi-directional and uni-directional LSPs. Your clarification > > > > > is very much > > > > > appreciated. > > > > > > > > > > Sincerely, > > > > > > > > > > Guangzhi > > > > > > > > > > ------------------------------------------------------------- > > > > > ------------------------------------- > > > > > > > > > > The issue arises because contention is resolved between > > > > > bi-directional > > > > > LSPs by the node with the higher node index while for uni-directional > > > > > LSPs, contention is resolved by the downstream node. Consider the > > > > > following example of two nodes with paired, bi-directional interfaces > > > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > > > transmitter port and > > > > > label 2 for the receiver port; node 2 uses label 4 for the > > > > > transmitter > > > > > port and label 3 for the receiver port. We assume that a > > > > > bi-directional LSP requires a single I/O interface. > > > > > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > > > to node 2, > > > > > with the uni-directional LSP setup request arriving marginally before > > > > > the bi-directional LSP. LSP A does not use a suggested > > > > > label, and thus > > > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > > > contention resolution rule for bi-directional LSPs) that LSP > > > > > B wins the > > > > > contention and thus label 3 is assigned to LSP B. Thus > > > > > label 1 at node > > > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > > > LSPs have "won" the contention. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 10:14:24 -0700 Message-ID: <3B8BD235.88311B40@research.att.com> Date: Tue, 28 Aug 2001 13:17:41 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Hang Liu Cc: John Drake , Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hang: NO. The PATH message is bi-directional and the RESV is uni-directional. If there is a contention, the contention happens with LSP A and the upstream label of LSP B. In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve it, such as Resv wins Path message in all cases, there is no problem. A simply local decision is NOT enough. Please draw pictures and apply current GMPLS contention resolution schemes ONLY. You will see something needs to be fixed. Guangzhi Hang Liu wrote: > Guangzhi, > > For this case, if Node 1 always maps the label in the RESV message and > creates RSB. LSP A will be set up. The suggested label in the PATH message > from Node 1 is only preference. LSP B will be rejected by Node 2. > > Hang > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Tuesday, August 28, 2001 9:52 AM > To: John Drake > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > John: > > No. Node 1 may send out the PATH message to node 2 as the same time as node > 2 > sends out the RESV message to node 1. If the contention resolution is a > local > decision or policy implementation, node 1 may decide to fail LSP A since > node 1 > has the higher node ID. Then both LSP A and LSP B are failed. This is not > what > we want. So, a consistent decision is required between these two nodes. > > Thanks, > > -- Guangzhi > > John Drake wrote: > > > Guangzhi, > > > > In Fong's note she indicated that the contention can be completely > resolved > > by node 2, so I'm not sure that there's an interoperability issue. I.e., > > node 1 is told the result of node 2's decision making process. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Monday, August 27, 2001 2:13 PM > > To: Fong Liaw > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: Question on GMPLS contentions resolution > > > > Fong: > > > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs > both > > uni-directional and bi-directional together and uses the same port pool, > > then a PATH and a RESV may cross each other. I think that it should be > legal > > based on current GMPLS specification. IF this scenario happens, GMPLS has > to > > provide one standard way to handle this situation. > > > > Your suggestion works but it still involves the implementations of node 1 > > and node 2. Both nodes should interperate the same way. That means RESV > > message always wins PATH message. No problem. > > > > I assume that the I/O ports of bi-didrectional LSP are paired together, > then > > suggested_label = upstream_label and suggested_label is hard binding. Note > > that contention happens in either this case or lack of resource. If > > suggested_label could be different upstream_label, no contention problem > at > > all. > > > > -- Guangzhi > > > > Fong Liaw wrote: > > > > > Guangzhi > > > > > > The GMPLS contention resolution applies to the scenario > > > that two Path messages cross each other. Your example > > > have Resv and Path cross each other so the rule in the > > > contention resolution does not directly apply and is more > > > of a policy and implementation issue. > > > > > > Here is one possible solution and is within the > > > interpretation of the draft, IMHO. here it is. > > > If node 2 already sends Resv to node 1, LSP A should > > > be considered established and therefore LSP B should > > > be rejected by node 2. If node 2 hasn't sent back Resv, > > > LSP A is still in establishing mode and node 2 can resolve > > > the contention internally by rejecting LSP A or LSP B, based > > > on their setting up priority or it can change LSP A's > > > label and reprogram the cross-connect without ever noticed > > > by any external node. In both cases, node 2 is the one > > > that resolve this contention. Hope this helps. > > > > > > p.s. I think you meant to use LABEL_SET since > > > Suggested label is a suggestion, not a hard binding. > > > > > > Regards > > > -Fong > > > > > > > -----Original Message----- > > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > > Sent: Monday, August 27, 2001 6:17 AM > > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > > Cc: gli@research.att.com > > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > > > During GMPLS last call, I posted the same question on the > > > > mailing list > > > > without response. Please somebody spend a little time and > > > > check with the > > > > following example? Something seems not clear when the current GMPLS > > > > contention resution schemes are applied on a framework with both > > > > bi-directional and uni-directional LSPs. Your clarification > > > > is very much > > > > appreciated. > > > > > > > > Sincerely, > > > > > > > > Guangzhi > > > > > > > > ------------------------------------------------------------- > > > > ------------------------------------- > > > > > > > > The issue arises because contention is resolved between > > > > bi-directional > > > > LSPs by the node with the higher node index while for uni-directional > > > > LSPs, contention is resolved by the downstream node. Consider the > > > > following example of two nodes with paired, bi-directional interfaces > > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > > transmitter port and > > > > label 2 for the receiver port; node 2 uses label 4 for the > > > > transmitter > > > > port and label 3 for the receiver port. We assume that a > > > > bi-directional LSP requires a single I/O interface. > > > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > > to node 2, > > > > with the uni-directional LSP setup request arriving marginally before > > > > the bi-directional LSP. LSP A does not use a suggested > > > > label, and thus > > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > > contention resolution rule for bi-directional LSPs) that LSP > > > > B wins the > > > > contention and thus label 3 is assigned to LSP B. Thus > > > > label 1 at node > > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > > LSPs have "won" the contention. > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 08:44:24 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D02204040208894F@mail1.tellium.com> From: Hang Liu To: "'Guangzhi Li'" , John Drake Cc: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Tue, 28 Aug 2001 11:29:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Guangzhi, For this case, if Node 1 always maps the label in the RESV message and creates RSB. LSP A will be set up. The suggested label in the PATH message from Node 1 is only preference. LSP B will be rejected by Node 2. Hang -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Tuesday, August 28, 2001 9:52 AM To: John Drake Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution John: No. Node 1 may send out the PATH message to node 2 as the same time as node 2 sends out the RESV message to node 1. If the contention resolution is a local decision or policy implementation, node 1 may decide to fail LSP A since node 1 has the higher node ID. Then both LSP A and LSP B are failed. This is not what we want. So, a consistent decision is required between these two nodes. Thanks, -- Guangzhi John Drake wrote: > Guangzhi, > > In Fong's note she indicated that the contention can be completely resolved > by node 2, so I'm not sure that there's an interoperability issue. I.e., > node 1 is told the result of node 2's decision making process. > > Thanks, > > John > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Monday, August 27, 2001 2:13 PM > To: Fong Liaw > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > Fong: > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both > uni-directional and bi-directional together and uses the same port pool, > then a PATH and a RESV may cross each other. I think that it should be legal > based on current GMPLS specification. IF this scenario happens, GMPLS has to > provide one standard way to handle this situation. > > Your suggestion works but it still involves the implementations of node 1 > and node 2. Both nodes should interperate the same way. That means RESV > message always wins PATH message. No problem. > > I assume that the I/O ports of bi-didrectional LSP are paired together, then > suggested_label = upstream_label and suggested_label is hard binding. Note > that contention happens in either this case or lack of resource. If > suggested_label could be different upstream_label, no contention problem at > all. > > -- Guangzhi > > Fong Liaw wrote: > > > Guangzhi > > > > The GMPLS contention resolution applies to the scenario > > that two Path messages cross each other. Your example > > have Resv and Path cross each other so the rule in the > > contention resolution does not directly apply and is more > > of a policy and implementation issue. > > > > Here is one possible solution and is within the > > interpretation of the draft, IMHO. here it is. > > If node 2 already sends Resv to node 1, LSP A should > > be considered established and therefore LSP B should > > be rejected by node 2. If node 2 hasn't sent back Resv, > > LSP A is still in establishing mode and node 2 can resolve > > the contention internally by rejecting LSP A or LSP B, based > > on their setting up priority or it can change LSP A's > > label and reprogram the cross-connect without ever noticed > > by any external node. In both cases, node 2 is the one > > that resolve this contention. Hope this helps. > > > > p.s. I think you meant to use LABEL_SET since > > Suggested label is a suggestion, not a hard binding. > > > > Regards > > -Fong > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Monday, August 27, 2001 6:17 AM > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > Cc: gli@research.att.com > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > During GMPLS last call, I posted the same question on the > > > mailing list > > > without response. Please somebody spend a little time and > > > check with the > > > following example? Something seems not clear when the current GMPLS > > > contention resution schemes are applied on a framework with both > > > bi-directional and uni-directional LSPs. Your clarification > > > is very much > > > appreciated. > > > > > > Sincerely, > > > > > > Guangzhi > > > > > > ------------------------------------------------------------- > > > ------------------------------------- > > > > > > The issue arises because contention is resolved between > > > bi-directional > > > LSPs by the node with the higher node index while for uni-directional > > > LSPs, contention is resolved by the downstream node. Consider the > > > following example of two nodes with paired, bi-directional interfaces > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > transmitter port and > > > label 2 for the receiver port; node 2 uses label 4 for the > > > transmitter > > > port and label 3 for the receiver port. We assume that a > > > bi-directional LSP requires a single I/O interface. > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > to node 2, > > > with the uni-directional LSP setup request arriving marginally before > > > the bi-directional LSP. LSP A does not use a suggested > > > label, and thus > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > contention resolution rule for bi-directional LSPs) that LSP > > > B wins the > > > contention and thus label 3 is assigned to LSP B. Thus > > > label 1 at node > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > LSPs have "won" the contention. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Aug 2001 06:55:10 -0700 Message-ID: <3B8BA205.7E1CDB3E@research.att.com> Date: Tue, 28 Aug 2001 09:52:05 -0400 From: Guangzhi Li MIME-Version: 1.0 To: John Drake Cc: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John: No. Node 1 may send out the PATH message to node 2 as the same time as node 2 sends out the RESV message to node 1. If the contention resolution is a local decision or policy implementation, node 1 may decide to fail LSP A since node 1 has the higher node ID. Then both LSP A and LSP B are failed. This is not what we want. So, a consistent decision is required between these two nodes. Thanks, -- Guangzhi John Drake wrote: > Guangzhi, > > In Fong's note she indicated that the contention can be completely resolved > by node 2, so I'm not sure that there's an interoperability issue. I.e., > node 1 is told the result of node 2's decision making process. > > Thanks, > > John > > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Monday, August 27, 2001 2:13 PM > To: Fong Liaw > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: Question on GMPLS contentions resolution > > Fong: > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both > uni-directional and bi-directional together and uses the same port pool, > then a PATH and a RESV may cross each other. I think that it should be legal > based on current GMPLS specification. IF this scenario happens, GMPLS has to > provide one standard way to handle this situation. > > Your suggestion works but it still involves the implementations of node 1 > and node 2. Both nodes should interperate the same way. That means RESV > message always wins PATH message. No problem. > > I assume that the I/O ports of bi-didrectional LSP are paired together, then > suggested_label = upstream_label and suggested_label is hard binding. Note > that contention happens in either this case or lack of resource. If > suggested_label could be different upstream_label, no contention problem at > all. > > -- Guangzhi > > Fong Liaw wrote: > > > Guangzhi > > > > The GMPLS contention resolution applies to the scenario > > that two Path messages cross each other. Your example > > have Resv and Path cross each other so the rule in the > > contention resolution does not directly apply and is more > > of a policy and implementation issue. > > > > Here is one possible solution and is within the > > interpretation of the draft, IMHO. here it is. > > If node 2 already sends Resv to node 1, LSP A should > > be considered established and therefore LSP B should > > be rejected by node 2. If node 2 hasn't sent back Resv, > > LSP A is still in establishing mode and node 2 can resolve > > the contention internally by rejecting LSP A or LSP B, based > > on their setting up priority or it can change LSP A's > > label and reprogram the cross-connect without ever noticed > > by any external node. In both cases, node 2 is the one > > that resolve this contention. Hope this helps. > > > > p.s. I think you meant to use LABEL_SET since > > Suggested label is a suggestion, not a hard binding. > > > > Regards > > -Fong > > > > > -----Original Message----- > > > From: Guangzhi Li [mailto:gli@research.att.com] > > > Sent: Monday, August 27, 2001 6:17 AM > > > To: ccamp@ops.ietf.org; mpls@UU.NET > > > Cc: gli@research.att.com > > > Subject: Question on GMPLS contentions resolution > > > > > > > > > Dear GMPLS authors and all experts: > > > > > > During GMPLS last call, I posted the same question on the > > > mailing list > > > without response. Please somebody spend a little time and > > > check with the > > > following example? Something seems not clear when the current GMPLS > > > contention resution schemes are applied on a framework with both > > > bi-directional and uni-directional LSPs. Your clarification > > > is very much > > > appreciated. > > > > > > Sincerely, > > > > > > Guangzhi > > > > > > ------------------------------------------------------------- > > > ------------------------------------- > > > > > > The issue arises because contention is resolved between > > > bi-directional > > > LSPs by the node with the higher node index while for uni-directional > > > LSPs, contention is resolved by the downstream node. Consider the > > > following example of two nodes with paired, bi-directional interfaces > > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > > node 2 with ID = 50. Node 1 uses label 1 for the > > > transmitter port and > > > label 2 for the receiver port; node 2 uses label 4 for the > > > transmitter > > > port and label 3 for the receiver port. We assume that a > > > bi-directional LSP requires a single I/O interface. > > > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > > to node 2, > > > with the uni-directional LSP setup request arriving marginally before > > > the bi-directional LSP. LSP A does not use a suggested > > > label, and thus > > > is assigned a label (port) by node 2. Label 3 is assigned, > > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > > Because node 1 has the higher node ID, node 2 will assume (due to the > > > contention resolution rule for bi-directional LSPs) that LSP > > > B wins the > > > contention and thus label 3 is assigned to LSP B. Thus > > > label 1 at node > > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > > LSPs have "won" the contention. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 15:33:29 -0700 Message-ID: From: John Drake To: 'Guangzhi Li' , Fong Liaw Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Mon, 27 Aug 2001 15:31:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Guangzhi, In Fong's note she indicated that the contention can be completely resolved by node 2, so I'm not sure that there's an interoperability issue. I.e., node 1 is told the result of node 2's decision making process. Thanks, John -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Monday, August 27, 2001 2:13 PM To: Fong Liaw Cc: ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Fong: Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both uni-directional and bi-directional together and uses the same port pool, then a PATH and a RESV may cross each other. I think that it should be legal based on current GMPLS specification. IF this scenario happens, GMPLS has to provide one standard way to handle this situation. Your suggestion works but it still involves the implementations of node 1 and node 2. Both nodes should interperate the same way. That means RESV message always wins PATH message. No problem. I assume that the I/O ports of bi-didrectional LSP are paired together, then suggested_label = upstream_label and suggested_label is hard binding. Note that contention happens in either this case or lack of resource. If suggested_label could be different upstream_label, no contention problem at all. -- Guangzhi Fong Liaw wrote: > Guangzhi > > The GMPLS contention resolution applies to the scenario > that two Path messages cross each other. Your example > have Resv and Path cross each other so the rule in the > contention resolution does not directly apply and is more > of a policy and implementation issue. > > Here is one possible solution and is within the > interpretation of the draft, IMHO. here it is. > If node 2 already sends Resv to node 1, LSP A should > be considered established and therefore LSP B should > be rejected by node 2. If node 2 hasn't sent back Resv, > LSP A is still in establishing mode and node 2 can resolve > the contention internally by rejecting LSP A or LSP B, based > on their setting up priority or it can change LSP A's > label and reprogram the cross-connect without ever noticed > by any external node. In both cases, node 2 is the one > that resolve this contention. Hope this helps. > > p.s. I think you meant to use LABEL_SET since > Suggested label is a suggestion, not a hard binding. > > Regards > -Fong > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Monday, August 27, 2001 6:17 AM > > To: ccamp@ops.ietf.org; mpls@UU.NET > > Cc: gli@research.att.com > > Subject: Question on GMPLS contentions resolution > > > > > > Dear GMPLS authors and all experts: > > > > During GMPLS last call, I posted the same question on the > > mailing list > > without response. Please somebody spend a little time and > > check with the > > following example? Something seems not clear when the current GMPLS > > contention resution schemes are applied on a framework with both > > bi-directional and uni-directional LSPs. Your clarification > > is very much > > appreciated. > > > > Sincerely, > > > > Guangzhi > > > > ------------------------------------------------------------- > > ------------------------------------- > > > > The issue arises because contention is resolved between > > bi-directional > > LSPs by the node with the higher node index while for uni-directional > > LSPs, contention is resolved by the downstream node. Consider the > > following example of two nodes with paired, bi-directional interfaces > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > node 2 with ID = 50. Node 1 uses label 1 for the > > transmitter port and > > label 2 for the receiver port; node 2 uses label 4 for the > > transmitter > > port and label 3 for the receiver port. We assume that a > > bi-directional LSP requires a single I/O interface. > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > to node 2, > > with the uni-directional LSP setup request arriving marginally before > > the bi-directional LSP. LSP A does not use a suggested > > label, and thus > > is assigned a label (port) by node 2. Label 3 is assigned, > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > Because node 1 has the higher node ID, node 2 will assume (due to the > > contention resolution rule for bi-directional LSPs) that LSP > > B wins the > > contention and thus label 3 is assigned to LSP B. Thus > > label 1 at node > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > LSPs have "won" the contention. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 14:10:22 -0700 Message-ID: <3B8AB7F4.2C91848D@research.att.com> Date: Mon, 27 Aug 2001 17:13:24 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Fong Liaw Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fong: Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both uni-directional and bi-directional together and uses the same port pool, then a PATH and a RESV may cross each other. I think that it should be legal based on current GMPLS specification. IF this scenario happens, GMPLS has to provide one standard way to handle this situation. Your suggestion works but it still involves the implementations of node 1 and node 2. Both nodes should interperate the same way. That means RESV message always wins PATH message. No problem. I assume that the I/O ports of bi-didrectional LSP are paired together, then suggested_label = upstream_label and suggested_label is hard binding. Note that contention happens in either this case or lack of resource. If suggested_label could be different upstream_label, no contention problem at all. -- Guangzhi Fong Liaw wrote: > Guangzhi > > The GMPLS contention resolution applies to the scenario > that two Path messages cross each other. Your example > have Resv and Path cross each other so the rule in the > contention resolution does not directly apply and is more > of a policy and implementation issue. > > Here is one possible solution and is within the > interpretation of the draft, IMHO. here it is. > If node 2 already sends Resv to node 1, LSP A should > be considered established and therefore LSP B should > be rejected by node 2. If node 2 hasn't sent back Resv, > LSP A is still in establishing mode and node 2 can resolve > the contention internally by rejecting LSP A or LSP B, based > on their setting up priority or it can change LSP A's > label and reprogram the cross-connect without ever noticed > by any external node. In both cases, node 2 is the one > that resolve this contention. Hope this helps. > > p.s. I think you meant to use LABEL_SET since > Suggested label is a suggestion, not a hard binding. > > Regards > -Fong > > > -----Original Message----- > > From: Guangzhi Li [mailto:gli@research.att.com] > > Sent: Monday, August 27, 2001 6:17 AM > > To: ccamp@ops.ietf.org; mpls@UU.NET > > Cc: gli@research.att.com > > Subject: Question on GMPLS contentions resolution > > > > > > Dear GMPLS authors and all experts: > > > > During GMPLS last call, I posted the same question on the > > mailing list > > without response. Please somebody spend a little time and > > check with the > > following example? Something seems not clear when the current GMPLS > > contention resution schemes are applied on a framework with both > > bi-directional and uni-directional LSPs. Your clarification > > is very much > > appreciated. > > > > Sincerely, > > > > Guangzhi > > > > ------------------------------------------------------------- > > ------------------------------------- > > > > The issue arises because contention is resolved between > > bi-directional > > LSPs by the node with the higher node index while for uni-directional > > LSPs, contention is resolved by the downstream node. Consider the > > following example of two nodes with paired, bi-directional interfaces > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > node 2 with ID = 50. Node 1 uses label 1 for the > > transmitter port and > > label 2 for the receiver port; node 2 uses label 4 for the > > transmitter > > port and label 3 for the receiver port. We assume that a > > bi-directional LSP requires a single I/O interface. > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > bi-directional LSP (LSP B). Both LSPs are going from node 1 > > to node 2, > > with the uni-directional LSP setup request arriving marginally before > > the bi-directional LSP. LSP A does not use a suggested > > label, and thus > > is assigned a label (port) by node 2. Label 3 is assigned, > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > Because node 1 has the higher node ID, node 2 will assume (due to the > > contention resolution rule for bi-directional LSPs) that LSP > > B wins the > > contention and thus label 3 is assigned to LSP B. Thus > > label 1 at node > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > LSPs have "won" the contention. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 11:15:25 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B90DD@ICARIAN> From: Fong Liaw To: 'Guangzhi Li' , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Question on GMPLS contentions resolution Date: Mon, 27 Aug 2001 11:13:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Guangzhi The GMPLS contention resolution applies to the scenario that two Path messages cross each other. Your example have Resv and Path cross each other so the rule in the contention resolution does not directly apply and is more of a policy and implementation issue. Here is one possible solution and is within the interpretation of the draft, IMHO. here it is. If node 2 already sends Resv to node 1, LSP A should be considered established and therefore LSP B should be rejected by node 2. If node 2 hasn't sent back Resv, LSP A is still in establishing mode and node 2 can resolve the contention internally by rejecting LSP A or LSP B, based on their setting up priority or it can change LSP A's label and reprogram the cross-connect without ever noticed by any external node. In both cases, node 2 is the one that resolve this contention. Hope this helps. p.s. I think you meant to use LABEL_SET since Suggested label is a suggestion, not a hard binding. Regards -Fong > -----Original Message----- > From: Guangzhi Li [mailto:gli@research.att.com] > Sent: Monday, August 27, 2001 6:17 AM > To: ccamp@ops.ietf.org; mpls@UU.NET > Cc: gli@research.att.com > Subject: Question on GMPLS contentions resolution > > > Dear GMPLS authors and all experts: > > During GMPLS last call, I posted the same question on the > mailing list > without response. Please somebody spend a little time and > check with the > following example? Something seems not clear when the current GMPLS > contention resution schemes are applied on a framework with both > bi-directional and uni-directional LSPs. Your clarification > is very much > appreciated. > > Sincerely, > > Guangzhi > > ------------------------------------------------------------- > ------------------------------------- > > The issue arises because contention is resolved between > bi-directional > LSPs by the node with the higher node index while for uni-directional > LSPs, contention is resolved by the downstream node. Consider the > following example of two nodes with paired, bi-directional interfaces > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > node 2 with ID = 50. Node 1 uses label 1 for the > transmitter port and > label 2 for the receiver port; node 2 uses label 4 for the > transmitter > port and label 3 for the receiver port. We assume that a > bi-directional LSP requires a single I/O interface. > > We consider two LSPs - a uni-directional LSP (LSP A) and a > bi-directional LSP (LSP B). Both LSPs are going from node 1 > to node 2, > with the uni-directional LSP setup request arriving marginally before > the bi-directional LSP. LSP A does not use a suggested > label, and thus > is assigned a label (port) by node 2. Label 3 is assigned, > corresponding to label 1 at node 1. At the same time, for LSP B (the > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > Because node 1 has the higher node ID, node 2 will assume (due to the > contention resolution rule for bi-directional LSPs) that LSP > B wins the > contention and thus label 3 is assigned to LSP B. Thus > label 1 at node > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > LSPs have "won" the contention. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 10:30:18 -0700 Message-ID: <3B8A84C4.E9A4A8C8@research.att.com> Date: Mon, 27 Aug 2001 13:35:00 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Eric Gray Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric: In GMPLS functional specification: (1) Two uni-directional LSPs establishment with label suggestion will result contention. Downstream node label assignment policy solves the contention. (2) Two bi-directional LSPs establishment with I/O pair restriction will result contention. LSP with master node label assignment wins the contention. (3) How about the contention between a uni-directional LSP and bi-directional LSP in the same framework? The application is not clear currently. But if you draw figures by yourself, you may find the issue. -- Guangzhi Eric Gray wrote: > Guangzhi, > > The thing I can't figure out, is where you're getting all of this from. > I can't help you with your issues, because - from where I sit - it looks > like you pulled them out of thin air. > > Could you provide more specific information about where you see the > these issues of contention being defined? > > -- > Eric Gray > > You wrote: > > > Dear GMPLS authors and all experts: > > > > During GMPLS last call, I posted the same question on the mailing list > > without response. Please somebody spend a little time and check with the > > following example? Something seems not clear when the current GMPLS > > contention resution schemes are applied on a framework with both > > bi-directional and uni-directional LSPs. Your clarification is very much > > appreciated. > > > > Sincerely, > > > > Guangzhi > > > > -------------------------------------------------------------------------------------------------- > > > > The issue arises because contention is resolved between bi-directional > > LSPs by the node with the higher node index while for uni-directional > > LSPs, contention is resolved by the downstream node. Consider the > > following example of two nodes with paired, bi-directional interfaces > > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > > node 2 with ID = 50. Node 1 uses label 1 for the transmitter port and > > label 2 for the receiver port; node 2 uses label 4 for the transmitter > > port and label 3 for the receiver port. We assume that a > > bi-directional LSP requires a single I/O interface. > > > > We consider two LSPs - a uni-directional LSP (LSP A) and a > > bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2, > > with the uni-directional LSP setup request arriving marginally before > > the bi-directional LSP. LSP A does not use a suggested label, and thus > > is assigned a label (port) by node 2. Label 3 is assigned, > > corresponding to label 1 at node 1. At the same time, for LSP B (the > > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > > Because node 1 has the higher node ID, node 2 will assume (due to the > > contention resolution rule for bi-directional LSPs) that LSP B wins the > > contention and thus label 3 is assigned to LSP B. Thus label 1 at node > > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > > LSPs have ?won? the contention. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 09:24:59 -0700 Message-Id: <200108271621.f7RGLd023399@merlot.juniper.net> To: Zhi-Wei Lin cc: ccamp@ops.ietf.org Subject: Re: Questions about GMPLS signaling and routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53442.998929299.1@juniper.net> Date: Mon, 27 Aug 2001 09:21:39 -0700 From: Yakov Rekhter Zhi-Wei, > >>1. One thing that came to mind when reading these docs was how these are > >>not well aligned with the GMPLS signaling discussions. For example, the > >>routing documents still mix "standard" and "non-standard" features > >>together (case of concatenation and arbitrary concatenation). > >> > > > > Please point to the specific text in the routing documents you'd like > > to change. > > Section 6.4.3 The text in 6.4.3 uses arbitrary concatenation *as an example*. Are you saying that we can't refer to arbitrary concatenation even for the purpose of an example ? > >>2. The split for the "interface switching capability" doesn't seem to > >>make sense. For example, why are there four PSC defined? Apparently this > >>is the text in -ccamp-gmpls-routing-00: > >> > >> If an interface is of type PSC-1 through PSC-4, it means that the > >> node receiving data over this interface can switch the received data > >> on a packet-by-packet basis. The various levels of PSC establish a > >> hierarchy of LSPs tunneled within LSPs. > >> > >> From what I understand LSP hierarchy allows any number of LSPs tunneled > >>within LSPs. Are we limiting the level of tunneling by defining these 4? > >> > > > > No, we are not limiting the level of tunneling by definining these 4. > > > Then what is the reason for four PSC levels? Can you explain what the > last sentence above mean? The last sentence above means that if one wants to have more than 4 levels of nested (PSC) LSPs, one could certainly do this. > What type of hierarchy is it referring to? The hierarchy of LSP regions, as described in draf-ietf-mpls-lsp-hierarchy. > >>3. Getting back to the switching capability type, the split of TDM > >>(which currenlty seems to only include SONET/SDH) and LSC does not work > >>well with OTN. For example, where would ODU switching belong, in TDM or > >>LSC? > >> > > > > Please explain why ODU fits neither in TDM nor in LSC. > > > > > The descriptions of TDM talks about SONET/SDH. It doesn't mention OTN. > Is it your intention then that TDM will also include ODU? My intention is first to get comments on this issue from other folks in the WG. > >>4. The the detailed docs ospf-gmpls-extensions and isis-gmpls-extensions > >>and ccamp-gmpls-routing describe min and max LSP bandwidth but when > >>looking at the descriptors, they only contain max LSP bandwidth info... > >> > > > > Please look again - the text includes min LSP b/w as well. > > OK I see. Thanks for pointing this out. Ok. > >>5. Going to the ccamp-gmpls-routing doc again (sorry for jumping > >>around...), section 6.4.7.4 talks of two type of SONET muxing hierarchy, > >>one with min of VT1.5 the other with min of VT2. I don't understand this > >>example at all. I am assuming for both cases that there will be support > >>for the intermediate muxing structures between VT1.5 and STS-192 (this > >>is probably STS-192c?). Then for the former case, it includes VT2. > >>Otherwise, if certain muxing structure are skipped then better specify > >>each mux hierachy explicitly. > >> > > > > The example illustrates the case where an interface supports more > > than one branch of the SONET muxing hierarchy. > > > Right, and again the second part of example talks about arbitrary concat > which is separated from the main document in GMPLS signaling suite of I-Ds. Right, and again it uses arbitrary concatenation just as *an example*, and not as a normative text. > > >>For example in section 6.4.7.5 and 6.4.7.6, you have > >> interface switching capability=LSC > >> encoding type=SONET ANSI T1.105 (BTW, please remove the date) > >> > > > > In the absence of any objections from the other folks, I'll be glad to > > remove the date. > > > > > >> reservable bandwidth=determined by DWDM > >>doesn't make sense as a combined unit. I think the encoding should be 8 > >>(lambda). > >> > > > > The encoding is "lambda" (as LSC stands for *Lambda* switch capable). > > > > > No I'm not referring to "interface switching capability", but "encoding > type". Right now, it's set to "SONET ANSI T1.105". I think it should be > "lambda" and you seem to agree with your answer above...? Small miscommunication - the encoding I was referring to was the encoding of the interface switching capability. The encoding you are referring to is the "encoding type". The reason why the encoding type is set to SONET is because in that particular example the DWDM constraints the signal to SONET. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 09:03:35 -0700 Message-ID: <3B8A6E9D.4E6FFCCA@sandburst.com> Date: Mon, 27 Aug 2001 12:00:29 -0400 From: Eric Gray MIME-Version: 1.0 To: Guangzhi Li Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question on GMPLS contentions resolution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Guangzhi, The thing I can't figure out, is where you're getting all of this from. I can't help you with your issues, because - from where I sit - it looks like you pulled them out of thin air. Could you provide more specific information about where you see the these issues of contention being defined? -- Eric Gray You wrote: > Dear GMPLS authors and all experts: > > During GMPLS last call, I posted the same question on the mailing list > without response. Please somebody spend a little time and check with the > following example? Something seems not clear when the current GMPLS > contention resution schemes are applied on a framework with both > bi-directional and uni-directional LSPs. Your clarification is very much > appreciated. > > Sincerely, > > Guangzhi > > -------------------------------------------------------------------------------------------------- > > The issue arises because contention is resolved between bi-directional > LSPs by the node with the higher node index while for uni-directional > LSPs, contention is resolved by the downstream node. Consider the > following example of two nodes with paired, bi-directional interfaces > (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and > node 2 with ID = 50. Node 1 uses label 1 for the transmitter port and > label 2 for the receiver port; node 2 uses label 4 for the transmitter > port and label 3 for the receiver port. We assume that a > bi-directional LSP requires a single I/O interface. > > We consider two LSPs - a uni-directional LSP (LSP A) and a > bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2, > with the uni-directional LSP setup request arriving marginally before > the bi-directional LSP. LSP A does not use a suggested label, and thus > is assigned a label (port) by node 2. Label 3 is assigned, > corresponding to label 1 at node 1. At the same time, for LSP B (the > bi-directional LSP) node 1 assigns label 2, with suggested label 1. > Because node 1 has the higher node ID, node 2 will assume (due to the > contention resolution rule for bi-directional LSPs) that LSP B wins the > contention and thus label 3 is assigned to LSP B. Thus label 1 at node > 1 (label 3 at node 2) has been assigned to two different LSPs. Both > LSPs have ?won? the contention. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Aug 2001 06:15:12 -0700 Message-ID: <3B8A4840.DCF7230E@research.att.com> Date: Mon, 27 Aug 2001 09:16:48 -0400 From: Guangzhi Li MIME-Version: 1.0 To: ccamp@ops.ietf.org, mpls@UU.NET Cc: gli@research.att.com Subject: Question on GMPLS contentions resolution Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear GMPLS authors and all experts: During GMPLS last call, I posted the same question on the mailing list without response. Please somebody spend a little time and check with the following example? Something seems not clear when the current GMPLS contention resution schemes are applied on a framework with both bi-directional and uni-directional LSPs. Your clarification is very much appreciated. Sincerely, Guangzhi -------------------------------------------------------------------------------------------------- The issue arises because contention is resolved between bi-directional LSPs by the node with the higher node index while for uni-directional LSPs, contention is resolved by the downstream node. Consider the following example of two nodes with paired, bi-directional interfaces (i.e., a transmitter/receiver pair of ports). Node 1 with ID=100 and node 2 with ID = 50. Node 1 uses label 1 for the transmitter port and label 2 for the receiver port; node 2 uses label 4 for the transmitter port and label 3 for the receiver port. We assume that a bi-directional LSP requires a single I/O interface. We consider two LSPs - a uni-directional LSP (LSP A) and a bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2, with the uni-directional LSP setup request arriving marginally before the bi-directional LSP. LSP A does not use a suggested label, and thus is assigned a label (port) by node 2. Label 3 is assigned, corresponding to label 1 at node 1. At the same time, for LSP B (the bi-directional LSP) node 1 assigns label 2, with suggested label 1. Because node 1 has the higher node ID, node 2 will assume (due to the contention resolution rule for bi-directional LSPs) that LSP B wins the contention and thus label 3 is assigned to LSP B. Thus label 1 at node 1 (label 3 at node 2) has been assigned to two different LSPs. Both LSPs have “won” the contention. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Aug 2001 14:30:16 -0700 Message-ID: From: Jonathan Lang To: "'Bhargava, Nidhi'" , "'ccamp@ops.ietf.org'" Cc: "Leach, Debi" Subject: RE: data link fsm in LMP draft Date: Fri, 24 Aug 2001 14:22:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Nidhi, Thanks for catching this. We will fix this in the next version. Thanks, Jonathan > -----Original Message----- > From: Bhargava, Nidhi [mailto:nidhi.bhargava@netplane.com] > Sent: Friday, August 24, 2001 11:49 AM > To: 'ccamp@ops.ietf.org' > Cc: Leach, Debi > Subject: data link fsm in LMP draft > > > Hi all, > There seems to be some inconsistency in draft > draft-ietf-ccamp-lmp-00.txt . > In section 8.3.2 "Data Link Events" defines the various > events in the data > link FSM. > The events evTestRet and evVerifyAbrt have been assigned the > same number 11. > whereas each of them should be given a separate number. This > leads to some > confusion > in the data link FSMs.(section 8.3.3. and 8.3.4) > > Nidhi > ------------------------------- > Nidhi Bhargava > NetPlane Systems Inc. > A Mindspeed Technologies Company > Tel: + 1.781.329.3200 x5353 > Web: http://www.netplane.com > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Aug 2001 11:53:31 -0700 Message-ID: <87009604743AD411B1F600508BA0F95952C075@XOVER.dedham.mindspeed.com> From: "Bhargava, Nidhi" To: "'ccamp@ops.ietf.org'" Cc: "Leach, Debi" Subject: data link fsm in LMP draft Date: Fri, 24 Aug 2001 14:48:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, There seems to be some inconsistency in draft draft-ietf-ccamp-lmp-00.txt . In section 8.3.2 "Data Link Events" defines the various events in the data link FSM. The events evTestRet and evVerifyAbrt have been assigned the same number 11. whereas each of them should be given a separate number. This leads to some confusion in the data link FSMs.(section 8.3.3. and 8.3.4) Nidhi ------------------------------- Nidhi Bhargava NetPlane Systems Inc. A Mindspeed Technologies Company Tel: + 1.781.329.3200 x5353 Web: http://www.netplane.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Aug 2001 12:23:20 -0700 Message-ID: <47D99458148BD411BE2E0090276155790228CB34@njc240po04.mt.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Heiles Juergen'" , "'ccamp@ops.ietf.org'" Subject: RE: Comments on GMPLS generalized signaling/Question on gmpls-sdh -sonet last call Date: Thu, 23 Aug 2001 15:21:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 1. mpls-generalized-signaling-05: I agree with the following mail from Juergen. I had previously commented to remove the version numbers and SDH/SONET/ETSI/ANSI specific labels. I thought it was agreed and so was surprised to see it in the latest draft. These generalized LSP encoding types are archaic and overly restrictive for allowing global connections. Also, the G-PID is technology specific, as Juergen states. Including it in the generalized-signaling draft creates confusion as there is overlap/redundancy with the technology specific parameters. The generalized-signaling draft should only provide general LSP encoding types; referring to the technology-specific documents for specifics. 2. gmpls-sonet-sdh-01 Is this document for final comment by Aug 27 or will it be revised first? Deborah Brungard AT&T -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Thursday, August 23, 2001 10:45 AM To: 'ccamp@ops.ietf.org' Subject: Comments on GMPLS generalized signaling I am sending this e-mail with comments on draft-ietf-mpls-generalized-signaling again as I haven't received any comments on it and the proposed changes were not introduce in the 05 version. In addition under LSP Encoding Type the date should be removed from SDH and SONET type, which makes the second SDH and SONET type (11 and 12) superfluous. This was already mentioned at the meeting. Further Digital Wrapper should be changed to G.709. Regards Juergen > -----Original Message----- > From: Heiles Juergen [SMTP:Juergen.Heiles@icn.siemens.de] > Sent: Monday, May 07, 2001 5:08 PM > To: mpls@UU.NET; ccamp@ops.ietf.org > Subject: Comments on G-PID > > I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt. > > Juergen > > > > The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID introduction text > "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload." > > Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required. > > Now to the detailed comments: > The following G-PIDs have to be removed as the mappings are not defined: > 8 Bit synchronous mapping of E3 > 9 Byte synchronous mapping of E3 > 12 Byte synchronous mapping of DS2/T2 > > As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore: > 19 Same as 12 but in a VC-12 > 20 Same as 13 but in a VC-12 > 21 Same as 14 but in a VC-12 > > SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals): > The whole set of SONET/SDH G-PIDs: > Asynchronous mapping of E4 PDH framed > Asynchronous mapping of E4 SDH framed > Asynchronous mapping of E4 transparent > Asynchronous mapping of DS3 M23 > Asynchronous mapping of DS3 C-Bit Parity > Asynchronous mapping of DS3 transparent > Asynchronous mapping of E3 PDH framed > Asynchronous mapping of E3 SDH framed > Asynchronous mapping of E3 transparent > Asynchronous mapping of DS2/T2 > Bit synchronous mapping of DS2/T2 > Asynchronous mapping of E1 framed > Asynchronous mapping of E1 transparent > Byte synchronous mapping of E1 framed > Byte synchronous mapping of 31 * 64kbit/s > Asynchronous mapping of DS1/T1 SF > Asynchronous mapping of DS1/T1 ESF > Asynchronous mapping of DS1/T1 transparent > Bit synchronous mapping of DS1/T1 SF > Bit synchronous mapping of DS1/T1 ESF > Bit synchronous mapping of DS1/T1 transparent > Byte synchronous mapping of DS1/T1 SF > Byte synchronous mapping of DS1/T1 ESF > VTG/TUG > STS Group/AUG (in a STS/STM LSP) > Line/Multiplex Section (in a STS/STM LSP) > Section/Regenerator Section (in a STS/STM LSP) > POS - No Scrambling, 16 bit CRC > POS - No Scrambling, 32 bit CRC > POS - Scrambling, 16 bit CRC > POS - Scrambling, 32 bit CRC > ATM mapping > FDDI mapping > DQDB mapping > GFP mapping > LAPS IP (X.85) > LAPS Ethernet (X.86) > SDL, set-reset scrambler > SDL, self-synchronizing scrambler > O.181 test signal > > Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be the payload of an PDH LSP again, only of a SONET/SDH LSP and this is already defined. So they should be removed. > > > The G-PIDs > > 33 Ethernet Lambda, Fiber specific > 34 SDH Lambda, Fiber " > 35 SONET Lambda, Fiber " > 36 Digital Wrapper Lambda, Fiber " > 37 Lambda Fiber " > are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown? > "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Aug 2001 12:14:35 -0700 Message-ID: <3B8554F5.4060307@lucent.com> Date: Thu, 23 Aug 2001 15:09:41 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org Subject: Re: Questions about GMPLS signaling and routing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yakov, >>1. One thing that came to mind when reading these docs was how these are >>not well aligned with the GMPLS signaling discussions. For example, the >>routing documents still mix "standard" and "non-standard" features >>together (case of concatenation and arbitrary concatenation). >> > > Please point to the specific text in the routing documents you'd like > to change. > Section 6.4.3 >>2. The split for the "interface switching capability" doesn't seem to >>make sense. For example, why are there four PSC defined? Apparently this >>is the text in -ccamp-gmpls-routing-00: >> >> If an interface is of type PSC-1 through PSC-4, it means that the >> node receiving data over this interface can switch the received data >> on a packet-by-packet basis. The various levels of PSC establish a >> hierarchy of LSPs tunneled within LSPs. >> >> From what I understand LSP hierarchy allows any number of LSPs tunneled >>within LSPs. Are we limiting the level of tunneling by defining these 4? >> > > No, we are not limiting the level of tunneling by definining these 4. > Then what is the reason for four PSC levels? Can you explain what the last sentence above mean? What type of hierarchy is it referring to? thanks for any clarification >>3. Getting back to the switching capability type, the split of TDM >>(which currenlty seems to only include SONET/SDH) and LSC does not work >>well with OTN. For example, where would ODU switching belong, in TDM or >>LSC? >> > > Please explain why ODU fits neither in TDM nor in LSC. > The descriptions of TDM talks about SONET/SDH. It doesn't mention OTN. Is it your intention then that TDM will also include ODU? >>4. The the detailed docs ospf-gmpls-extensions and isis-gmpls-extensions >>and ccamp-gmpls-routing describe min and max LSP bandwidth but when >>looking at the descriptors, they only contain max LSP bandwidth info... >> > > Please look again - the text includes min LSP b/w as well. > OK I see. Thanks for pointing this out. >>5. Going to the ccamp-gmpls-routing doc again (sorry for jumping >>around...), section 6.4.7.4 talks of two type of SONET muxing hierarchy, >>one with min of VT1.5 the other with min of VT2. I don't understand this >>example at all. I am assuming for both cases that there will be support >>for the intermediate muxing structures between VT1.5 and STS-192 (this >>is probably STS-192c?). Then for the former case, it includes VT2. >>Otherwise, if certain muxing structure are skipped then better specify >>each mux hierachy explicitly. >> > > The example illustrates the case where an interface supports more > than one branch of the SONET muxing hierarchy. > Right, and again the second part of example talks about arbitrary concat which is separated from the main document in GMPLS signaling suite of I-Ds. >>For example in section 6.4.7.5 and 6.4.7.6, you have >> interface switching capability=LSC >> encoding type=SONET ANSI T1.105 (BTW, please remove the date) >> > > In the absence of any objections from the other folks, I'll be glad to > remove the date. > > >> reservable bandwidth=determined by DWDM >>doesn't make sense as a combined unit. I think the encoding should be 8 >>(lambda). >> > > The encoding is "lambda" (as LSC stands for *Lambda* switch capable). > No I'm not referring to "interface switching capability", but "encoding type". Right now, it's set to "SONET ANSI T1.105". I think it should be "lambda" and you seem to agree with your answer above...? >>7. I can understand using the "interface switching capability >>descriptor" for routing exchange information. But why has this been >>added to the GMPLS signaling? It still escapes me. Can I ask who would >>be strongly opposed to removing the "switching type" from GMPLS >>signaling and what the impact would be that breaks this? I can think of >>a case where maybe within the network, some subnetwork may want to use a >>different "switching type" as specified by the source, e.g., because >>that's all they support, or it's more efficient to support... >> > > This has to do with the ability of a given interface to support > more than one switching capability. At signaling time you may want > to select a particular one. So you're saying that a user may request a STS-1 service and wish to specify the switching type as LSC (for example), and not the typical TDM? I'm assuming that once the "switching type" is specified, it remains constant for the entire connection? If it is, then I'm assuming that the source node will be specifying what "switching type" to use. What happens when a connection goes over multiple AS, where the first AS uses TDM to support the connection but the second AS uses LSC to support the connection (for example, for an OC-48 service request)? Does specifying the switching type limit service for this case? Thanks for further clarifications... Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Aug 2001 07:49:31 -0700 Message-ID: From: Heiles Juergen To: "'ccamp@ops.ietf.org'" Subject: Comments on GMPLS generalized signaling Date: Thu, 23 Aug 2001 16:45:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I am sending this e-mail with comments on draft-ietf-mpls-generalized-signaling again as I haven't received any comments on it and the proposed changes were not introduce in the 05 version. In addition under LSP Encoding Type the date should be removed from SDH and SONET type, which makes the second SDH and SONET type (11 and 12) superfluous. This was already mentioned at the meeting. Further Digital Wrapper should be changed to G.709. Regards Juergen > -----Original Message----- > From: Heiles Juergen [SMTP:Juergen.Heiles@icn.siemens.de] > Sent: Monday, May 07, 2001 5:08 PM > To: mpls@UU.NET; ccamp@ops.ietf.org > Subject: Comments on G-PID > > I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt. > > Juergen > > > > The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID introduction text > "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload." > > Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required. > > Now to the detailed comments: > The following G-PIDs have to be removed as the mappings are not defined: > 8 Bit synchronous mapping of E3 > 9 Byte synchronous mapping of E3 > 12 Byte synchronous mapping of DS2/T2 > > As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore: > 19 Same as 12 but in a VC-12 > 20 Same as 13 but in a VC-12 > 21 Same as 14 but in a VC-12 > > SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals): > The whole set of SONET/SDH G-PIDs: > Asynchronous mapping of E4 PDH framed > Asynchronous mapping of E4 SDH framed > Asynchronous mapping of E4 transparent > Asynchronous mapping of DS3 M23 > Asynchronous mapping of DS3 C-Bit Parity > Asynchronous mapping of DS3 transparent > Asynchronous mapping of E3 PDH framed > Asynchronous mapping of E3 SDH framed > Asynchronous mapping of E3 transparent > Asynchronous mapping of DS2/T2 > Bit synchronous mapping of DS2/T2 > Asynchronous mapping of E1 framed > Asynchronous mapping of E1 transparent > Byte synchronous mapping of E1 framed > Byte synchronous mapping of 31 * 64kbit/s > Asynchronous mapping of DS1/T1 SF > Asynchronous mapping of DS1/T1 ESF > Asynchronous mapping of DS1/T1 transparent > Bit synchronous mapping of DS1/T1 SF > Bit synchronous mapping of DS1/T1 ESF > Bit synchronous mapping of DS1/T1 transparent > Byte synchronous mapping of DS1/T1 SF > Byte synchronous mapping of DS1/T1 ESF > VTG/TUG > STS Group/AUG (in a STS/STM LSP) > Line/Multiplex Section (in a STS/STM LSP) > Section/Regenerator Section (in a STS/STM LSP) > POS - No Scrambling, 16 bit CRC > POS - No Scrambling, 32 bit CRC > POS - Scrambling, 16 bit CRC > POS - Scrambling, 32 bit CRC > ATM mapping > FDDI mapping > DQDB mapping > GFP mapping > LAPS IP (X.85) > LAPS Ethernet (X.86) > SDL, set-reset scrambler > SDL, self-synchronizing scrambler > O.181 test signal > > Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be the payload of an PDH LSP again, only of a SONET/SDH LSP and this is already defined. So they should be removed. > > > The G-PIDs > > 33 Ethernet Lambda, Fiber specific > 34 SDH Lambda, Fiber " > 35 SONET Lambda, Fiber " > 36 Digital Wrapper Lambda, Fiber " > 37 Lambda Fiber " > are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown? > "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Aug 2001 10:53:17 -0700 Message-Id: <200108221751.f7MHpi073205@merlot.juniper.net> To: Zhi-Wei Lin cc: ccamp@ops.ietf.org Subject: Re: Questions about GMPLS signaling and routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21117.998502704.1@juniper.net> Date: Wed, 22 Aug 2001 10:51:44 -0700 From: Yakov Rekhter Zhi-Wei, > Hi all, > > Below are 7 questions/concerns I have...Looking forward to your replies! > These questions apply basically to the set of GMPLS routing docs and to > the GMPLS signaling docs... > > > ---------- > 1. One thing that came to mind when reading these docs was how these are > not well aligned with the GMPLS signaling discussions. For example, the > routing documents still mix "standard" and "non-standard" features > together (case of concatenation and arbitrary concatenation). Please point to the specific text in the routing documents you'd like to change. > ---------- > 2. The split for the "interface switching capability" doesn't seem to > make sense. For example, why are there four PSC defined? Apparently this > is the text in -ccamp-gmpls-routing-00: > > If an interface is of type PSC-1 through PSC-4, it means that the > node receiving data over this interface can switch the received data > on a packet-by-packet basis. The various levels of PSC establish a > hierarchy of LSPs tunneled within LSPs. > > From what I understand LSP hierarchy allows any number of LSPs tunneled > within LSPs. Are we limiting the level of tunneling by defining these 4? No, we are not limiting the level of tunneling by definining these 4. > Also there should be no difference among these four regardless of > hierarchy. I see hierarchy as layers... > > If you were to define PSC as four types, then I can also state that even > for other switching capabilities, you might also have LSPs tunneled > within LSPs of those, and therefore using the same logic should define > four types for TDM, four types for L2TP, etc. > > ---------- > 3. Getting back to the switching capability type, the split of TDM > (which currenlty seems to only include SONET/SDH) and LSC does not work > well with OTN. For example, where would ODU switching belong, in TDM or > LSC? Please explain why ODU fits neither in TDM nor in LSC. > ---------- > 4. The the detailed docs ospf-gmpls-extensions and isis-gmpls-extensions > and ccamp-gmpls-routing describe min and max LSP bandwidth but when > looking at the descriptors, they only contain max LSP bandwidth info... Please look again - the text includes min LSP b/w as well. > ---------- > 5. Going to the ccamp-gmpls-routing doc again (sorry for jumping > around...), section 6.4.7.4 talks of two type of SONET muxing hierarchy, > one with min of VT1.5 the other with min of VT2. I don't understand this > example at all. I am assuming for both cases that there will be support > for the intermediate muxing structures between VT1.5 and STS-192 (this > is probably STS-192c?). Then for the former case, it includes VT2. > Otherwise, if certain muxing structure are skipped then better specify > each mux hierachy explicitly. The example illustrates the case where an interface supports more than one branch of the SONET muxing hierarchy. > > ---------- > 6. For multi-service capable interfaces (by the way, I think switching > capability is not associated with an interface but with the node/fabric > itself. For example, an interface such as a trib card is likely limited > to what signal it supports, but anyway I digress), I think each > switching capability should be advertised as a separate "interface > switching capability descriptor". Agreed, and that is exactly what is in the current routing drafts. > For example in section 6.4.7.5 and 6.4.7.6, you have > interface switching capability=LSC > encoding type=SONET ANSI T1.105 (BTW, please remove the date) In the absence of any objections from the other folks, I'll be glad to remove the date. > reservable bandwidth=determined by DWDM > doesn't make sense as a combined unit. I think the encoding should be 8 > (lambda). The encoding is "lambda" (as LSC stands for *Lambda* switch capable). > ---------- > 7. I can understand using the "interface switching capability > descriptor" for routing exchange information. But why has this been > added to the GMPLS signaling? It still escapes me. Can I ask who would > be strongly opposed to removing the "switching type" from GMPLS > signaling and what the impact would be that breaks this? I can think of > a case where maybe within the network, some subnetwork may want to use a > different "switching type" as specified by the source, e.g., because > that's all they support, or it's more efficient to support... This has to do with the ability of a given interface to support more than one switching capability. At signaling time you may want to select a particular one. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 Aug 2001 10:04:53 -0700 Message-ID: <3B83E44E.7080300@lucent.com> Date: Wed, 22 Aug 2001 12:56:46 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Questions about GMPLS signaling and routing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Below are 7 questions/concerns I have...Looking forward to your replies! These questions apply basically to the set of GMPLS routing docs and to the GMPLS signaling docs... ---------- 1. One thing that came to mind when reading these docs was how these are not well aligned with the GMPLS signaling discussions. For example, the routing documents still mix "standard" and "non-standard" features together (case of concatenation and arbitrary concatenation). ---------- 2. The split for the "interface switching capability" doesn't seem to make sense. For example, why are there four PSC defined? Apparently this is the text in -ccamp-gmpls-routing-00: If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs. From what I understand LSP hierarchy allows any number of LSPs tunneled within LSPs. Are we limiting the level of tunneling by defining these 4? Also there should be no difference among these four regardless of hierarchy. I see hierarchy as layers... If you were to define PSC as four types, then I can also state that even for other switching capabilities, you might also have LSPs tunneled within LSPs of those, and therefore using the same logic should define four types for TDM, four types for L2TP, etc. ---------- 3. Getting back to the switching capability type, the split of TDM (which currenlty seems to only include SONET/SDH) and LSC does not work well with OTN. For example, where would ODU switching belong, in TDM or LSC? ---------- 4. The the detailed docs ospf-gmpls-extensions and isis-gmpls-extensions and ccamp-gmpls-routing describe min and max LSP bandwidth but when looking at the descriptors, they only contain max LSP bandwidth info... ---------- 5. Going to the ccamp-gmpls-routing doc again (sorry for jumping around...), section 6.4.7.4 talks of two type of SONET muxing hierarchy, one with min of VT1.5 the other with min of VT2. I don't understand this example at all. I am assuming for both cases that there will be support for the intermediate muxing structures between VT1.5 and STS-192 (this is probably STS-192c?). Then for the former case, it includes VT2. Otherwise, if certain muxing structure are skipped then better specify each mux hierachy explicitly. ---------- 6. For multi-service capable interfaces (by the way, I think switching capability is not associated with an interface but with the node/fabric itself. For example, an interface such as a trib card is likely limited to what signal it supports, but anyway I digress), I think each switching capability should be advertised as a separate "interface switching capability descriptor". For example in section 6.4.7.5 and 6.4.7.6, you have interface switching capability=LSC encoding type=SONET ANSI T1.105 (BTW, please remove the date) reservable bandwidth=determined by DWDM doesn't make sense as a combined unit. I think the encoding should be 8 (lambda). ---------- 7. I can understand using the "interface switching capability descriptor" for routing exchange information. But why has this been added to the GMPLS signaling? It still escapes me. Can I ask who would be strongly opposed to removing the "switching type" from GMPLS signaling and what the impact would be that breaks this? I can think of a case where maybe within the network, some subnetwork may want to use a different "switching type" as specified by the source, e.g., because that's all they support, or it's more efficient to support... Thanks Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Aug 2001 04:05:37 -0700 Message-Id: <200108171102.HAA23263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: forces@peach.ease.lsoft.com, mpls@uu.net, ip-optical@lists.bell-labs.com, ccamp@ops.ietf.org, iporpr@external.cisco.com, gsmp@revnetworks.com, ppvpn@zephion.net, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-amenyo-consion-sigint-optnet-00.txt Date: Fri, 17 Aug 2001 07:02:36 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ConSION: Control & Signaling Intelligence Overlay Ntworks for Optical Networking Author(s) : J. Amenyo Filename : draft-amenyo-consion-sigint-optnet-00.txt Pages : 15 Date : 16-Aug-01 When one extrapolates from the ongoing evolutionary trends of IP router / switch development and its role in the build-out of optical core, edge, access and enterprise networks, it is reasonable to reach the almost inescapable conclusion that within a few years, there will be a complete physical separation of the commercial equipment embodying various concerns, aspects, roles and functions of data communications, Namely, 1. Separate equipment for transport (transmission, switching and multiplexing) and traffic forwarding. 2. Separate equipment concerned with control, signaling, traffic engineering, provisioning, protection and restoration control, as well as, traffic and flow management, (generalized 'softswitches'). 3. Separate equipment for network management, operations support, measurement & metering, OAMP, inter-OSS, engineering management (including performance management, availability management, security management, accounting management), as well as life cycle support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-amenyo-consion-sigint-optnet-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-amenyo-consion-sigint-optnet-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-amenyo-consion-sigint-optnet-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010816080136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-amenyo-consion-sigint-optnet-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-amenyo-consion-sigint-optnet-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010816080136.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Aug 2001 01:03:50 -0700 Cc: "'Kireeti Kompella'" , ccamp@ops.ietf.org Message-ID: <3B7CCEE8.169E38F3@lucent.com> Date: Fri, 17 Aug 2001 09:59:36 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Heiles Juergen Original-CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: AW: CCAMP minutes Content-Type: multipart/mixed; boundary="------------E78B628325D4F811D2BDCB42" This is a multi-part message in MIME format. --------------E78B628325D4F811D2BDCB42 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Kireeti, I agree with Juergen's comment. That's what I said. Regards, Maarten Heiles Juergen wrote: > = > I think Maartens comment on concatenation conversion is stated wrong. > He said that concatenation converion is a standard feature (defined in = G.707 and G.783) and that we should first focus on support for standard f= eatures before defining support for proprietary features. So put it in. > = > Juergen > = > > -----Urspr=FCngliche Nachricht----- > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > Gesendet: Mittwoch, 8. August 2001 18:14 > > An: ccamp@ops.ietf.org > > Betreff: CCAMP minutes > > > > > > Many thanks to Sudheer for his detailed minutes and to Ed for his > > colorful minutes (pity I can't publish them unexpurgated). Between > > the two, we have excellent coverage. > > > > The following is mostly from Sudheer, with comments from Ed prefaced > > by "EK:" My own comments in []. The minutes are reproduced almost > > as is. Note that the numbers when asking for consensus, while > > faithfully reported, are *not* in themselves significant. The goal > > is rough consensus, not a majority. > > > > Kireeti. > > ------- > > > > CCAMP Minutes: > > > > Milestones: > > > > To dos: > > > > - Make framework as working group document > > - What to do about or extend the working group for > > o Inter-AS signaling > > o Optical VPNs > > o G.709 > > o Measurement (routing, LMP, OLI, ?) > > o MIBs > > o Security (new design team) > > > > Charter & draft updates: > > > > Routing drafts are broken as "common" and "Protocol-specific" > > ISIS will be dealt in the ISIS working group > > OSPF will be dealt in the CCAMP working group > > (EK: (mike goes dead, we can thankfully no longer hear > > kireeti babble)) > > > > Protection and restoration - ? > > > > Hierarchical (multi-area) TE drafts > > - Where will the protocol work be done? > > o Wei - Can decide after the TE WG. > > (EK: kireeti says protocol work belongs in ccamp; te-wg chairs agree.= ) > > > > Update from the DT: > > No presentation made. > > > > GMPLS update (Lou): > > (Generalized-signaling, RSVP-TE, CR-LDP) > > > > Changes: > > - More on the technology specific is separated and > > covered in length > > - SONET/SDH is moved out to be included in another draft > > - Issued joint CCAMP and MPLS WG last calls > > > > Detailed changes: > > - Technical error in LDP (?) > > - Re-introduced Switching type in the G-PID > > o To support multiple switching types on the same interface > > - Administrative status information TLV is added > > o To support state of the LSP (in Path/RESV) and > > o To notify the status of an LSP otherwise > > - Changes made in the scope of "control channel separation" > > o Identification of data channels when the channel is > > not uniquely > > identified by control channel > > o Handling of control channel failures that do not impact data > > channels > > Next changes: > > - Need more comments > > - Ask IANA assignment for CR-LDP and RSVP-TE related informatio= n > > - Some issues resolved > > o Missing timeout > > o Minor changes to > > o G-PID change to avoid duplicity for SONET (?) > > (EK: kireeti cant run powerpoint to save himself.) > > > > Discussion: > > > > 3 weeks from today [i.e., by August 27] will close on the comments an= d > > move forward. > > > > SONET/SDH (Eric): > > > > GMPLS-SONET-SDH: > > > > - This is the separated document from GMPLS signaling > > draft specific to > > SONET/SDH > > - Flexible concatenation is NOT part of this document > > - Mostly editorial, re-organizing, correctness etc. > > - Appendices are provided for different implementation > > mechanisms > > supported using this draft > > - Other modifications > > o Improve the interoperability > > o Etc. > > - Targeted for informational RFC [not this doc, the new > > doc, see below] > > - Move for IANA assignment > > - Which appendices to be moved > > o Contiguous concatenation > > o Transparency (per byte) > > o Virtual concatenation > > o Signaling for non-std concatenation > > o Appendix 1: Explained > > > > Discussion: > > > > Comment: > > > > (EK: comment on if certain part should be on standards track > > or information) > > [Clarification: the appendices that refer to items that are non-ITU-T= > > standards get moved to another *informational* document.] > > > > Concatenation conversion (Eric): > > > > Problem: > > - To avoid wastage of timeslots due to different > > concatenation mechanisms > > > > Solution: > > - SDH/SONET "Virtual Concatenation" > > Proposed a contiguous concatenation (C) to virtual concatenatio= n > > (V) conversion mechanism and extensions > > - Realize ingress and egress aggregator > > - Advertise the converting nodes using routing protocols > > - Use signaling protocols to use this information to > > setup the path > > > > Signaling: > > - C->V is performed at the first converter and V->C is > > performed at > > the end converter (before the destination) > > - 5 possible concatenation mechanisms can be negotiated > > o CC e-to-e > > o CC->VC > > o VC->CC > > o VC e-to-e > > o ? [CC->VC->CC] > > > > Discussion: > > o Are there such converters available? > > o Eric says at least two vendors have. He sees this > > evolving more > > and more. > > o How many see this as useful function? - 10-15 (EK: 10) > > o How many think this is should be done here? - 10 > > o How many think this makes sense? - 5 (EK: 8) > > o How many think this does not make sense? - 2 (EK: 3) > > o Why not in IPO? > > o These are signaling extensions. > > o Technology specific things should be in their > > respective groups > > CCAMP is working on GMPLS > > o What about VCs taking different paths? > > o This does not include such paths > > o (Marteen) This is a non-standard feature support. Why > > not also look > > at supporting standard mechanism using GMPLS? This is > > part of the > > transport network -- put it in. > > > > Conclusion: > > - WG chair's inclination is to make this as a WG draft. > > But since not > > many people understand these concepts let us take this to the > > mailing list before the decision. > > > > G 709 (Dimitri): - Fontana-ccamp-gmpls-g709 > > > > What? > > - Propose GMPLS based control plane for G709 > > - ITU-T G709 is getting standardized at ITU. Lets work > > on the control > > plane for it. > > > > Why? > > - G709 is a tera-bit tech for the future > > - GMPLS solves the signaling mechanisms to control such > > a technology > > > > Changes: > > - G709 OTN is independent of the control plane > > - GMPLS provides all the hooks without major paradigm shift > > > > Propose a new G709 drafts similar to SONET draft > > > > This is only about signaling extensions > > Routing extensions for G709 are under consideration > > > > Changes: > > > > - Document name has changed > > - Encoding type > > - Signaling type > > - GPID value list > > - .. > > > > Further changes > > - Move features not covered by G709 in a dedicated draft > > - OOS field description to be completed in appendix > > - RMT/RNC to be adopted in RMT/RNC and RVC field > > > > Conclusions: > > - Propose to be working group document > > - Features not in the document to be moved to extensions -- > > Kireeti - This should be driven more by what is in the > > ITU G709 document. > > (EK: kireeti says that its not a vote; if its in g709 > > it should be in > > the document.) > > [KK: Clarification: stuff that is not standardized by the ITU > > should be moved to another document.] > > > > Decision - Consensus in the room is to adopt as a WG > > document. But will be > > taken to the mailing list before the final decision. > > (EK: majority think this should be a wg document and that the > > signalling part belongs here.) > > > > GMPLS TE MIB (Adrian) > > > > Existing TE MIB (which is in the final stages in MPLS WG) is > > only for MPLS. > > (EK: clarification this is the mpls te mib) > > GMPLS extensions are provided in this draft. > > This effort should not impede MPLS TE MIB progress. > > This should belong in CCAMP. > > Lot of interest on this work (by implementers, operators etc.) > > Work includes TE and LSR MIBs for GMPLS > > Updates will be provided next month > > > > Make this CCAMP WG document > > > > Discussion: > > > > (AD) Bert: Make a MIB framework document with the gamut of MIBs to pu= t > > them in perspective. Make sure that there will not be an > > overlap in these MIBs. > > Decision - Wait for the overview draft. > > (EK: bert before you extend or build on mpls mib document > > best to let that > > document go through iesg last call so that it stabilizes > > before you extend > > it. kireeti should we not make it a wg document until mplste mib > > settles...bert yes.) > > > > > > GMPLS Architecture draft (Eric) > > > > Was accepted as a CCAMP WG document > > Gives GMPLS overview and provides how the building blocks are glued. > > Changes: > > - TOC, open issues, L2SC added etc. > > - Many changes including scope of UNI, GASTN/GASON in the GMPLS= > > context > > Proposed sections: > > - G709 > > - OLI > > - Protection and restoration > > o UPTO THIS IS IN THE CHARTER - What is below will be on > > consensus from the DT and further discussion. > > - Multicast > > - Inter-area TE > > - Inter-domain > > - VPN (OVPN) section > > - Etc.. > > > > Discussion: > > > > - (Jim Luciani) Make sure there will be no overlap on > > ASON work in the > > IPO group. - OK > > (EK: lots of overlap with work thats being done elsewhere and > > work with > > person doing req documents from cienna on interarea work.) > > - (Marteen) Wait for the ITU to come on consensus on > > OTN and Protection > > - Make ASON relationship clarified in this document in > > terms of scope. > > - Kireeti: Track what OIF and ITU work is being done. > > But we need to > > work on the signaling part should be done at CCAMP to > > move the work. > > - No consensus on the draft status > > [Editor to remove out-of-scope subjects. Draft status is "close to W= G > > Last Call".] > > > > Framework document (Yongwang Xu): > > > > - Control plane is discussed from different perspectives > > - What are the fundamental changes betn pkt and ckt > > based network ctrl > > plane design > > - NW layering -- based on tech, BW mismatch, cost etc > > - NW partitioning -- administrative (tech, geo, oper reasons) > > - Overall -- reduce the tools to a common integrated > > control plane > > > > Propose: > > - Make this a WG document > > Discussion: > > - Greg: How is this different from what is being done > > in IPO? - More > > number of authors and carriers > > - Eric: > > - ?: What about reliability of the control plane and > > bandwidth broker? -- > > Kireeti: Bandwidth broker is not in the charter. > > Reliability of the > > control plane will be discussed only after what is to > > be done is clear. > > > > Consensus: Will take to the mailing list with the assumption > > that people are > > not sure. > > (EK: kireeti: how many think we need gmpls framework document about 1= 0 > > against 5.) > > > > Framework on GMPLS based CP for SONET/SDH networks (Greg): > > > > - Asked by many people to explain what are the problems > > with SONET using > > GMPLS > > > > Discussion: > > > > - Kireeti: Will be a WG document as informational. > > > > LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt > > > > - Remove CCId from TE link related messages > > - Modified the LMP common header to include > > o CCId specific messages > > o The TE link Id for specific msgs > > - Removed ChFailNack > > - Removed LMPCapabilities TLV > > - Next steps: > > o Remove link MUX type > > o Add on graceful restart procedures > > > > Discussion: > > > > - Why ChFailNack removed? -- Always the upstream node > > worries about it. > > So we can remove this msg without loss of info. > > - What about tech specific mechanisms (for e.g., as > > specified by the > > OIF UNI for in band)? -- Since this involves protocol specific > > extensions, make a specific document. > > - How many are implementing? -- 10 (EK: 15) > > - How many carriers are interested in putting in the > > lab? -- None (EK: 5) > > - How many think after the next rev there should a last > > call? -- 4 > > Wait for the next update and see if it is stable. > > > > LMP MIB: > > > > - Moved Link Summary retransmit values ... > > - TE link table uses if id > > > > Discussion: > > > > - Will this be a WG draft? -- Accept as a WG draft > > (EK: does this have to wait for mplste mib to move > > forward...kireeti views it > > as being 95% independant from the other mib so is available > > to move forward. > > kireeti takes poll on if it should be wg document...20 for > > zero against.) > > > > - Request: Send the dependency to the other TE components to th= e > > mailing list > > > > OLI (Andre) > > > > > > - Main objectives > > o Enhanced fault detection/recovery for transparent optical XCs= > > ? PXCs have limited detection mechanisms unlike SONET > > equipment > > o Enhanced discovery of link characteristics for > > optical networks in > > general > > ? Reduce manual errors in configuring > > o General requirements > > ? Simple protocol to report health > > ? Defined parameters > > ? Extensible to future techs like G709 > > ? Reliable > > ? Secure > > ? No assumption on 1:1 relation between client and server > > > > - Requirements > > o Neighbor discovery > > o Control Channel Management > > o OLI synchronization > > o Connectivity discovery > > o Fault management > > o Property discovery > > > > Discussion: > > > > - Angela: Is this required to run only OOB? -- Not necessarily.= > > Could be used for opaque. > > o Neighbor disc should be coordinated? - That was the intentio= n > > - Sham: Why this in IETF? -- Rough consensus to work in IETF. > > This is because this work falls under measurement part of CCMP.= > > > > (EK: question: why should this work be done in ietf,no ip > > involved.....because > > it has an ip control plane thats why. randy: iesg goes around > > seriously..its here not because ip transport is being used to > > control the > > device, but that its carrying ip traffic.... > > kireeti: not enough that they are IP > > protocols but that they grow IP networks everywhere. hands on > > if we should > > be working on this or not..about 40 hands for 15 against.) > > > > > > NTIP > > > > - Added auto-discovery > > - Reliable transport -- TCP - X > > - Simple -- Assymetric relationship - ??? > > - CC Maintenance -- Keep alive > > - Auto-dsc -- Supported > > - Fault notification -- Supported > > - Trace monitoring -- Supported > > - Resynchronization -- Supported - X > > - Fast notification -- Supported - X > > - Issues with LMP-DWDM > > o Assumes LMP exists > > o Employs > > > > LMP-DWDM > > > > Discussion: > > > > - Vijay: To have less new code in a box, I prefer LMP-DWDM. > > - WG chairs: Move with LMP-DWDM if we move forward (i.e., if we= > > are not stepping on ITU foot.) > > - Osama: What is the procedure to follow up this > > formally with ITU. > > o Randy: We have a formal channels > > > > (EK: kireeti: needs duedilligence that we > > will move forward with lmpdwdm if we move forward with > > anything because the > > itu work might cover it making it not necessary to do this > > work at all. > > question? how do we make sure this isnt work they are doing > > randy: we have formal channels in place to ask the itu. > > question: formal channels are in place...comment that it > > doesnt get used > > enough, more common that liason statements are used. randy: > > there are many > > other channels being used far more frequently then liason > > papers so nothing > > more formal or other channel is necessary0 > > > > > > Tunnel trace protocol: > > > > - Protocol is completely stateless > > - Refined PIO and TIO > > - ? > > - Issues: > > o Works only for tunnels that have TTL expiration > > o GTTP should support MTU discovery > > > > Discussion: > > > > - Consensus that this is a required concept. > > - No consensus that this should a WG draft. > > - Will be discussed on the mailing list. > > > > (EK: kireeti: useful document? 20 yes zero no...is this > > document useful > > should this be a wg document 6 yes zero no.) > > > > > = > ---------------------------------------------------------------------= ----------- > = > Part 1.2 Type: application/ms-tnef > Encoding: base64 --------------E78B628325D4F811D2BDCB42 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:mvissers@lucent.com 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 --------------E78B628325D4F811D2BDCB42-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 Aug 2001 21:07:24 -0700 From: "Irfan Lateef" To: ip-optical@lists.bell-labs.com Cc: ccamp@ops.ietf.org Bcc: Subject: Distributed vs Centralized Date: Fri, 17 Aug 2001 00:05:07 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Bala, In draft-many-ip-optical-framework-03.txt section 9.5 Distributed vs. Centralized Provisioning "Centralization aids in implementing complex capacity optimization schemes, and may be the near-term provisioning solution in optical networks with interconnected multi-vendor optical sub-networks." I also happen to subscribe to this view, but I need some help. Are there any implementations of this approach in the industry which can be quoted as successful. Appreciate your response. Irfan Lateef _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 Aug 2001 07:19:44 -0700 Date: Thu, 16 Aug 2001 07:14:32 -0700 (PDT) From: Kireeti Kompella Message-Id: <200108161414.HAA21836@kummer.juniper.net> To: ccamp@ops.ietf.org, Juergen.Heiles@icn.siemens.de, kireeti@juniper.net Subject: Re: AW: CCAMP minutes Thanks, Juergen. I heard the same from Eric Mannie -- just haven't had time to double-check with Maarten. Hopefully, he'll read your email and confirm. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Aug 2001 06:49:42 -0700 Message-Id: <4.3.2.7.2.20010815094639.0180ceb8@bucket.cisco.com> Date: Wed, 15 Aug 2001 09:47:22 -0700 To: "Wijnen, Bert (Bert)" From: Thomas Nadeau Subject: RE: CCAMP WG action items Cc: Kireeti Kompella , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >So we agreed this work could be a WG work item. >Would still be good to include some words about >it in the overview of documents on all the MPLS >MIBs that are in the works I have a section in the forthcoming MPLS Management Framework document about the LMP MIB. --Tom >Bert > > > -----Original Message----- > > From: Thomas Nadeau [mailto:tnadeau@cisco.com] > > Sent: woensdag 15 augustus 2001 0:07 > > To: Kireeti Kompella > > Cc: ccamp@ops.ietf.org > > Subject: Re: CCAMP WG action items > > > > > > > > Hi, > > > > >5) Tom and co-authors to send mail to the list stating the degree > > > of independence of LMP MIB to the MPLS TE MIB complex. > > > > At present, the LMP MIB is totally independent of the > > MPLS TE MIB. The only interaction is via the Link Bundling > > MIB, which contains TE links/link bundles which either > > MIB may utilize, but don't necessarily have to. > > > > --Tom > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Aug 2001 14:03:03 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D3DA412@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Thomas Nadeau , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: CCAMP WG action items Date: Tue, 14 Aug 2001 22:54:41 +0200 MIME-Version: 1.0 Content-Type: text/plain So we agreed this work could be a WG work item. Would still be good to include some words about it in the overview of documents on all the MPLS MIBs that are in the works Bert > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@cisco.com] > Sent: woensdag 15 augustus 2001 0:07 > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: CCAMP WG action items > > > > Hi, > > >5) Tom and co-authors to send mail to the list stating the degree > > of independence of LMP MIB to the MPLS TE MIB complex. > > At present, the LMP MIB is totally independent of the > MPLS TE MIB. The only interaction is via the Link Bundling > MIB, which contains TE links/link bundles which either > MIB may utilize, but don't necessarily have to. > > --Tom > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Aug 2001 12:11:39 -0700 Message-Id: <4.3.2.7.2.20010809054711.00b91a90@127.0.0.1> Date: Tue, 14 Aug 2001 15:06:32 -0700 To: Kireeti Kompella From: Thomas Nadeau Subject: Re: CCAMP WG action items Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >5) Tom and co-authors to send mail to the list stating the degree > of independence of LMP MIB to the MPLS TE MIB complex. At present, the LMP MIB is totally independent of the MPLS TE MIB. The only interaction is via the Link Bundling MIB, which contains TE links/link bundles which either MIB may utilize, but don't necessarily have to. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 14 Aug 2001 05:26:48 -0700 From: i-nishioka@cb.jp.nec.com To: ccamp@ops.ietf.org Subject: LSP Deletion and Admin status Reply-To: i-nishioka@cb.jp.nec.com Date: Tue, 14 Aug 2001 21:17:01 +0900 Message-Id: <20010814211701i-nishioka@optsys1.cb.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hi, I have questions about LSP deletion procedure with Admin status object in draft-ietf-mpls-generalized-rsvp-04. As described in section 7, LSP state is changed to "down" by admin status object in Path/Resv Msg, before deletion from ingress node One question; How to transpot Admin status object in case of deletion from egress node? Another question; Why does Round-trip procedure (Path->Resv procedure) need, to change LSP state? I think round trip procedure is different from UNI 1.0 signaling procedure, because signaling to change LSP state is only one-way in UNI 1.0. Thanks in advance, Itaru Nishioka. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Aug 2001 12:48:51 -0700 Message-ID: <3B782EAE.ACC74502@lucent.com> Date: Mon, 13 Aug 2001 15:46:54 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org Subject: Re: CCAMP WG action items Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Lou, I've had several people explain the "switching type" field to me, and yet I still don't think that it is needed. Can you or anyone else provide a concrete example of how this is used? For example, across the UNI, within the network (I-NNI), across two domains (E-NNI). Thanks for any clarification. Zhi BTW, which comment was this field addressing? Lou Berger wrote: > > At 12:15 PM 8/8/01, Kireeti Kompella wrote: > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-04.txt > > draft-ietf-mpls-generalized-signaling-05.txt > > Here's a summary of what changed in this rev of the drafts: > o Fixed Label Set format (for LDP) > [Increased field size to match LDP type field size] > o Added Switching type of LSP being requested > [This field was in an earlier version of the drafts] > [Is required for links that support multiple switching types] > o Added Administrative Status Information > [To address last call comments (notably from the > carrier community)] > o Added section on Control Channel Separation > Covers: > - Separation of control and data channels > [To address last call comments (notably from the > carrier community)] > - Restoration of state post control channel failures > [Again to address last call comments, is required by > control / data channel separation.] > o Other minor editorial and clarification text > [some based on comments received] > > So far the following changes are planned based on comments received since > the above were issued: > - Update LSP Encoding Type to remove redundant SONET/SDH types > - Use a new object type rather than suggested_label when supporting restart > - to simplify restart processing > - Add some clarification text on error processing and when an LSP is usable > - Add IANA considerations section > > That's it, > Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Aug 2001 12:12:55 -0700 Message-Id: <4.3.2.7.2.20010813150941.01c90620@bucket.cisco.com> Date: Mon, 13 Aug 2001 15:10:07 -0700 To: "Martin Dubuc" From: Thomas Nadeau Subject: RE: Comments on LMP MIB draft Cc: "Sameh M. Elsharkawy" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Just for reference, I am going to paste in the original question, as some may not understand if they can't open the attachment: Comments/Questions on LMP MIB draft (draft-dubuc-lmp-mib-02.txt) ================================================================ 1. lmpTeLinkAdminStatus is missing from the TE Link table entry. 2. lmpDataBearingLinkAdminStatus is missing from the Data Bearing Link table entry. >The administrative status of TE links and data-bearing links is not >defined in the LMP MIB. Each TE link and data-bearing link has an >associated entry in the ifTable. The adminStatus for the associated >entry in the ifTable should be used to control the administrative status >of TE links and data-bearing links. > >Martin > > >-----Original Message----- >From: Sameh M. Elsharkawy [mailto:selsharkawy@fwion.com] >Sent: Friday, August 10, 2001 5:07 PM >To: Martin Dubuc; sudheer@nayna.com; tnadeau@cisco.com; >jplang@calient.net >Subject: Comments on LMP MIB draft > > > >Hi, > >My name Sameh Elsharkawy, I am working with FirstWave Intelligent >Optical >Networks. I am working on implementing the LMP protocol on a DWDM switch >and >I had some comments/questions about the last version of the LMP MIB >draft. I >appreciate your feedback on these issues. > >N.B: The comment file is attached. > >Thanks > >Sameh M. Elsharkawy >Senior Member of Technical Staff >FirstWave Intelligent Optical Networks >(301) 345-2137 x1034 > > > <> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Aug 2001 11:55:49 -0700 Content-Class: urn:content-classes:message Subject: RE: Comments on LMP MIB draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C12428.9094DE6A" Date: Mon, 13 Aug 2001 14:48:38 -0400 Message-ID: Thread-Topic: Comments on LMP MIB draft Thread-Index: AcEh4WqdWjoZjsEjSeWyuCDmELWmOwCNVe6A From: "Martin Dubuc" To: "Sameh M. Elsharkawy" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C12428.9094DE6A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sameh, The administrative status of TE links and data-bearing links is not defined in the LMP MIB. Each TE link and data-bearing link has an associated entry in the ifTable. The adminStatus for the associated entry in the ifTable should be used to control the administrative status of TE links and data-bearing links.=20 Martin -----Original Message----- From: Sameh M. Elsharkawy [mailto:selsharkawy@fwion.com] Sent: Friday, August 10, 2001 5:07 PM To: Martin Dubuc; sudheer@nayna.com; tnadeau@cisco.com; jplang@calient.net Subject: Comments on LMP MIB draft Hi, My name Sameh Elsharkawy, I am working with FirstWave Intelligent Optical Networks. I am working on implementing the LMP protocol on a DWDM switch and I had some comments/questions about the last version of the LMP MIB draft. I appreciate your feedback on these issues. N.B: The comment file is attached. Thanks Sameh M. Elsharkawy=20 Senior Member of Technical Staff FirstWave Intelligent Optical Networks (301) 345-2137 x1034 <>=20 ------_=_NextPart_001_01C12428.9094DE6A Content-Type: text/plain; name="lmpMIBComments.txt" Content-Transfer-Encoding: base64 Content-Description: lmpMIBComments.txt Content-Disposition: attachment; filename="lmpMIBComments.txt" Q29tbWVudHMvUXVlc3Rpb25zIG9uIExNUCBNSUIgZHJhZnQgKGRyYWZ0LWR1YnVjLWxtcC1taWIt MDIudHh0KQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQoxLiBsbXBUZUxpbmtBZG1pblN0YXR1cyBpcyBtaXNzaW5nIGZy b20gdGhlIFRFIExpbmsgdGFibGUgZW50cnkuDQoNCjIuIGxtcERhdGFCZWFyaW5nTGlua0FkbWlu U3RhdHVzIGlzIG1pc3NpbmcgZnJvbSB0aGUgRGF0YSBCZWFyaW5nDQpMaW5rIHRhYmxlIGVudHJ5 Lg0KDQo= ------_=_NextPart_001_01C12428.9094DE6A-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Aug 2001 03:38:08 -0700 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: AW: CCAMP minutes Date: Mon, 13 Aug 2001 12:35:22 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C123E3.A7C2E2C0" 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_01C123E3.A7C2E2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think Maartens comment on concatenation conversion is stated wrong. He said that concatenation converion is a standard feature (defined in = G.707 and G.783) and that we should first focus on support for standard = features before defining support for proprietary features. So put it = in. Juergen > -----Urspr=FCngliche Nachricht----- > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > Gesendet: Mittwoch, 8. August 2001 18:14 > An: ccamp@ops.ietf.org > Betreff: CCAMP minutes >=20 >=20 > Many thanks to Sudheer for his detailed minutes and to Ed for his > colorful minutes (pity I can't publish them unexpurgated). Between > the two, we have excellent coverage. >=20 > The following is mostly from Sudheer, with comments from Ed prefaced > by "EK:" My own comments in []. The minutes are reproduced almost > as is. Note that the numbers when asking for consensus, while > faithfully reported, are *not* in themselves significant. The goal > is rough consensus, not a majority. >=20 > Kireeti. > ------- >=20 > CCAMP Minutes: >=20 > Milestones: >=20 > To dos: >=20 > - Make framework as working group document > - What to do about or extend the working group for > o Inter-AS signaling > o Optical VPNs > o G.709 > o Measurement (routing, LMP, OLI, ?) > o MIBs > o Security (new design team) >=20 > Charter & draft updates: >=20 > Routing drafts are broken as "common" and "Protocol-specific" > ISIS will be dealt in the ISIS working group > OSPF will be dealt in the CCAMP working group > (EK: (mike goes dead, we can thankfully no longer hear=20 > kireeti babble)) >=20 > Protection and restoration - ? >=20 > Hierarchical (multi-area) TE drafts > - Where will the protocol work be done? > o Wei - Can decide after the TE WG. > (EK: kireeti says protocol work belongs in ccamp; te-wg chairs = agree.) >=20 > Update from the DT: > No presentation made. >=20 > GMPLS update (Lou): > (Generalized-signaling, RSVP-TE, CR-LDP) >=20 > Changes: > - More on the technology specific is separated and=20 > covered in length > - SONET/SDH is moved out to be included in another draft > - Issued joint CCAMP and MPLS WG last calls >=20 > Detailed changes: > - Technical error in LDP (?) > - Re-introduced Switching type in the G-PID > o To support multiple switching types on the same interface > - Administrative status information TLV is added > o To support state of the LSP (in Path/RESV) and > o To notify the status of an LSP otherwise > - Changes made in the scope of "control channel separation" > o Identification of data channels when the channel is=20 > not uniquely > identified by control channel > o Handling of control channel failures that do not impact data > channels > Next changes: > - Need more comments > - Ask IANA assignment for CR-LDP and RSVP-TE related = information > - Some issues resolved > o Missing timeout > o Minor changes to > o G-PID change to avoid duplicity for SONET (?) > (EK: kireeti cant run powerpoint to save himself.) >=20 > Discussion: >=20 > 3 weeks from today [i.e., by August 27] will close on the comments = and > move forward. >=20 > SONET/SDH (Eric): >=20 > GMPLS-SONET-SDH: >=20 > - This is the separated document from GMPLS signaling=20 > draft specific to > SONET/SDH > - Flexible concatenation is NOT part of this document > - Mostly editorial, re-organizing, correctness etc. > - Appendices are provided for different implementation=20 > mechanisms > supported using this draft > - Other modifications > o Improve the interoperability > o Etc. > - Targeted for informational RFC [not this doc, the new=20 > doc, see below] > - Move for IANA assignment > - Which appendices to be moved > o Contiguous concatenation > o Transparency (per byte) > o Virtual concatenation > o Signaling for non-std concatenation > o Appendix 1: Explained >=20 > Discussion: >=20 > Comment: >=20 > (EK: comment on if certain part should be on standards track=20 > or information) > [Clarification: the appendices that refer to items that are non-ITU-T > standards get moved to another *informational* document.] >=20 > Concatenation conversion (Eric): >=20 > Problem: > - To avoid wastage of timeslots due to different=20 > concatenation mechanisms >=20 > Solution: > - SDH/SONET "Virtual Concatenation" > Proposed a contiguous concatenation (C) to virtual concatenation > (V) conversion mechanism and extensions > - Realize ingress and egress aggregator > - Advertise the converting nodes using routing protocols > - Use signaling protocols to use this information to=20 > setup the path >=20 > Signaling: > - C->V is performed at the first converter and V->C is=20 > performed at > the end converter (before the destination) > - 5 possible concatenation mechanisms can be negotiated > o CC e-to-e > o CC->VC > o VC->CC > o VC e-to-e > o ? [CC->VC->CC] >=20 > Discussion: > o Are there such converters available? > o Eric says at least two vendors have. He sees this=20 > evolving more > and more. > o How many see this as useful function? - 10-15 (EK: 10) > o How many think this is should be done here? - 10 > o How many think this makes sense? - 5 (EK: 8) > o How many think this does not make sense? - 2 (EK: 3) > o Why not in IPO? > o These are signaling extensions. > o Technology specific things should be in their=20 > respective groups > CCAMP is working on GMPLS > o What about VCs taking different paths? > o This does not include such paths > o (Marteen) This is a non-standard feature support. Why=20 > not also look > at supporting standard mechanism using GMPLS? This is=20 > part of the > transport network -- put it in. >=20 > Conclusion: > - WG chair's inclination is to make this as a WG draft.=20 > But since not > many people understand these concepts let us take this to the > mailing list before the decision. >=20 > G 709 (Dimitri): - Fontana-ccamp-gmpls-g709 >=20 > What? > - Propose GMPLS based control plane for G709 > - ITU-T G709 is getting standardized at ITU. Lets work=20 > on the control > plane for it. >=20 > Why? > - G709 is a tera-bit tech for the future > - GMPLS solves the signaling mechanisms to control such=20 > a technology >=20 > Changes: > - G709 OTN is independent of the control plane > - GMPLS provides all the hooks without major paradigm shift >=20 > Propose a new G709 drafts similar to SONET draft >=20 > This is only about signaling extensions > Routing extensions for G709 are under consideration >=20 > Changes: >=20 > - Document name has changed > - Encoding type > - Signaling type > - GPID value list > - .. >=20 > Further changes > - Move features not covered by G709 in a dedicated draft > - OOS field description to be completed in appendix > - RMT/RNC to be adopted in RMT/RNC and RVC field >=20 > Conclusions: > - Propose to be working group document > - Features not in the document to be moved to extensions -- > Kireeti - This should be driven more by what is in the=20 > ITU G709 document. > (EK: kireeti says that its not a vote; if its in g709=20 > it should be in > the document.) > [KK: Clarification: stuff that is not standardized by the ITU > should be moved to another document.] >=20 > Decision - Consensus in the room is to adopt as a WG=20 > document. But will be > taken to the mailing list before the final decision. > (EK: majority think this should be a wg document and that the > signalling part belongs here.) >=20 > GMPLS TE MIB (Adrian) >=20 > Existing TE MIB (which is in the final stages in MPLS WG) is=20 > only for MPLS. > (EK: clarification this is the mpls te mib) > GMPLS extensions are provided in this draft. > This effort should not impede MPLS TE MIB progress. > This should belong in CCAMP. > Lot of interest on this work (by implementers, operators etc.) > Work includes TE and LSR MIBs for GMPLS > Updates will be provided next month >=20 > Make this CCAMP WG document >=20 > Discussion: >=20 > (AD) Bert: Make a MIB framework document with the gamut of MIBs to = put > them in perspective. Make sure that there will not be an=20 > overlap in these MIBs. > Decision - Wait for the overview draft. > (EK: bert before you extend or build on mpls mib document=20 > best to let that > document go through iesg last call so that it stabilizes=20 > before you extend > it. kireeti should we not make it a wg document until mplste mib > settles...bert yes.) >=20 >=20 > GMPLS Architecture draft (Eric) >=20 > Was accepted as a CCAMP WG document > Gives GMPLS overview and provides how the building blocks are glued. > Changes: > - TOC, open issues, L2SC added etc. > - Many changes including scope of UNI, GASTN/GASON in the GMPLS > context > Proposed sections: > - G709 > - OLI > - Protection and restoration > o UPTO THIS IS IN THE CHARTER - What is below will be on > consensus from the DT and further discussion. > - Multicast > - Inter-area TE > - Inter-domain > - VPN (OVPN) section > - Etc.. >=20 > Discussion: >=20 > - (Jim Luciani) Make sure there will be no overlap on=20 > ASON work in the > IPO group. - OK > (EK: lots of overlap with work thats being done elsewhere and=20 > work with > person doing req documents from cienna on interarea work.) > - (Marteen) Wait for the ITU to come on consensus on=20 > OTN and Protection > - Make ASON relationship clarified in this document in=20 > terms of scope. > - Kireeti: Track what OIF and ITU work is being done.=20 > But we need to > work on the signaling part should be done at CCAMP to=20 > move the work. > - No consensus on the draft status > [Editor to remove out-of-scope subjects. Draft status is "close to = WG > Last Call".] >=20 > Framework document (Yongwang Xu): >=20 > - Control plane is discussed from different perspectives > - What are the fundamental changes betn pkt and ckt=20 > based network ctrl > plane design > - NW layering -- based on tech, BW mismatch, cost etc > - NW partitioning -- administrative (tech, geo, oper reasons) > - Overall -- reduce the tools to a common integrated=20 > control plane >=20 > Propose: > - Make this a WG document > Discussion: > - Greg: How is this different from what is being done=20 > in IPO? - More > number of authors and carriers > - Eric: > - ?: What about reliability of the control plane and=20 > bandwidth broker? -- > Kireeti: Bandwidth broker is not in the charter.=20 > Reliability of the > control plane will be discussed only after what is to=20 > be done is clear. >=20 > Consensus: Will take to the mailing list with the assumption=20 > that people are > not sure. > (EK: kireeti: how many think we need gmpls framework document about = 10 > against 5.) >=20 > Framework on GMPLS based CP for SONET/SDH networks (Greg): >=20 > - Asked by many people to explain what are the problems=20 > with SONET using > GMPLS >=20 > Discussion: >=20 > - Kireeti: Will be a WG document as informational. >=20 > LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt >=20 > - Remove CCId from TE link related messages > - Modified the LMP common header to include > o CCId specific messages > o The TE link Id for specific msgs > - Removed ChFailNack > - Removed LMPCapabilities TLV > - Next steps: > o Remove link MUX type > o Add on graceful restart procedures >=20 > Discussion: >=20 > - Why ChFailNack removed? -- Always the upstream node=20 > worries about it. > So we can remove this msg without loss of info. > - What about tech specific mechanisms (for e.g., as=20 > specified by the > OIF UNI for in band)? -- Since this involves protocol specific > extensions, make a specific document. > - How many are implementing? -- 10 (EK: 15) > - How many carriers are interested in putting in the=20 > lab? -- None (EK: 5) > - How many think after the next rev there should a last=20 > call? -- 4 > Wait for the next update and see if it is stable. >=20 > LMP MIB: >=20 > - Moved Link Summary retransmit values ... > - TE link table uses if id >=20 > Discussion: >=20 > - Will this be a WG draft? -- Accept as a WG draft > (EK: does this have to wait for mplste mib to move=20 > forward...kireeti views it > as being 95% independant from the other mib so is available=20 > to move forward. > kireeti takes poll on if it should be wg document...20 for=20 > zero against.) >=20 > - Request: Send the dependency to the other TE components to = the > mailing list >=20 > OLI (Andre) >=20 >=20 > - Main objectives > o Enhanced fault detection/recovery for transparent optical XCs > ? PXCs have limited detection mechanisms unlike SONET > equipment > o Enhanced discovery of link characteristics for=20 > optical networks in > general > ? Reduce manual errors in configuring > o General requirements > ? Simple protocol to report health > ? Defined parameters > ? Extensible to future techs like G709 > ? Reliable > ? Secure > ? No assumption on 1:1 relation between client and server >=20 > - Requirements > o Neighbor discovery > o Control Channel Management > o OLI synchronization > o Connectivity discovery > o Fault management > o Property discovery >=20 > Discussion: >=20 > - Angela: Is this required to run only OOB? -- Not necessarily. > Could be used for opaque. > o Neighbor disc should be coordinated? - That was the = intention > - Sham: Why this in IETF? -- Rough consensus to work in IETF. > This is because this work falls under measurement part of CCMP. >=20 > (EK: question: why should this work be done in ietf,no ip=20 > involved.....because > it has an ip control plane thats why. randy: iesg goes around > seriously..its here not because ip transport is being used to=20 > control the > device, but that its carrying ip traffic....=20 > kireeti: not enough that they are IP > protocols but that they grow IP networks everywhere. hands on=20 > if we should > be working on this or not..about 40 hands for 15 against.) >=20 >=20 > NTIP >=20 > - Added auto-discovery > - Reliable transport -- TCP - X > - Simple -- Assymetric relationship - ??? > - CC Maintenance -- Keep alive > - Auto-dsc -- Supported > - Fault notification -- Supported > - Trace monitoring -- Supported > - Resynchronization -- Supported - X > - Fast notification -- Supported - X > - Issues with LMP-DWDM > o Assumes LMP exists > o Employs >=20 > LMP-DWDM >=20 > Discussion: >=20 > - Vijay: To have less new code in a box, I prefer LMP-DWDM. > - WG chairs: Move with LMP-DWDM if we move forward (i.e., if we > are not stepping on ITU foot.) > - Osama: What is the procedure to follow up this=20 > formally with ITU. > o Randy: We have a formal channels >=20 > (EK: kireeti: needs duedilligence that we > will move forward with lmpdwdm if we move forward with=20 > anything because the > itu work might cover it making it not necessary to do this=20 > work at all. > question? how do we make sure this isnt work they are doing > randy: we have formal channels in place to ask the itu. > question: formal channels are in place...comment that it > doesnt get used > enough, more common that liason statements are used. randy:=20 > there are many > other channels being used far more frequently then liason=20 > papers so nothing > more formal or other channel is necessary0 >=20 >=20 > Tunnel trace protocol: >=20 > - Protocol is completely stateless > - Refined PIO and TIO > - ? > - Issues: > o Works only for tunnels that have TTL expiration > o GTTP should support MTU discovery >=20 > Discussion: >=20 > - Consensus that this is a required concept. > - No consensus that this should a WG draft. > - Will be discussed on the mailing list. >=20 > (EK: kireeti: useful document? 20 yes zero no...is this=20 > document useful > should this be a wg document 6 yes zero no.) >=20 >=20 ------_=_NextPart_000_01C123E3.A7C2E2C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhsKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcIAA0ADAAjABYAAQAzAQEggAMADgAAANEHCAAN AAwAIwAZAAEANgEBCYABACEAAAA4QzUyRDcwM0JFOEZENTExQTdFQzAwMDhDNzFFQUYxRQBVBwEE gAEAEgAAAEFXOiBDQ0FNUCBtaW51dGVzAHsFAQ2ABAACAAAAAgACAAEDkAYADCYAADAAAAADAAFu AAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgABgAggBgAAAAAAwAAAAAAAAEYA AAAAVIUAAAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwACgAgg BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAAOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA AAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAA EIUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAA AABGAAAAABiFAAAAAAAAAgEJEAEAAAD5IAAA9SAAAAhLAABMWkZ1MThxJAMACgByY3BnMTI14jID Q3RleAVBAQMB908KgAKkA+MCAGNoCsBz8GV0MCAHEwKAD/MAUH8EVghVB7IRxQ5RAwEQxzL3BgAG wxHFMwRGEMkS2xHT2wjvCfc7GL8OMDURwgxgzmMAUAsJAWQzNhFQC6agIEkgdGgLgGsF0N5hCsAO sAYxBaBtB4ACMMYgAiAekW5jYR5RH5B6aR8kdgSQAJAfIQQAIEZzAZAOsGQgdwNgbsxnLgqiCoBI ZSEAC3C/IWAdsB+QH08gUiClYSECxG5kCxEgZmUfkAhwPSJQKAEBC4AhUQuAIEdwLjcwNySwJRAm ojisMyknAyLDdyJRaAhgOmwlUWkREAVAAhBjdcMEIB8hc3VwcBhhKUH3BcAk7gQgYgEQBbAiUCYD 9QuAZynbcANgLYAIkAGQVHJ5KycuBgBvLXB1tQVAaS8xbiHVIeRKClCMcmcJ8C+6PiAtMcJmVREQ LYBcJxDQIbBs1Q3gaCJQTgDQaAUQEOAWdDHDMUZWAiA6IEsfKQAJ4B/gNMADcHBlbBkLYCBbAMAD EHRvOmJrNORAanUDADWActIuJkB0XTFGRweQCfCVAQB0NLBNL1B0dylgEGgsIDguwEF1ZwcpgAVA AdAwMSAxOKg6MTQxRkE0oWMjQJ01cEAtoC6wLdFmLgWwemcxRkIRMBjAASA0sEPAQ0FNUCBtC4Av IO8HkDFGPm4eEG4uICLBHeDnBCA2MAYAdWQy8BMhKmL/HcAEIDhxNgEhUT31J7Qu8N5FJVFBZDFG GDNmKLBCVzwocC9QLiAdkCNAbicvBUAvEAJgBABoHaFlbb4gNvAOwC8QMKAhMikuwP888ihQMMYx oEbhHaA5ADlA1yhREPAgYCAOwGM1kR7iuwWgIGFhMLAh1T7IVDLx+wIQNaBvA/AskSDhBGAhEP5s LiEDYUDGSZEvUEbAHqX/BCBN40NRLYABEADQCYAxRoJiLiAiRUs6IkgQPk0uIEzgHzJPNSaBW12/ SAFMYkJnJcEYwC2BZBtw7yFRB0BNcjFGYVKhLrEHsP5vDrAitEkiPhAG0CBxIXD/MvADoFXQNmAs kSpiIxE4Qf0p4HNJkR3AQiAxRlBQTtF/RMFNsVRBGGEJgDlAVAIqum5WYComckbiESBsIGC5IPFp ZwMAJiBGAXRTFfxnbwdAMUYg4QNgOaBO8u9Y11vRJLEAwGoFsEWhS1//NNVhBzHDM+gxRj2UOMA+ E/46Pu9CESEQAiBlP0xBLvB2ZE2AZw8tSBBpkx4Qa+9MgUsQB4A5AHId8FXRaqL3LIIJwAhgcGgx KXAe0mkO/ldWs2giJLAG4C8hBbEOwX84UUkTaywqYTFGLvBplEnzAjAEkC1BBfBdAgdALIEdcI5P BTBdYQMgVlBO1z5XcQYmsjlwjk0lgCngexjAHtMoXxEf4CGwOUBMIz3AOUBPTEk5QD8p+XW/SUJ0 XwZgKXBgwiXgvyZAB+ABAF0CHaAlgG14x+dkBxDxcaEgJiwgSxABgP1HIHAlIGUvMZEIAHejfkT9 U+RiA2BqIFfiUUAeogIgc1GQJxIiUANgNjAYMS2XMjAFkF1CIjFGSVOEgP9OsTWgK7EsIQdAL2JJ E4SEw2s6MUZPU1BGhM9JE/c9lIZ/MYIoUWEl4D3waiH/XiAHkYVRW1EoUUYBQCRahP1b0CAYUCGw EyEy8ArFMYLPNmUrsAGgAmBlKXyvguL/BZAf4ycSK4E2MEsQH+NpgPo/Pm5ICJEKwBDgc9OLYCso sB/gLVQBYSegVEX/gKVsjzLwJcGIE0kiLYGDE59rE4hTZsGS13EGV2U1MP1pgEMDkQWBIpAiUH5x EyF7SSKVgVcmsIqbjwYicHlfBCCYDo3CUqM7Yzt8US2+dyygEOEpASSwCcIuj//OVX7DTdRJIkRU fydWUH9QEjhBISEf8gDAAQBhD0ddPcBMBfB+tCXgTAhgKb1/Jyg4ICZASxAywHoJgKeDYHImOUBS U3QgLZWAgTlAQ1ItTERQoU//fbGN4X8YaYcr8h8hSSMFkPZoW9AYUGcuIIN2INNUUH8KwCEzJxJD +CBhJlRKgWcDHbCsDlNPTkVUL/hTREhNNCBgIWBuUkCh+4UhC4BjCkABACZjAHBWYPeXIX5ErA5J BBAKUCFgYKD/C4AFQD2UJxKmY5xAjbBV0Osi8QdAbD5fREHmEOGrv/1pklSt0nPTBJADYAXAJoHv qkEl4Hi4aYZSoCC3kVR2flNOwZRBLJFFsDWAhaZH8C1QSURwjmgRKeaUw/8LUCJRwDspk0kiInAH gCZx53GhUFKsDkFkPfEEAD0g/x/RSgEhEimBC4AqYQDAH+PoVExWJINktMHB38LoeyETHxBmSROm gL3xJoFQ4R+QaC9SRamQJ6PKT/8u8FvRBpBAEsg3zFEDkczC/7VTA/HGX6uFpPOFpgTwLaD/zDOC Ab+CAyC7IiZAAyCvNf8f8YP3cQcBAAIwXUMf48xR/37RJMDVBVeVSSLVBiDhMUb7YCI28XEKUE2w PmcBkSDQ39dFIVFRIdSN1j5IJQFyYv/MQtSOWjEKQCuCIsNuAWAi/wdwCrCRUNhD27vYpqOHDsL/ uy9plQfAQjIr8k8Wxm9YEPEdgEFOQVXBXQIe0ypi/6oUJwOphVQxC2AhQsjJsa//A3C0UbcSXvEH kAbws5F43/8EAcCDB3FuUe7/C4BYgtK1/zYwdG/BkuUlQJJJ8LeAIWD/VJALUA3gRaIqYrKjvgqc +/9dclQwNvAtcEzgBJAqELeSf0ChInBKAR3AXII8MKp/RK8EAClxIJJ/LzMoQWVAcf+ixARwndA1 0GJwpTA5QFEh+TmWN12IBLSQTYCtN08X9835s3IqUncLEaVPsqiLEPczYadopdstsqMGELMQBL// vCdBkiDhxUOvR2wGTdSmVP9yFwc3flSud/LI45Oyp6wOckZCIHhpj7EjDSDhTv5P9mCvUR8BzGJB omwfrKZ/TZMY0C9QYLFeQDlAGMAt/zxR+BCogHfDStC9UJFBZtH72lA4gGNiiMb2KgA4Ua7Q+1PV LYF2mzFDZBQgPVCXMf8e8eJhQiAe0h/UAWet0RUh/nNcgNu7KeUhUSmAwINBk3+1z3NytWOCQBlx 16V6D0m/NXAYsVaCxbXUAUsQYlmA+0WhIM5FFo9TIa9gMLCvksfqEsjJc/FSRkM10GAi/xHWOUBW 83vBC4coYjhAgUH9nwF3N5esiAIE6Q6WH5RRvUbAYRfItBSzcyDOQ9SR/V0QdW5Q2lAQC84vSxBf wPuvUUiAY3uBNyFREX3weM/+VqCgyIBz8TGPelsK9+oS9VvQboNgdLsBNl9w2Re16HggMfdgRUdg uPC0cP9QiPrf++8wwQDDPj+LEwCl/wAirrAAkPjAurH4cRFiRrD9blBs3RGtM8hRF/ACceGBPUsQ Y2rQIMcmezS3W0P/uPB7UNeW92CJIi56VrJQMX+bojrAwEBcceGUW4I48kn8VFWpwIqWQ5gl8bNl 9LLdtUUqJptcABImLiqHPsh/ECoQAbCxPfIET5CYD8Ft/+WvaBH05AJgyFH0gcxS8IH+c//ggPH1 QPSTGXiwGBAq/xuPAyiuEIBRPhmyJ7MQsvD99jMiNcZP64P345OC4cMw36Rgr7HgAzEfUTNDzdD0 se8Y0DXv7JjjkyjNwVDJWLf/uCNuwz3y58+/QKhjvZGg8fcWQWUjZ6VnoPEVEJIhFr/+ZLCxEJAA AQBkUOKAY0zQ33vxHYV3hZ4HZf9VAAEK6P9tJ/SiHZAiIghiyNn0sUrXf7qgwxCXtM1RWV+o5lrf Q/wtPsmjIuHI4q+iJ+Kiod+gobkha0S1gYKSVnXwJ5C/2kl2ag0biSIX4XfJKJ7wv+oRIiRsAYBh RazG5jX4gf/pcQ/PWKmMk4Uh4NCLwBCQ36+CL98nkKAgDPAt0ZeCuP118UM0z3XhiWCFL4NPxvX/ ktDcQkaAhNOGQk7fPZ86qb98tOchwwAuQXfXARF2usH/IxB/YJlfUYKdtOHBf2C5Av50mJBhYBfh 9fDaUEnAK7DeLt9ACOLhc9pJZfTw7rD/HbLnAg0buDLnApxn3tf4oH3TEW6uUSoBEdPpYHBSZl/D kOoA2zDioBChP8bRMfAwLTE1Y0RA0plwNL/7lvcR0W6e0HCkrxFC1xIgf+DQ+bCNQZk0mp+br9MC a78YMaRhpGCZMn7gQMM4mo+/n58R8xgx4iKg0qEoMkC0PjOiTy4QNADiI7UQSVD+T48fCEAYMEeh jVIK92Vo75XvvKOuHZwiZ5zq03R3gL8HN+FhrTHIA2egs9BwHBz3t9QIkZFgcveA37K1EAqD+6af ScNi8LGGEeGBoOAdsvsZeHMCc6h/CEOklzxQ/9CeddNBjYO2QyDOKE0RYf/3sEXgCDfYgDj0Q7Tq AGcQ/2GgjVPDI5JQp5Laegsg7pDxkOBvb2uUnMvRwxQdsv+8J2SIHZQKg5kwCEZ5NxFn/5SMx9Ez gcuy4NCRUbJgacD9adBwtMFJUNNhAq9P4uFA2z37LZdH9DJ3gCdw0v/Q/31lCIM6wKUjl8bYgMoh DAP7klBARkK0wfAhQfDiEg0b/5cz1BDUAH9h2zDXQHeR6sL/R4EAARACCRBWEX9g2xG1E/9whfSx xI6lICMxHcH1cP8RH3x7rVA98sdvyjA3MDl7NBCLMG1JUFGQUcBpwUZjX4H4EGEtY4EgGiAt+mca IXPZUNdxBs60QraX92nWXsUKdWLpYOvR4BY8IfudweoSR9nZadZKg96jCIK/JfHAu2dBduNKgZJQ TBZw/7IkRIgARt2zDRveGElQ1k//p5HbT+BWX1B8IdjgIyAn4f9Ywd5jdzPwwLzx548KlO6i/wil CveAefSx3ZaNg0BG6QJ3rJbHf/RTc8kf6IMRIE7/CII8UNCAF9JBU8Rj3YzyD/8KkxilARH/oUeC QtC/MLIh90lQQtGlAmoZQQkiGADZYP9Csa1gemhSeNyDu8Eo8eiD/wwDnOHX0UahLxJcJB5LQEa/ CEYa0BPhtJSqL2XZUmy1/wEo3mdJ89BjYBIK4NCBYnz38R8FnGnWRAm2EHBkgJIB7zFh8ZOCJ2nW RRAgIAEdwj55rTBa7wCXC5/oUlBJvkRhYKpgVlHUwiqeLuY//ka88EzzCZRtryuUvMSkxP9gIFDx XyE0cOh1gUBfUBjx70byXyEeTx9TT+wgRuAqQPsWoRRgY1GQ0cBxdS9RQREf0CEdUhXSO1VmD01U L/xSTieQLyT5oCLQGjUcJv14clKHgRhTBX/Ih/Hv3EffLySyRrCDTjcSvkYUGq7Ev043LxovEgLJ xqCUm0uvIP+68MtAacG3o50JUZCRkZWT/RVCd0nCcMNHc0BGSoH8Jf9OVmLMQNKycCmEkHNIc0lQ 76TEX1BUoHwgO0GyMLKoEf/Zws13xxGuKnp/Tkemh4kk7ktA4UadOTB1tcAwVaTE/+FbFVFHgkqB lJtCyEw/Tk//iqjV1WnBT+Glcl/xJdVvoP8Z4MuFHQPMhw+mPOfN8/iQ//fBgWAPptJycZNHgtRP fLX/GFBN8dW/LzT5E/igo8udCP1fUHe1gQiG0NR3BHHnAJP/b0TEEoFgVfCt4o0yNanW5snr81RF E6BJQi8walDnUZDPsE4PRXjU0Q0yT3b/K+AWUI2wLDhGdFUTLEPr8//KILsgkxn/095y6/JHXMrw /zcJnHdEs9mB6RGVkH9Afdf/6+QCyani9yUdY6REzSP+2//VIN5xMzen09lw4fCSgE8q/2+RZ6Nc /J0HTVKusrGzELf+TKfhxFGoEHwhfTHjtLIVv3xRFWBe8X9gI8KOQSzjsKd2YWkSXbF0YzWoV8Zi 37iFkyBPcXhy3QBST5IDVfmzClVwvGAxcPhyQ1NbiP/GIKrQlZFKwHM/urDMFrG0n8ziI52Kv4vI R2dBRLsgvkJ8AS9wbfMWAE+iZvmQ3wkgxlMmR/iSOeNn2SC0wf/EUWljIkHG0UOn9MBAcYFA/3mx r/aSUG3zvTB8s0tUqfH/QzOn0hzSgUC2p44BjsAjYN8sZCIRaWIQtz6JV8pw4jD/6gYU4vdQ/AFc rC9Da5BNAz1F43m0sAEUPBDl4WJ1/46wgbErQVkSWYEmOA+ma5D/kSK+8dIRMGJB3uDA0yIjMf5n UrEUYEVRkRIWYENRvuH/MGXA8ulwywDh4JMogL8yqPdC0C+XnRR3zoOlFMcRShz/mMDLQEaw2XJZ VEu34OHQMHerUBCggGN5kCFQX06cQf5yrJD4oLARvPLNEy8xNxD+Y5EPfdDMcdkA0bHh8rui/26f 1tewQVUQ6+R+p0ry9ydf+MCjcDnyggPCUmKs0GPr+GGp4mcPIWQQt/GPrAZ8T0NmQ8tyvTAUYGZA TPQyUx4RZFviZwISv8+yPxJFuHXAw9FwrTDEQlVOoklmQEdBU/NgL6PR//2wJcay+9Pz3ZICwfrd PBCf3VCwISCP6FUXH0xJIM//IzCTQj7SSvJkIuXgBSu3JsxVUJ5wt5BISewgrrKH83CukE+AQ0hB Uk9w4WlAXCc5NrQ0y5FNMv+acGtGBVml5T9lc7BAYTny/kTgMEry6oAR5PmwcMagf35NSaDLQBZg D48tQGPyLf8EARYAT3C3D7gTQQBE8TQHyRAmVlDzcChPu5FU4H+npQoPZxEQv3CvB19P0Er//QDi kO8AUCHYIHh7eZdrkf/wIHs3y2EPpqRDZPMsZCzXnlCucCMjQtAQIE9LR2v/8EAx8XXRe0Z042Tz MGKwsv9RskEA3kEYcN1QK+B5kkry/w+mZPP4kg+md7KCYUEAUbL9FFBxgxezJdXgKzAAsOOy/2Pj uGNk8jWowLdt8BHgKZD/UEB9zC1S7kMJIYJhsqjESf/zUkryq6i1f3iSpEMUUN4g/6fTXGAjYFdl W/pKdlRBQ6d/ZhDuEXXRovO1byllL3BUx/mQm5Ar1E9JRkrjLVL/xUTKGscAD6ZC84yRKZA8Ev+x 22TzWBPs2kzjKlnKoktRf5akIkEPpjvSOePQkw+uTn/uU9SIJgOT01PRN+ASp1t+RfmwZrEiMhRQ 5tP40S3NddAtovR40GJqeAGQ4PcIUeoJWIIiaEAiBUGgYvf1h1JD97EiPW8k8HPPT9AKWWIhd50R IFh1Kfe/rxAmIAF0IzBGsI7ASvD/M9Fcgb8UFSGzQ/mwXeB5kf9KwXe5Eq+wUwQCRjMEQQkRr0rA RqGh1muQdHeRa0rU75uQg5mWUGwjdGTzeBB7cN+x2/XkaHHjwee/V4cxkMC/NxANQShw/VUZQj6Q aKOw9kIBIFmAc0TwZxACwbKg/0WRZwEAHwEgTOLrYD7RAZW/QPBZgMHQRZCs4hPRKAKUfQnQb2ZE rIGWULKx0O9P/36xh6IB0RURwZBGFGaw9bD/QKQZwmyhY9NgUBZzD6amIv/1px8OIcWoL234QYMj jr8P66iZJVBnL3BImmFYk/ZDf/eGs0Mr5so5MqcyMMZxP+2v9E1F8fRmbiZwgGF1wv5hdaBJgGbR /GM5QDcQZhG3vL+UQROPPy9w+cRi7FH/2FJQIIjCSJF10TnyDavLe9f9YIGgQzBkdQFixsB4oO5y GLAof92lQiHdOHYsZev7UdIhcuCoUh8PpV/1qP9rRvZ4VbN/UbSRFqbmKeUW/2TBaEC4gCawvg4/ Nx4hQ0L/RCJEf0WCdOeWUHjQjrBX8/92uEtRd/APkGWwW0IZZzjC/5OBR1yLlcgQmlJE8KGhSMSd 4YZngpNzvx52MTD0ZvdT8LphRZE1kP/xyT7hWkQd/WRDluBpsqRRRVQv2FNESP22VRAoFJLzz/n0 10FzeKBJwaGwNzMz5f/ToVqg9eFUQd5z+hZgIZtg/2XAVRh04z6jjkDjsJ0gsdv/pQwSf0A/3Q8v 83piEaqWQr9UQGmxA1F9cePwLj9MltF/+1bBME2heSHSYQHR7dMtHc9gdOygldD60HAtbOFRcTAw LnSmePRuJ2D77AOWoEn29V+xMTE3wNhj/6AR0/BJEDrw+K8ZEfdh2ZL/MiJO8wwU6cCf4LSR06Fo Je+tTlQzd+LZcWNVz63GYTD/45BU1lRS0vFbOIcQVk9TxOk+EWhGMRFO3jFfT2BVP07x8GCcgB9D hvFooExW9wRPbGKO4XCoGK3GU8VVA2hNVViGYHl38K1OQf+f8IJSDLGV4PqQjpCskuRi/2vBleAK wKyRR89I31K/sFC3obBgyOvVZCLCxOBs81D+eRVC45DG4AbRuIDBYHogf5oQy7obcZuxHqOLUbHb U/+twIyBtsAMUOvl2gNfAckj/x6y7vHIY00S568eSQKSWyqf+1IDMT+xPmLgkGcuo7D/llGPV1tE QfQoXt7Co4E+U+sYUSHCKW+zU6JRESUYUP529bCYUpnB06CyoIfBW0X/sduKc7Uin2GM88+gWzeN xv923xTyNzOb0sFQNBESIpsh52+zOlA2BDE1CO+FVxtG74XUuBJqEdmkcB7AhqIl1vv0ZsQAYm+z 6LAXoTYTh89/hUg3hCukMiIXoGUxrJB2/8Kl5KXPoMQAA+ENJ/Bxb7P+NLHb0puQY8bg+sACkN7z /6dgLZF2cRbT7jFEwU3vTvJ4TUlCbM9W2GKjN6JT+4PwMQByobCskAbhsvAGkJ3eoHbj8J9BGME4 NfRu312GltNGQaIidnFkay9sP/+ZLy/0EVJL1+3ib7RRQGWA/0zDo0g1m4PAT4HaAywQ5vL/dAHS pjhylYEGkCOw06HsA6f0Zj5h81ByZL3gLjZle5wAz2B3TPG290zhFyQ5/DUl2cH/sOzw+rEWJjIi /zUQtIKoYs2AFSKm8DERnlP/2xeotamm9GaqRjBCgAH1sO8ggM/ClkPkqHcXYoPlveDuModAPmL0 ZnobkAvBOwSrO49TOXGcQXTIEFOs4ffppKzD0lBjN2EwpK3kXYH/09EPoBegzsIwlCiLMQqfTuRP TH2wKEHfEJtgto8/mT9DgkSw7VL4ilpmRW7veaFqsT5QGoBs3qD/sNZV/i+bYNRQyMFCMNLjm5Iu 0d8WEg+Q1oCSsfOQQ183GLD9FCRQxsGm1DEwm9H24cQX/3lq+qAxMBERRfP0Zrgh2QD/EirCr/Zy xOQaUVUDJlJpkP+KYTGRHOA4obUJxkY/RxhQ//RmB9AXoAohxv4nYArDhZH+dfshG5D3IBrRGFHo 4VuA7mc1UEZ5WmZH0mSbUcux/+vhu0LG/n7ghjKAGOuzD6DXalFY0cPgaMb+RGmwGFDf9uEu0frR imHYL0WCFJ5if0MR+pDuYPoiAqFFAMqDR/g3MDnSzydzNCDYP/hQHzVRxv7osTJpPUExOjH/VUQy 0vvRN+C5kC3RibA5wv2Vw3LE8b+/t6nXvlpmZRD91YBoOgB6UM3HWe8gNWDA/yRwF6AggBDwTbAH 0Mv/CcJpvpFzeVmAaPcgBfB6/01z7E89QBeg+GIfcuu/Wmb/brDD0oWR7n/HlQ+BG5Dyv7+fn6Cv QQtPYZHgFNBJFUUf13VXwdpBymArRE9PQv+MxZIQ8kFV4gGAK3BzHC9A77N1nqFeFA+QYbgxlyfq r/8qsrM5ICCUgCqwT+Fvkhwx/11AHmGnYHBUikKGkfD4HEa6UywQbR4iN2PU80lGIPpGb7NSkXDr UCASL3SnI/89AgfFcxxdQH9iFwJRUJ6h/6aEORPDsDAQykJZAnlwTOD/NVE5oy7RxiEaYFQwR4CX L/82E7gz+QJDsUIwkVUMWC0327LBUQEsJaCWUHAXyX+z/6oCqiAL1RfX2rGkorLBE8A/ICwzkgyB bmAmwJuRZHn3+yBjobPwZ6ZSheCRcCEQ13sHz1GRcHP+YS4fcKbB/5ESJaIL1hOxxYTakqLji2L/ //MsiSAmfFnJEKrAfxB6sN5ieGIsE7thiXJ5i2Mcg/5mg4EU4vgHNmclormQCJPnM5MyIYXESVCN 1oAmovH/IJYk42lwhWElcD84kMDFAe9DwJERIrBQEWR2QTL4ljH/N+GRVCy5ORKLYj1BppOUgfc1 AaogOfQ0h0ApZD5ih7Dztf+/r05UJXj5z2kQODH7w8BDEC33D1NI4bQcmYcB9lQ+MY5QWAXf2URv 0vjg/nnc8dWwW6DlxpFQE7GOUP4/OeCN3lQwwSOCIcNShvL+S0sgE8CSwMHhMZ8zAwKh/36ylUDa gorAjd70dC0Rg3L/5fQ+b50aaYKowXnA3wDVsv9BT2Gs8C1EGzZv9EOSAUCPf0dPZGn7QA3gT4F1 kpgiLfBEV0RNaA/ksmOxmDLXZSC9UeofRafxb3BAlz+PTP34H/kvjkdWaWpwMP37IFQeMMhEW9Eo AYVwFvDvcWF+EaNALXB4erB9sGqA/2mwj/FM5oRPo2F5kSNgZaCfmiNMjCplsDoQMGkulxC/erAq c4E7heIbsmVicCwluElUVc/RLSGNz0/+IP+8wAcSIOJwVGqH3vOycYVh/5VAorSpKbzAopDOQEyT YBH1AO9SGJRX34DIQ6NAZST/ztLt8lDvEEMjWJYAKZHT4P+KwKKBAhC5kRe0Xdl1kKKRi1x7TJNs p/Bkd2RxIP9cH25Vq0ePMI9is/AL2BWZ/nUJpJvQCLCSEMTTllKCwf+LY0kz/ce5w7QQZEwMo2JB /5LBDzcQlozAkWCFcHYxXEL3gtIN4n81c8YRDKMk57QQ/9XJGIUqochDaF2K45HgbDL/5IJ7I3Ly d+/7IH2eigR+tP+qEbrhDiMgxVLnpkLGEdJQ/5UhAAHLJyQzIGCo0IJBgyL/LGNiQTTxroDJkJbB lYDX4/+CI//yGGevh5EDgjKPEk1n/63zfgcdecOwDZGGoq1QuCK/xhD84bjxyZCHpSWXYfah/5ah HjAtEXGCSyaNlGhkAFK3i8quonVnMC9fUwVUymD/7gKbgdQB2aZUH0um9nHZ1P/7kbri2XCoMPzh iBNWkkTvsdxFUElP5zMw4E9LLu86D0wkltfxllfRY/zDxUOPlZOmcmJByENUVExPEf9fkKUw8N/W wqIgTwAC1Q3g/0RzwSBgITNPUv9UDzqICPj/JKQLdFeg+8cW8TvQxlBZL//kcQjpqfcC1VegWjG+ 8CIw/6vPByBtYhKCpyTcgSxj1BL/vOgPP2pMHDHfMBdQhKDjMKv1MtuwMi3QeRlhet0g/5BSFQFi c2R5tSa0pRn3EYnbA0FXoHcZILfXNrXrL08FnaR9vXAAAAAeAHAAAQAAAA4AAABDQ0FNUCBtaW51 dGVzAAAAAgFxAAEAAAAbAAAAAcEgKBTli3mgDIwREdW0DQAIxw3xOgDuwMvgAAMALgAAAAAACwAC AAEAAAADAAlZAQAAAB4AQhABAAAAKwAAADwyMDAxMDgwODE2MTMuSkFBMjk5MjFAa3VtbWVyLmp1 bmlwZXIubmV0PgAAAwDeP69vAABAADkAwOLCp+MjwQEDAPE/BwQAAB4AMUABAAAACQAAAEhKMDQ4 NjY0AAAAAAMAGkAAAAAAHgAwQAEAAAAJAAAASEowNDg2NjQAAAAAAwAZQAAAAAADAP0/5AQAAAMA JgAAAAAAAwA2AAAAAAADAIAQ/////wIBRwABAAAAMAAAAGM9REU7YT1EQlA7cD1TQ047bD1NQ0hI MjMwRS0wMTA4MTMxMDM1MjJaLTQxNjY4AAIB+T8BAAAASwAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1TQ04vT1U9REVNQ0hIMjAxRS9DTj1SRUNJUElFTlRTL0NOPUhKMDQ4NjY0AAAe APg/AQAAAA8AAABIZWlsZXMgSnVlcmdlbgAAHgA4QAEAAAAJAAAASEowNDg2NjQAAAAAAgH7PwEA AABLAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVNDTi9PVT1ERU1DSEgyMDFFL0NO PVJFQ0lQSUVOVFMvQ049SEowNDg2NjQAAB4A+j8BAAAADwAAAEhlaWxlcyBKdWVyZ2VuAAAeADlA AQAAAAkAAABISjA0ODY2NAAAAABAAAcwfkgRGOMjwQFAAAgwFODJqeMjwQEeAD0AAQAAAAUAAABB VzogAAAAAB4AHQ4BAAAADgAAAENDQU1QIG1pbnV0ZXMAAAAeADUQAQAAADQAAAA8QUZDNzY4MzU3 MjdERDIxMUE3QzIwMDA4QzcxRUFGMUUwMjI5MTgzMkBNQ0hIMjMwRT4ACwApAAAAAAALACMAAAAA AAMABhBojqXZAwAHEOksAAADABAQAAAAAAMAERACAAAAHgAIEAEAAABlAAAASVRISU5LTUFBUlRF TlNDT01NRU5UT05DT05DQVRFTkFUSU9OQ09OVkVSU0lPTklTU1RBVEVEV1JPTkdIRVNBSURUSEFU Q09OQ0FURU5BVElPTkNPTlZFUklPTklTQVNUQU5EQQAAAAACAX8AAQAAADQAAAA8QUZDNzY4MzU3 MjdERDIxMUE3QzIwMDA4QzcxRUFGMUUwMjI5MTgzMkBNQ0hIMjMwRT4AbRQ= ------_=_NextPart_000_01C123E3.A7C2E2C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Aug 2001 12:52:26 -0700 From: "Raju Venkatraman" To: ccamp@ops.ietf.org Bcc: Subject: Testing Requirements for RSVP-TE Date: Thu, 09 Aug 2001 19:43:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Is it possible to test RSVP-TE implementation with just Sun-Solaris/Sparc machines? I would appreciate if someone could help me. Thanks. Raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Aug 2001 09:10:31 -0700 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers ' Cc: ''Heiles Juergen' ' , 'ccamp ' , "'t1x1.5 '" , 'q11/15 ' Subject: RE: ARE: [T1X1.5] arbitrary contiguous concatenation question Date: Thu, 9 Aug 2001 18:04:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Maarten, I though that my e-mail was more about SDH, sorry if I was not clear = :-) Also you know (since you wrote the arbitrary concatenation section with = me) that the IETF is not defining any transport plane. We (you and me) gave = a description of our understanding of arbitrary concatenation. Whatever are the exceptions that one can find in the transport plane interoperability (not in IETF scope), it doesn't change the fact that = many arbitrary concatenated signals are useful and used (e.g. to transport 1 = GE), and for those signals there is no problem. The issue of the STS-3c is an exception and don't break the general mechanism. To solve this exception, there is an easy solution in the signaling: return the list of labels for all timeslots (like in case of virtual concatenation). Also, I think that one should refrain to cc these e-mails = systematically to IETF, ITU-T and T1X1 mailing lists. I don't know what is the purpose of = this ! That's the last time that I am doing it. Those people interested into GMPLS can simply join the CCAMP mailing = list (see IETF web site, WG, CCAMP WG). Kind regards, Eric -----Original Message----- From: Maarten Vissers To: Mannie, Eric Cc: 'Heiles Juergen'; ccamp; t1x1.5; q11/15 Sent: 8/5/01 2:00 PM Subject: Re: ARE: [T1X1.5] arbitrary contiguous concatenation question Eric, Let's discuss this issue during the IETF meeting in London. Being face to face its easier to illustrate that a STS-3c isn't using 3 physically contiguous timeslots. For the standard contiguous concatenation (including STS-3c) there are T1.105 and G.707 defining the timeslots used. But there are no transport plane documents that define the timeslot allocation for arbitrary concatenation. I.e. is a STS-3a using physically contiguous timeslots or is it using the same timeslots a STS-3c would use? As the gmpls-sonet-sdh document is the first and only standard describing arbitrary concatenation, interworking is only guaranteed when it is unambiguous which timeslots are being used. Regards, Maarten "Mannie, Eric" wrote: >=20 > Hello Juergen and Maarten, >=20 > I don't understand the relationship between > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that you are talking > about. >=20 > In addition, the IETF is not specifying any SDH/SONET = interoperability (Not > at all in the GMPLS scope). >=20 > 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 ? >=20 > 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. >=20 > 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. >=20 > I guess also that this discussion is relevant for the ITU-T and/or T1X1, not > for the ccamp mailing list (of the IETF). >=20 > Kind regards, >=20 > Eric >=20 > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > 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 >=20 > Maarten, >=20 > good point. Lets hear what the supporters of arbitrary concatenation have to > say. >=20 > Juergen >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Maarten Vissers [mailto:mvissers@lucent.com] > > Gesendet: Dienstag, 10. Juli 2001 11:14 > > An: ccamp > > Cc: t1x1.5; q11/15 > > Betreff: [T1X1.5] 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 > > <>=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 Aug 2001 03:39:16 -0700 Message-Id: <4.3.2.7.2.20010809111953.027392c0@mo-ex1> Date: Thu, 09 Aug 2001 11:37:08 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: Re: CCAMP WG action items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:15 PM 8/8/01, Kireeti Kompella wrote: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-04.txt > draft-ietf-mpls-generalized-signaling-05.txt Here's a summary of what changed in this rev of the drafts: o Fixed Label Set format (for LDP) [Increased field size to match LDP type field size] o Added Switching type of LSP being requested [This field was in an earlier version of the drafts] [Is required for links that support multiple switching types] o Added Administrative Status Information [To address last call comments (notably from the carrier community)] o Added section on Control Channel Separation Covers: - Separation of control and data channels [To address last call comments (notably from the carrier community)] - Restoration of state post control channel failures [Again to address last call comments, is required by control / data channel separation.] o Other minor editorial and clarification text [some based on comments received] So far the following changes are planned based on comments received since the above were issued: - Update LSP Encoding Type to remove redundant SONET/SDH types - Use a new object type rather than suggested_label when supporting restart - to simplify restart processing - Add some clarification text on error processing and when an LSP is usable - Add IANA considerations section That's it, Lou Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 Aug 2001 09:20:21 -0700 Date: Wed, 8 Aug 2001 09:15:05 -0700 (PDT) From: Kireeti Kompella Message-Id: <200108081615.JAA29927@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP WG action items 1) Final round of WG comments on GMPLS signalling drafts by August 27. These include: 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-sonet-sdh-01.txt At that point, the authors (editors) incorporate the comments, and the documents go to IETF Last Call. The pieces of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt that get taken out are to be put in another draft that will be a CCAMP WG _informational_ document. When Eric submits this draft, we'll have a three week WG Last Call on it. 2) G.709: move non-ITU-standard stuff into a separate document. 3) Reissue routing docs as CCAMP WG docs: draft-kompella-ospf-gmpls-extensions-02.txt draft-many-ccamp-gmpls-routing-00.txt 4) For each of the following, do you think: a. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt b. draft-fontana-ccamp-gmpls-g709-00.txt (assuming that the non-ITU stuff is removed) c. draft-many-ccamp-gmpls-framework-00.txt d. draft-bonica-tunneltrace-01.txt should these be made CCAMP WG docs or not? Also, for (c), do you think that a GMPLS framework doc is useful? 5) Tom and co-authors to send mail to the list stating the degree of independence of LMP MIB to the MPLS TE MIB complex. 6) Consensus: don't move forward with NTIP; move forward with LMP-WDM, subject to due diligence that this work belongs in the IETF. 7) Once new versions of the following drafts appear, we will have WG Last Call on them: draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt draft-ietf-ccamp-lmp-00.txt draft-many-gmpls-architecture-01.txt Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 Aug 2001 09:20:15 -0700 Date: Wed, 8 Aug 2001 09:13:34 -0700 (PDT) From: Kireeti Kompella Message-Id: <200108081613.JAA29921@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP minutes Many thanks to Sudheer for his detailed minutes and to Ed for his colorful minutes (pity I can't publish them unexpurgated). Between the two, we have excellent coverage. The following is mostly from Sudheer, with comments from Ed prefaced by "EK:" My own comments in []. The minutes are reproduced almost as is. Note that the numbers when asking for consensus, while faithfully reported, are *not* in themselves significant. The goal is rough consensus, not a majority. Kireeti. ------- CCAMP Minutes: Milestones: To dos: - Make framework as working group document - What to do about or extend the working group for o Inter-AS signaling o Optical VPNs o G.709 o Measurement (routing, LMP, OLI, ?) o MIBs o Security (new design team) Charter & draft updates: Routing drafts are broken as "common" and "Protocol-specific" ISIS will be dealt in the ISIS working group OSPF will be dealt in the CCAMP working group (EK: (mike goes dead, we can thankfully no longer hear kireeti babble)) Protection and restoration - ? Hierarchical (multi-area) TE drafts - Where will the protocol work be done? o Wei - Can decide after the TE WG. (EK: kireeti says protocol work belongs in ccamp; te-wg chairs agree.) Update from the DT: No presentation made. GMPLS update (Lou): (Generalized-signaling, RSVP-TE, CR-LDP) Changes: - More on the technology specific is separated and covered in length - SONET/SDH is moved out to be included in another draft - Issued joint CCAMP and MPLS WG last calls Detailed changes: - Technical error in LDP (?) - Re-introduced Switching type in the G-PID o To support multiple switching types on the same interface - Administrative status information TLV is added o To support state of the LSP (in Path/RESV) and o To notify the status of an LSP otherwise - Changes made in the scope of "control channel separation" o Identification of data channels when the channel is not uniquely identified by control channel o Handling of control channel failures that do not impact data channels Next changes: - Need more comments - Ask IANA assignment for CR-LDP and RSVP-TE related information - Some issues resolved o Missing timeout o Minor changes to o G-PID change to avoid duplicity for SONET (?) (EK: kireeti cant run powerpoint to save himself.) Discussion: 3 weeks from today [i.e., by August 27] will close on the comments and move forward. SONET/SDH (Eric): GMPLS-SONET-SDH: - This is the separated document from GMPLS signaling draft specific to SONET/SDH - Flexible concatenation is NOT part of this document - Mostly editorial, re-organizing, correctness etc. - Appendices are provided for different implementation mechanisms supported using this draft - Other modifications o Improve the interoperability o Etc. - Targeted for informational RFC [not this doc, the new doc, see below] - Move for IANA assignment - Which appendices to be moved o Contiguous concatenation o Transparency (per byte) o Virtual concatenation o Signaling for non-std concatenation o Appendix 1: Explained Discussion: Comment: (EK: comment on if certain part should be on standards track or information) [Clarification: the appendices that refer to items that are non-ITU-T standards get moved to another *informational* document.] Concatenation conversion (Eric): Problem: - To avoid wastage of timeslots due to different concatenation mechanisms Solution: - SDH/SONET "Virtual Concatenation" Proposed a contiguous concatenation (C) to virtual concatenation (V) conversion mechanism and extensions - Realize ingress and egress aggregator - Advertise the converting nodes using routing protocols - Use signaling protocols to use this information to setup the path Signaling: - C->V is performed at the first converter and V->C is performed at the end converter (before the destination) - 5 possible concatenation mechanisms can be negotiated o CC e-to-e o CC->VC o VC->CC o VC e-to-e o ? [CC->VC->CC] Discussion: o Are there such converters available? o Eric says at least two vendors have. He sees this evolving more and more. o How many see this as useful function? - 10-15 (EK: 10) o How many think this is should be done here? - 10 o How many think this makes sense? - 5 (EK: 8) o How many think this does not make sense? - 2 (EK: 3) o Why not in IPO? o These are signaling extensions. o Technology specific things should be in their respective groups CCAMP is working on GMPLS o What about VCs taking different paths? o This does not include such paths o (Marteen) This is a non-standard feature support. Why not also look at supporting standard mechanism using GMPLS? This is part of the transport network -- put it in. Conclusion: - WG chair's inclination is to make this as a WG draft. But since not many people understand these concepts let us take this to the mailing list before the decision. G 709 (Dimitri): - Fontana-ccamp-gmpls-g709 What? - Propose GMPLS based control plane for G709 - ITU-T G709 is getting standardized at ITU. Lets work on the control plane for it. Why? - G709 is a tera-bit tech for the future - GMPLS solves the signaling mechanisms to control such a technology Changes: - G709 OTN is independent of the control plane - GMPLS provides all the hooks without major paradigm shift Propose a new G709 drafts similar to SONET draft This is only about signaling extensions Routing extensions for G709 are under consideration Changes: - Document name has changed - Encoding type - Signaling type - GPID value list - .. Further changes - Move features not covered by G709 in a dedicated draft - OOS field description to be completed in appendix - RMT/RNC to be adopted in RMT/RNC and RVC field Conclusions: - Propose to be working group document - Features not in the document to be moved to extensions -- Kireeti - This should be driven more by what is in the ITU G709 document. (EK: kireeti says that its not a vote; if its in g709 it should be in the document.) [KK: Clarification: stuff that is not standardized by the ITU should be moved to another document.] Decision - Consensus in the room is to adopt as a WG document. But will be taken to the mailing list before the final decision. (EK: majority think this should be a wg document and that the signalling part belongs here.) GMPLS TE MIB (Adrian) Existing TE MIB (which is in the final stages in MPLS WG) is only for MPLS. (EK: clarification this is the mpls te mib) GMPLS extensions are provided in this draft. This effort should not impede MPLS TE MIB progress. This should belong in CCAMP. Lot of interest on this work (by implementers, operators etc.) Work includes TE and LSR MIBs for GMPLS Updates will be provided next month Make this CCAMP WG document Discussion: (AD) Bert: Make a MIB framework document with the gamut of MIBs to put them in perspective. Make sure that there will not be an overlap in these MIBs. Decision - Wait for the overview draft. (EK: bert before you extend or build on mpls mib document best to let that document go through iesg last call so that it stabilizes before you extend it. kireeti should we not make it a wg document until mplste mib settles...bert yes.) GMPLS Architecture draft (Eric) Was accepted as a CCAMP WG document Gives GMPLS overview and provides how the building blocks are glued. Changes: - TOC, open issues, L2SC added etc. - Many changes including scope of UNI, GASTN/GASON in the GMPLS context Proposed sections: - G709 - OLI - Protection and restoration o UPTO THIS IS IN THE CHARTER – What is below will be on consensus from the DT and further discussion. - Multicast - Inter-area TE - Inter-domain - VPN (OVPN) section - Etc.. Discussion: - (Jim Luciani) Make sure there will be no overlap on ASON work in the IPO group. - OK (EK: lots of overlap with work thats being done elsewhere and work with person doing req documents from cienna on interarea work.) - (Marteen) Wait for the ITU to come on consensus on OTN and Protection - Make ASON relationship clarified in this document in terms of scope. - Kireeti: Track what OIF and ITU work is being done. But we need to work on the signaling part should be done at CCAMP to move the work. - No consensus on the draft status [Editor to remove out-of-scope subjects. Draft status is "close to WG Last Call".] Framework document (Yongwang Xu): - Control plane is discussed from different perspectives - What are the fundamental changes betn pkt and ckt based network ctrl plane design - NW layering -- based on tech, BW mismatch, cost etc - NW partitioning -- administrative (tech, geo, oper reasons) - Overall -- reduce the tools to a common integrated control plane Propose: - Make this a WG document Discussion: - Greg: How is this different from what is being done in IPO? – More number of authors and carriers - Eric: - ?: What about reliability of the control plane and bandwidth broker? -- Kireeti: Bandwidth broker is not in the charter. Reliability of the control plane will be discussed only after what is to be done is clear. Consensus: Will take to the mailing list with the assumption that people are not sure. (EK: kireeti: how many think we need gmpls framework document about 10 against 5.) Framework on GMPLS based CP for SONET/SDH networks (Greg): - Asked by many people to explain what are the problems with SONET using GMPLS Discussion: - Kireeti: Will be a WG document as informational. LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt - Remove CCId from TE link related messages - Modified the LMP common header to include o CCId specific messages o The TE link Id for specific msgs - Removed ChFailNack - Removed LMPCapabilities TLV - Next steps: o Remove link MUX type o Add on graceful restart procedures Discussion: - Why ChFailNack removed? -- Always the upstream node worries about it. So we can remove this msg without loss of info. - What about tech specific mechanisms (for e.g., as specified by the OIF UNI for in band)? -- Since this involves protocol specific extensions, make a specific document. - How many are implementing? -- 10 (EK: 15) - How many carriers are interested in putting in the lab? -- None (EK: 5) - How many think after the next rev there should a last call? -- 4 Wait for the next update and see if it is stable. LMP MIB: - Moved Link Summary retransmit values … - TE link table uses if id Discussion: - Will this be a WG draft? -- Accept as a WG draft (EK: does this have to wait for mplste mib to move forward...kireeti views it as being 95% independant from the other mib so is available to move forward. kireeti takes poll on if it should be wg document...20 for zero against.) - Request: Send the dependency to the other TE components to the mailing list OLI (Andre) - Main objectives o Enhanced fault detection/recovery for transparent optical XCs ? PXCs have limited detection mechanisms unlike SONET equipment o Enhanced discovery of link characteristics for optical networks in general ? Reduce manual errors in configuring o General requirements ? Simple protocol to report health ? Defined parameters ? Extensible to future techs like G709 ? Reliable ? Secure ? No assumption on 1:1 relation between client and server - Requirements o Neighbor discovery o Control Channel Management o OLI synchronization o Connectivity discovery o Fault management o Property discovery Discussion: - Angela: Is this required to run only OOB? -- Not necessarily. Could be used for opaque. o Neighbor disc should be coordinated? - That was the intention - Sham: Why this in IETF? -- Rough consensus to work in IETF. This is because this work falls under measurement part of CCMP. (EK: question: why should this work be done in ietf,no ip involved.....because it has an ip control plane thats why. randy: iesg goes around seriously..its here not because ip transport is being used to control the device, but that its carrying ip traffic.... kireeti: not enough that they are IP protocols but that they grow IP networks everywhere. hands on if we should be working on this or not..about 40 hands for 15 against.) NTIP - Added auto-discovery - Reliable transport -- TCP - X - Simple -- Assymetric relationship - ??? - CC Maintenance -- Keep alive - Auto-dsc -- Supported - Fault notification -- Supported - Trace monitoring -- Supported - Resynchronization -- Supported - X - Fast notification -- Supported - X - Issues with LMP-DWDM o Assumes LMP exists o Employs LMP-DWDM Discussion: - Vijay: To have less new code in a box, I prefer LMP-DWDM. - WG chairs: Move with LMP-DWDM if we move forward (i.e., if we are not stepping on ITU foot.) - Osama: What is the procedure to follow up this formally with ITU. o Randy: We have a formal channels (EK: kireeti: needs duedilligence that we will move forward with lmpdwdm if we move forward with anything because the itu work might cover it making it not necessary to do this work at all. question? how do we make sure this isnt work they are doing randy: we have formal channels in place to ask the itu. question: formal channels are in place...comment that it doesnt get used enough, more common that liason statements are used. randy: there are many other channels being used far more frequently then liason papers so nothing more formal or other channel is necessary0 Tunnel trace protocol: - Protocol is completely stateless - Refined PIO and TIO - ? - Issues: o Works only for tunnels that have TTL expiration o GTTP should support MTU discovery Discussion: - Consensus that this is a required concept. - No consensus that this should a WG draft. - Will be discussed on the mailing list. (EK: kireeti: useful document? 20 yes zero no...is this document useful should this be a wg document 6 yes zero no.) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 Aug 2001 14:54:56 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B7061E6.D279C51F@lucent.com> Date: Tue, 07 Aug 2001 23:47:18 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Tomohiro Otani Original-CC: ccamp@ops.ietf.org Subject: Re: BER value of TLV in LMP-WDM Content-Type: multipart/mixed; boundary="------------0A9B886EFE4FCFF6B95EE37E" This is a multi-part message in MIME format. --------------0A9B886EFE4FCFF6B95EE37E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Tomo, Bit Error defect detectors in SDH, SONET and OTN are defined in G.806. SDH has two alternative detector sets (see below) with different paramete= rs: a) EXC_X in range 10-3, 10-4 and 10-5, DEG_X in range 10-5, 10-6, 10-7, 1= 0-8, 10-9 b) DEGM in range 2..10 and DEGTHR in range 0..100% or 0..N SONET uses alternative a) detector types, while most AU-4 based SDH uses alternative b) detector types (refer to ETSI EN 300 417-1-1. OTN will only use alternative b) detector types. Regards, Maarten =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Text from G.806: 6.2.3 Signal quality supervision 6.2.3.1 Generic behaviour Signal quality supervision in general monitors the performance of a trail= =2E If the performance falls below a certain threshold this might activate a def= ect. For the generic performance monitoring process see section 8.3. For networks where the network operator assumes a Poisson distribution of= errors, an excessive error defect and a degraded signal defect are to be detected. = For networks where the operator assumes a bursty distribution of errors, = a degraded signal defect is to be detected. The excessive error defect, for= this case, is assumed to be false. The applicability of the two is in the province of the regional standards= =2E 6.2.3.1.1 Excessive error (dEXC) and degraded signal defects (dDEG) assum= ing Poisson distribution of errors Excessive error and degraded signal defect= s are to be detected according to the following process: An excessive error defect (dEXC) shall be detected if the equivalent BER = exceeds a preset threshold of 10-x, x =3D 3, 4 or 5. The excessive error defect s= hall be cleared if the equivalent BER is better than 10-(x+1). With BER >=3D 10-x the probability of defect detection within the measuri= ng time shall be =B3 0.99. With BER <=3D 10-(x+1) the probability of defect detection within the mea= suring time shall be =A3 10-6. With BER >=3D 10-x the probability of defect clearing within the measurin= g time shall be =A3 10-6. With BER <=3D 10-(x+1) the probability of defect clearing within the meas= uring time shall be =B3 0.99. A degraded signal defect (dDEG) shall be detected if the equivalent BER e= xceeds a preset threshold of 10-x, x =3D 5, 6, 7, 8 or 9. The degraded signal de= fect shall be cleared if the equivalent BER is better than 10-(x+1). With BER >=3D 10-x the probability of defect detection within the measuri= ng time shall be =B3 0.99. With BER <=3D 10-(x+1) the probability of defect detection within the mea= suring time shall be =A3 10-6. With BER >=3D 10-x the probability of defect clearing within the measurin= g time shall be =A3 10-6. With BER <=3D 10-(x+1) the probability of defect clearing within the meas= uring time shall be =B3 0.99. Maximum detection and clearing time requirements for the BER calculations= for SDH are listed in Table 6-4, Table 6-5 and Table 6-6. For all other signa= ls these values are for further study. NOTE - The specification in the 94 revision of ITU-T Recommendation G.783= [9] could have been interpreted as listed in Table 6-7. TABLE 6-4/G.806 Maximum detection time requirements for VC-4 and VC-3 Detector Actual BER threshold >=3D10-3 10-4 10-5 10-6 10-7 10-8 10-9 10-3 10 ms = 10-4 10 ms 100 ms = 10-5 10 ms 100 ms 1 s = 10-6 10 ms 100 ms 1 s 10 s = 10-7 10 ms 100 ms 1 s 10 s 100 s = 10-8 10 ms 100 ms 1 s 10 s 100 s 1 000 s = 10-9 10 ms 100 ms 1 s 10 s 100 s 1 000 s 10 000 s TABLE 6-5/G.806 Maximum detection time requirements for VC-2, VC-12 and VC-11 Detector Actual BER threshold >=3D10-3 10-4 10-5 10-6 10-7 10-8 10-3 40 ms = 10-4 40 ms 400 ms = 10-5 40 ms 400 ms 4 s = 10-6 40 ms 400 ms 4 s 40 s = 10-7 40 ms 400 ms 4 s 40 s 400 s = 10-8 40 ms 400 ms 4 s 40 s 400 s 4 000 s TABLE 6-6/G.806 Clearing time requirements Detector Set/Clear values Multiplex section VC-2 threshold associated with VC-4 VC-12 detector threshold VC-3 VC-11 = 10-3 10-3/10-4 10 ms 40 ms 10-4 10-4/10-5 100 ms 400 ms 10-5 10-5/10-6 1 s 4 s 10-6 10-6/10-7 10 s 40 s 10-7 10-7/10-8 100 s 400 s 10-8 10-8/10-9 1 000 s 4 000 s 10-9 10-9/10-10 10 000 s = TABLE 6-7/G.806 Alternative interpretation of maximum detection and clearing time require= ments = in the 94 revision of ITU-T Recommendation G.783 [9] Detector threshold Multiplex section VC-2 VC-4 VC-12 VC-3 VC-11 10-3 10 ms 40 ms 10-4 100 ms 400 ms 10-5 1 s 4 s 10-6 10 s 40 s 10-7 100 s 400 s 10-8 1 000 s 4 000 s 10-9 10 000 s = 6.2.3.1.2 Excessive error (dEXC) and degraded signal defects (dDEG) assum= ing Bursty distribution of errors The excessive error defect is not defined, and dEXC is assumed to be fals= e. The degraded signal defect (dDEG) shall be declared if DEGM consecutive b= ad intervals (interval is the one second period used for performance monitor= ing) are detected. An interval is declared bad if the percentage of detected e= rrored blocks in that interval or the number of errored blocks in that interval = >=3D Degraded Threshold (DEGTHR). NOTE 1 - For the case of dDEG in the MSn layer, the errored block is equa= l to a BIP violation. The degraded signal defect shall be cleared if M consecutive good interva= ls are detected. An interval shall be declared good if the percentage of detecte= d errored blocks in that interval or the number of errored blocks in that i= nterval < DEGTHR. The parameter DEGM shall be provisionable in the range 2 to 10. = The parameter DEGTHR shall be provisioned either as a percentage or eithe= r as a number of errored blocks. When based on a percentage, it shall be in the = range 0 < DEGTHR <=3D 100%. When based on a number of errored blocks, it shall be= in the range 0 < DEGTHR <=3D Number of blocks in the interval. NOTE 2 - When using percentage, for higher rate interfaces, one per cent = is equal to a large number of blocks. For example, in an STM-16 interface, 1= % is equal to a step of 30 720 blocks in the interval for the multiplex sectio= n. --------------0A9B886EFE4FCFF6B95EE37E 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:mvissers@lucent.com 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 --------------0A9B886EFE4FCFF6B95EE37E-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 18:37:20 -0700 Cc: mpls@UU.NET, ccamp@ops.ietf.org Message-ID: <3B6F44AF.4ADB419B@lucent.com> Date: Tue, 07 Aug 2001 03:30:23 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Martin Dubuc Original-CC: mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Queries regarding LMP. Content-Type: multipart/mixed; boundary="------------1482458F7B558D6517853310" This is a multi-part message in MIME format. --------------1482458F7B558D6517853310 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin, 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). > In an OTN network the fault isolation is provided by the transport plane; no need for LMP here (at least this aspect). In the truly optical part of the OTN there is OTS, OMS and OCh overhead to take care of fault isolation. And when reaching a 3R point, the OTUk and ODUk overhead continue/perform this fault isolation role. Same is true for SDH/SONET networks; no need for fault isolation within LMP. So in my opinion this fault isolation aspect in LMP is limited to pre-OTN networks. Regards, Maarten --------------1482458F7B558D6517853310 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:mvissers@lucent.com 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 --------------1482458F7B558D6517853310-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 14:56:37 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006D42158@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Fong Liaw , Fong Liaw , Andre Fredette , Jonathan Lang , "Bilel Jamoussi" , "Osama Aboul-Magd" Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Mon, 6 Aug 2001 14:52:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EC2.22B2DAC0" 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_01C11EC2.22B2DAC0 Content-Type: text/plain; charset="iso-8859-1" Hi Fong, See my comments below Regards Vasant -----Original Message----- From: Fong Liaw [mailto:fliaw@zaffire.com] Sent: Monday, August 06, 2001 1:05 PM To: Sahay, Vasant [SC9:6909:EXCH]; Fong Liaw; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi, Vasant -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Sunday, August 05, 2001 2:20 PM To: Fong Liaw; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Fong, Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. [Fong] But LMP (which LMP-WDM uses the link-verification procedure) is out for a long-long time. NTIP is quite recent. We all have protocols that works in our lab/product and did not bother to bring them out. LMP does have first-mover advantage here. [Sahay, Vasant] I agree with the fact that LMP is out there for a long time. However IETF should not pick a solution based only on being a first-mover. As we have said before LMP has a much wider scope than OLI and it is not completely defined either. Hence using LMP for OLI has time-to-market and design issues. NTIP on the other hand is a specifc solution, focused on OXC-to-OLS interface. Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. [Fong] I would ask why would we make a protocol extensible if we do not plan to extend it to do other functions. The fact that we can simply add a sub-TLV to accomplish new functionality says that if I implement LMP, I have better chance of re-using my implementation. Also, if after I implement NTIP, do I still need to implement LMP so that an OLS can also work with a router that is not a master controller ? Or would you propose we extend NTIP to do that function as well ? If so, using your way of argument, I can claim that NTIP is not complete in this aspect either. [Sahay, Vasant] Two points here: #1) protocol extension is a good thing. We should use it for unforeseen extensions in future/ for supporting proprietary extensions etc. However we have two competing proposals here. One (NTIP) already has considered and incorporated the features specific to OLI. Other (WDM-LMP) has not considered them and you are proposing to enhance WDM-LMP to add these extensions. I will save extensions for future use. #2) You are arguing that you will end up implementing LMP for OXC-to-OXC and NTIP for OXC-WDM so why not reduce the number of acronyms by basing OLI on LMP ? We have gone in loops on this argument for several months now. [Fong] From my read to LMP/LMP-WDM, LMP has also thought through the control/data channel degradation issues and its implications to SLA. NTIP has no mention of it. Simply said that NTIP does not address configuration issues and therefore do not requirement persistent store does not really simplify my implementation/system. I have no doubt that NTIP brought its own contribution, but if NTIP wants to present itself as a superior/complete protocol, I am afraid you would not get strong support in that. [Sahay, Vasant] Thanks for appreciating NTIP's contribution. If you look at the OLI requirements you will find more of it. We have no intentions of touting any superiority. We are only requesting that our proposal be treated fairly. It is in the best interest of the industry to go through the comparison to see what suits them, as oppsoed to picking something just because it is a first mover. We can continue the comparison game forever, but it will do no good to the industry. IMHO, the best way forward is to streamline LMP/LMP-WDM, as suggested by Bala, and I am sure Nortel will be able to contribute significantly, using experience from NTIP. [Sahay, Vasant ] Your opinion is valuable. However the way to pick solutions in a standards body is not to make an adhoc choice (by a few people) about streamlining one solution using contributions from others. We are comparing them so that a larger number of members get a chance to look at the pros and cons of both the solutions and decide what works best for them. Regards, -Fong Regards Vasant -----Original Message----- From: Fong Liaw [mailto:fliaw@zaffire.com] Sent: Friday, August 03, 2001 8:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) [Sahay, Vasant ] LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol. The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs". This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. [Sahay, Vasant ] Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ? NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? [Sahay, Vasant ] Here is the explanation. Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla. By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports. The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11EC2.22B2DAC0 Content-Type: text/html; charset="iso-8859-1"
Hi Fong,
See my comments below
 
Regards
Vasant
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Monday, August 06, 2001 1:05 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Fong Liaw; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi, Vasant
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Sunday, August 05, 2001 2:20 PM
To: Fong Liaw; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi Fong,
Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. 
 
[Fong]  But LMP (which LMP-WDM uses the link-verification procedure) is out for a long-long time. NTIP is quite recent.  We all have protocols that works in our lab/product and did not bother to bring them out. LMP does have first-mover advantage here.
[Sahay, Vasant] I agree with the fact that LMP is out there for a long time. However IETF should not pick a solution based only on being a first-mover. As we have said before LMP has a much wider scope than OLI and it is not completely defined either. Hence using LMP for OLI has time-to-market and design issues. NTIP on the other hand is a specifc solution, focused on OXC-to-OLS interface.   
 
Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. 
 
[Fong]  I would ask why would we make a protocol extensible if we do not plan to extend it to do other functions. The fact that we can simply add a sub-TLV to accomplish new functionality says that if I implement LMP, I have better chance of re-using my implementation. Also, if after I implement NTIP, do I still need to implement LMP so that an OLS can also work with a router that is not a master controller ? Or would you propose we extend NTIP to do that function as well ? If so, using your way of argument, I can claim that NTIP is not complete in this aspect either.
[Sahay, Vasant] Two points here:
#1) protocol extension is a good thing. We should use it for unforeseen extensions in future/ for supporting proprietary extensions etc.
However we have two competing proposals here. One (NTIP) already has considered and incorporated the features specific to OLI. Other (WDM-LMP) has not considered them and  you are proposing to enhance WDM-LMP to add these extensions. I will save extensions for future use.
#2) You are arguing that you will end up implementing LMP for OXC-to-OXC and NTIP for OXC-WDM so why not reduce the number of acronyms by basing OLI on LMP ? We have gone in loops on this argument for several months now.
 
[Fong] From my read to LMP/LMP-WDM, LMP has also thought through the control/data channel degradation issues and its implications to SLA. NTIP has no mention of it. Simply said that NTIP does not address configuration issues and therefore do not requirement persistent store does not really simplify my implementation/system. I have no doubt that NTIP brought its own contribution, but if NTIP wants to present itself as a superior/complete protocol,  I am afraid you would not get strong support in that.
[Sahay, Vasant] Thanks for appreciating NTIP's contribution. If you look at the OLI requirements you will find more of it. We have no intentions of touting any superiority. We are only requesting that our proposal be treated fairly. It is in the best interest of the industry to go through the comparison to see what suits them, as oppsoed to picking something just because it is a first mover.
 
 We can continue the comparison game forever, but it will do no good to the industry. IMHO, the best way forward is to streamline LMP/LMP-WDM, as suggested by Bala, and I am sure Nortel will be able to contribute significantly, using experience from NTIP.
[Sahay, Vasant ] Your opinion is valuable. However the way to pick solutions in a standards body is not to make an adhoc choice (by a few people) about streamlining one solution using contributions from others. We are comparing them so that a larger number of members get a chance to look at the pros and cons of both the solutions and decide what works best for them.
 
 
  
 
   Regards, -Fong
 Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors. 
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
[Sahay, Vasant ] 
LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol.
 
The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs".  This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly.
 
 
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. 
 
 
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. 
[Sahay, Vasant ] 
Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ?
 
 
 
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. 
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) 
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
[Sahay, Vasant ] 
Here is the explanation.
Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla.
 
By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports.
 
 
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11EC2.22B2DAC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 13:08:07 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B905F@ICARIAN> From: Fong Liaw To: 'Vasant Sahay' , Fong Liaw , Andre Fredette , Jonathan Lang , Bilel Jamoussi , Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Mon, 6 Aug 2001 13:05:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EB3.15DFEAE0" 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_01C11EB3.15DFEAE0 Content-Type: text/plain; charset="iso-8859-1" Hi, Vasant -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Sunday, August 05, 2001 2:20 PM To: Fong Liaw; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Fong, Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. [Fong] But LMP (which LMP-WDM uses the link-verification procedure) is out for a long-long time. NTIP is quite recent. We all have protocols that works in our lab/product and did not bother to bring them out. LMP does have first-mover advantage here. Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. [Fong] I would ask why would we make a protocol extensible if we do not plan to extend it to do other functions. The fact that we can simply add a sub-TLV to accomplish new functionality says that if I implement LMP, I have better chance of re-using my implementation. Also, if after I implement NTIP, do I still need to implement LMP so that an OLS can also work with a router that is not a master controller ? Or would you propose we extend NTIP to do that function as well ? If so, using your way of argument, I can claim that NTIP is not complete in this aspect either. [Fong] From my read to LMP/LMP-WDM, LMP has also thought through the control/data channel degradation issues and its implications to SLA. NTIP has no mention of it. Simply said that NTIP does not address configuration issues and therefore do not requirement persistent store does not really simplify my implementation/system. I have no doubt that NTIP brought its own contribution, but if NTIP wants to present itself as a superior/complete protocol, I am afraid you would not get strong support in that. We can continue the comparison game forever, but it will do no good to the industry. IMHO, the best way forward is to streamline LMP/LMP-WDM, as suggested by Bala, and I am sure Nortel will be able to contribute significantly, using experience from NTIP. Regards, -Fong Regards Vasant -----Original Message----- From: Fong Liaw [mailto:fliaw@zaffire.com] Sent: Friday, August 03, 2001 8:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) [Sahay, Vasant ] LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol. The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs". This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. [Sahay, Vasant ] Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ? NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? [Sahay, Vasant ] Here is the explanation. Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla. By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports. The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11EB3.15DFEAE0 Content-Type: text/html; charset="iso-8859-1"
Hi, Vasant
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Sunday, August 05, 2001 2:20 PM
To: Fong Liaw; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi Fong,
Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. 
 
[Fong]  But LMP (which LMP-WDM uses the link-verification procedure) is out for a long-long time. NTIP is quite recent.  We all have protocols that works in our lab/product and did not bother to bring them out. LMP does have first-mover advantage here.
 
Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. 
 
[Fong]  I would ask why would we make a protocol extensible if we do not plan to extend it to do other functions. The fact that we can simply add a sub-TLV to accomplish new functionality says that if I implement LMP, I have better chance of re-using my implementation. Also, if after I implement NTIP, do I still need to implement LMP so that an OLS can also work with a router that is not a master controller ? Or would you propose we extend NTIP to do that function as well ? If so, using your way of argument, I can claim that NTIP is not complete in this aspect either.
 
[Fong] From my read to LMP/LMP-WDM, LMP has also thought through the control/data channel degradation issues and its implications to SLA. NTIP has no mention of it. Simply said that NTIP does not address configuration issues and therefore do not requirement persistent store does not really simplify my implementation/system. I have no doubt that NTIP brought its own contribution, but if NTIP wants to present itself as a superior/complete protocol,  I am afraid you would not get strong support in that. We can continue the comparison game forever, but it will do no good to the industry. IMHO, the best way forward is to streamline LMP/LMP-WDM, as suggested by Bala, and I am sure Nortel will be able to contribute significantly, using experience from NTIP.  Regards, -Fong
 
 
Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors. 
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
[Sahay, Vasant ] 
LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol.
 
The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs".  This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly.
 
 
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. 
 
 
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. 
[Sahay, Vasant ] 
Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ?
 
 
 
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. 
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) 
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
[Sahay, Vasant ] 
Here is the explanation.
Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla.
 
By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports.
 
 
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11EB3.15DFEAE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 10:59:37 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006D41D3D@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Andre Fredette Cc: Jonathan Lang , "Bilel Jamoussi" , "Osama Aboul-Magd" , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Mon, 6 Aug 2001 10:52:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EA0.97BEF780" 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_01C11EA0.97BEF780 Content-Type: text/plain; charset="iso-8859-1" Andre, I am glad you agree that NTIP had mentioned link verification in the first draft. The reason for not elaborating on it's details was that we didnt want to jump into implementation details of all the features at once. We believe in building consensus on requirements and scope of the interface and then describing all the implementation details. By the way, you and Jonathan have not responded to my previous two ccamp-postings. Vasant -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Monday, August 06, 2001 2:29 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: Fong Liaw; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Let's try to be accurate Vasant. Link verification was not part of the initial NTIP spec (other than to mention that it would be good to do). You've added a couple paragraphs to the recent spec, but still don't have it fully specified, and do not even have the requisite messages defined. Sounds like "on the fly design" to me. By the way, just like everything else in NTIP, I'm sure it can be made to work, but WHY????? LMP already does it. Andre At 02:20 PM 8/5/2001 -0700, Vasant Sahay wrote: Hi Fong, Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. Regards Vasant -----Original Message----- From: Fong Liaw [ mailto:fliaw@zaffire.com ] Sent: Friday, August 03, 2001 8:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [ mailto:vasants@nortelnetworks.com ] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) [Sahay, Vasant ] LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol. The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs". This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. [Sahay, Vasant ] Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ? NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? [Sahay, Vasant ] Here is the explanation. Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla. By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports. The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11EA0.97BEF780 Content-Type: text/html; charset="iso-8859-1"
Andre,
I am glad you agree that NTIP had mentioned link verification in the first draft. The reason for not elaborating on it's details was that we didnt want to jump into implementation details of all the features at once. We believe in building consensus on requirements and scope of the interface and then describing all the implementation details.
 
By the way, you and Jonathan have not responded to my previous two ccamp-postings.
 
Vasant 
-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, August 06, 2001 2:29 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: Fong Liaw; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Let's try to be accurate Vasant.

Link verification was not part of the initial NTIP spec (other than to mention that it would be good to do).  You've added a couple paragraphs to the recent spec, but still don't have it fully specified, and do not even have the requisite messages defined.

Sounds like "on the fly design" to me.

By the way, just like everything else in NTIP, I'm sure it can be made to work, but WHY?????  LMP already does it.

Andre

At 02:20 PM 8/5/2001 -0700, Vasant Sahay wrote:
Hi Fong,
Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard.
 
Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below.
 
Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors.
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
[Sahay, Vasant ]
LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol.
 
The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs".  This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly.
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands.
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message.
[Sahay, Vasant ]
Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ?
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues.
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--)
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
[Sahay, Vasant ]
Here is the explanation.
Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla.
 
By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports.
 
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ?
 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.
Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.
I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.

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.
Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).

There are more examples of extra work due to LMP but we can discuss them one at a time.
The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".

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.
After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre

Cheers
Vasant
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11EA0.97BEF780-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 08:06:20 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040402088946@mail1.tellium.com> From: Hang Liu To: Bala Rajagopalan , "'kireeti@juniper.net'" Cc: "'ccamp@ops.ietf.org'" , "'mpls@UU.NET'" Subject: unnumbered links/control channel separation in GMPLS signaling Date: Mon, 6 Aug 2001 11:00:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi. Bala and Kireeti, By going over the new gmpls drafts and other two related drafts about unnumbered links and link bundles, draft-kompella-mpls-bundle-05.txt and draft-ietf-mpls-rsvp-unnum-01.txt, I have several questions and hope you can help me to clarify them. (1) In draft-ietf-mpls-generalized-rsvp-te-04.txt, section 8.1 defines IF_ID RSVP_HOP object that includes IF_ID TLV. It does not mention how to include IF_ID TLV in the ERO. Can I assume that IF_ID TLV can be put into ERO to replace normal explicit node/interface ID by the ingress node? The receiving node checks the initial subobject in the ERO to determine the outgoing link. If the receiving node is an intermediate node, it should copy the IF_ID TLV from the initial ERO subobject to the new IF_ID RSVP_HOP. This new IF_ID RSVP_HOP will be contained in the outgoing Path message to the next hop. Note that the initial subobject is removed from the ERO before the Path message is sent to next hop. (2) For unnumbered bundled links, the IF_ID in the ERO should be the IF_ID of this bundled link. If the bi-directional LSP is requested, both upstream IF_ID and downstream IF_ID will be included in ERO. Upstream IF_ID and downstream IF_ID may not be one-to-one mapping. However only one IF_ID TLV (IF_INDEX) is defined in section 9.1.1, draft-ietf-mpls-generalized-signaling-05.txt. Do we need to define a separate downstream IF_ID TLV and an upstream IF_ID TLV? This applies to the case of any unnumbered links/link bundles without upstream and downstream one-to-one mapping. Thank you very much. Hang Liu Tellium, Inc Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 Aug 2001 02:38:04 -0700 From: Andre Fredette To: Vasant Sahay Cc: Fong Liaw , Jonathan Lang , Bilel Jamoussi , Osama Aboul-Magd , ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010806052222.03c045f8@mailbox> Date: Mon, 06 Aug 2001 05:29:20 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1333507==_.ALT" --=====================_1333507==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Let's try to be accurate Vasant. Link verification was not part of the initial NTIP spec (other than to mention that it would be good to do). You've added a couple paragraphs to the recent spec, but still don't have it fully specified, and do not even have the requisite messages defined. Sounds like "on the fly design" to me. By the way, just like everything else in NTIP, I'm sure it can be made to work, but WHY????? LMP already does it. Andre At 02:20 PM 8/5/2001 -0700, Vasant Sahay wrote: Hi Fong, Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. Regards Vasant -----Original Message----- From: Fong Liaw [ mailto:fliaw@zaffire.com ] Sent: Friday, August 03, 2001 8:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [ mailto:vasants@nortelnetworks.com ] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) [Sahay, Vasant ] LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol. The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs". This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. [Sahay, Vasant ] Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ? NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? [Sahay, Vasant ] Here is the explanation. Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla. By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports. The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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. --=====================_1333507==_.ALT Content-Type: text/html; charset="us-ascii" Let's try to be accurate Vasant.

Link verification was not part of the initial NTIP spec (other than to mention that it would be good to do).  You've added a couple paragraphs to the recent spec, but still don't have it fully specified, and do not even have the requisite messages defined.

Sounds like "on the fly design" to me.

By the way, just like everything else in NTIP, I'm sure it can be made to work, but WHY?????  LMP already does it.

Andre

At 02:20 PM 8/5/2001 -0700, Vasant Sahay wrote:
Hi Fong,
Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard.
 
Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below.
 
Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors.
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
[Sahay, Vasant ]
LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol.
 
The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs".  This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly.
 
 
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands.
 
 
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message.
[Sahay, Vasant ]
Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ?
 
 
 
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues.
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--)
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
[Sahay, Vasant ]
Here is the explanation.
Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla.
 
By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports.
 
 
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ?
 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.
 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface
Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.
Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.
I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.

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.
Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).

There are more examples of extra work due to LMP but we can discuss them one at a time.
The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".

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.
After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre

Cheers
Vasant
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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.
--=====================_1333507==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 05 Aug 2001 14:23:20 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006CD8D90@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Fong Liaw , Andre Fredette , Jonathan Lang , "Bilel Jamoussi" , "Osama Aboul-Magd" Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Sun, 5 Aug 2001 14:20:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11DF4.66B358E0" 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_01C11DF4.66B358E0 Content-Type: text/plain; charset="iso-8859-1" Hi Fong, Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard. Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below. Regards Vasant -----Original Message----- From: Fong Liaw [mailto:fliaw@zaffire.com] Sent: Friday, August 03, 2001 8:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) [Sahay, Vasant ] LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol. The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs". This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. [Sahay, Vasant ] Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ? NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? [Sahay, Vasant ] Here is the explanation. Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla. By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports. The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11DF4.66B358E0 Content-Type: text/html; charset="iso-8859-1"
Hi Fong,
Control channel management is a basic requirement for any OLI implementation and all proposals on the table have it. Likewise NTIP and WDM-LMP both have mentioned link verification from the very beginning. So there is really no differentiation between the protocol-requirements in that regard.
 
Your suggestions to enhance LinkSummary message and to create a new data-link-sub-TLV actually support my point of "on the fly design" of WDM-LMP. Please see my comments below.
 
Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors. 
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
[Sahay, Vasant ] 
LMP and WDM-LMP propose use of this field to synchronize "the interface IDs and properties of TE links". These are static properties of TE links and their identifiers. That is all. It is not proposed to be used for synchronization of any dynamic information like failure reporting. As you said, an implementor can use his imagination and add more TLVs to achieve synchronization of failure status as well. But that brings out my point about an incomplete specification that risks implementors creating their own interpretations of the protocol.
 
The current WDM-LMP philosophy is "we defined some general purpose messages and hopefully we will be able to solve all problems by using them. If we discover missing requirements or behaviors, then we will add new TLVs".  This approach could be OK in case WDM-LMP was the only proposal and everybody was committed to incrementally revising it and patching up all the missing pieces by going over all the unthought-of behaviors. But that is not the case. NTIP has already thought through these requirements, behaviors and the messages. NTIP does not leave these protocol design decisions to implementors to decide on the fly.
 
 
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. 
 
 
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. 
[Sahay, Vasant ] 
Same point again. Missing piece in LMP. Already throught thru in NTIP. Why not use NTIP instead of fixing missing pieces in WDM-LMP based on feedback from NTIP ?
 
 
 
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. 
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) 
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
[Sahay, Vasant ] 
Here is the explanation.
Model is indeed that OLS does not need persistent store. During resynchronization phase, the OXC requests the status of all the ports it is interested in. Then OLS responds with its "dymanic" status for the requested ports. The burden of remembering which ports are to be monitored is on OXC and it teaches the OLS which ports to monitor. The key part here is recovering any updates that were lost while the link was down.Then onwards it is plain vanilla.
 
By the way, your last sentence refers to a "configuration state". We are not discussing configuration of OLS or the administrative states of ports here. But we are refereing to dynamic defect status on ports and enabling of defect reporting on OLS ports.
 
 
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11DF4.66B358E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 05 Aug 2001 05:20:26 -0700 Cc: "'Kireeti Kompella'" , ccamp@ops.ietf.org Message-ID: <3B6D3930.F19BD61A@lucent.com> Date: Sun, 05 Aug 2001 14:16:48 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Heiles Juergen Original-CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: AW: Drafts update Content-Type: multipart/mixed; boundary="------------82B8C8EAB9FB55288D96FA62" This is a multi-part message in MIME format. --------------82B8C8EAB9FB55288D96FA62 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Kireeti, I agree with Juergen that draft-fontana-ccamp-gmpls-g709-00.txt needs an = update before making it a WG document. I am in discussion for some months with D= imitri about this, but it is hard to get him to change text to support G.709. At= the moment the document is not compliant with G.709. Regards, Maarten Heiles Juergen wrote: > = > draft-fontana-ccamp-gmpls-g709-00.txt needs an update before making it = a WG document. > I am i ndiscussion with the authors. > = > Juergen > = > > -----Urspr=FCngliche Nachricht----- > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > Gesendet: Freitag, 27. Juli 2001 22:37 > > An: ccamp@ops.ietf.org > > Betreff: 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. > > --------------82B8C8EAB9FB55288D96FA62 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:mvissers@lucent.com 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 --------------82B8C8EAB9FB55288D96FA62-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 05 Aug 2001 05:03:11 -0700 Cc: "'Heiles Juergen'" , ccamp , "t1x1.5" , q11/15 Message-ID: <3B6D3573.68EC1969@lucent.com> Date: Sun, 05 Aug 2001 14:00:51 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'Heiles Juergen'" , ccamp , "t1x1.5" , q11/15 Subject: Re: ARE: [T1X1.5] arbitrary contiguous concatenation question Content-Type: multipart/mixed; boundary="------------28C5941AF6151650FE210EDD" This is a multi-part message in MIME format. --------------28C5941AF6151650FE210EDD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Eric, Let's discuss this issue during the IETF meeting in London. Being face to= face its easier to illustrate that a STS-3c isn't using 3 physically contiguou= s timeslots. For the standard contiguous concatenation (including STS-3c) there are T1= =2E105 and G.707 defining the timeslots used. But there are no transport plane documents that define the timeslot allocation for arbitrary concatenation= =2E I.e. is a STS-3a using physically contiguous timeslots or is it using the same= timeslots a STS-3c would use? As the gmpls-sonet-sdh document is the first and only standard describing= arbitrary concatenation, interworking is only guaranteed when it is unamb= iguous which timeslots are being used. Regards, Maarten "Mannie, Eric" wrote: > = > 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 ta= lking > 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= =2E707 > (used to have a clearer specification, and not used (transported) in an= y > protocol as far as I know) could imply that contiguous time-slots are n= ot > contiguous anymore ? > = > The "Arbitrary" concatenation that you are speaking about is a contiguo= us > 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 se= ems > 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:Juergen.Heiles@icn.siemens.de] > 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 ha= ve to > say. > = > Juergen > = > > -----Urspr=FCngliche Nachricht----- > > Von: Maarten Vissers [mailto:mvissers@lucent.com] > > Gesendet: Dienstag, 10. Juli 2001 11:14 > > An: ccamp > > Cc: t1x1.5; q11/15 > > Betreff: [T1X1.5] 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 > > --------------28C5941AF6151650FE210EDD 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:mvissers@lucent.com 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 --------------28C5941AF6151650FE210EDD-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 04 Aug 2001 15:59:43 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F044DB69D@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Fong Liaw , "Vasant Sahay" , Andre Fredette , Jonathan Lang , "Bilel Jamoussi" Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Sat, 4 Aug 2001 18:54:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11D38.6F8E5EE0" 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_01C11D38.6F8E5EE0 Content-Type: text/plain; charset="iso-8859-1" Fong, This is not NTIP requirement. It is an OLI requirement as stated in the requirement draft. ... and how exactly do you propose those sensible implementations to inter-work. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Fong Liaw [mailto:fliaw@zaffire.com] Sent: Friday, August 03, 2001 11:46 PM To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11D38.6F8E5EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

F= ong,

<= ![if = !supportEmptyParas]> 

=

T= his is not NTIP requirement. It is an OLI requirement as stated in the = requirement draft.

<= ![if = !supportEmptyParas]> 

=

&= #8230; and how exactly do you propose those sensible implementations to = inter-work.

<= ![if = !supportEmptyParas]> 

=

R= egards;

<= ![if = !supportEmptyParas]> 

=

Osama Aboul-Magd<= /p>

Nortel = Networks<= /p>

P.O. Box 3511, Station = "C"<= /p>

Ottawa, ON, = Canada<= /p>

K1Y - 4H7<= /p>

Tel: = 613-763-5827<= /p>

e.mail: = osama@nortelnetworks.com<= /p>

=  

=

-----Original Message-----
From: Fong Liaw [mailto:fliaw@zaffire.com]
Sent: Friday, August 03, = 2001 11:46 PM
To: Sahay, Vasant = [SC9:6909:EXCH]; Andre Fredette; Jonathan Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; = Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: = ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

 

Hi Vasant

 =

I have been watching this thread for a while. I believe both LMP, = LMP-WDM,=

and NTIP bring contribution to the OLI requirements.  Single out = requirements=

from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for = =

bringing in the importance of link verification and control channel maintenance etc.. 

 =

More comments below.  Best Regards, -Fong=

 =

-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August = 02, 2001 2:46 PM
To: Vasant Sahay; Andre = Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: = ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Andre, Jonathan,

Besides broken reliable transport in LMP I will like to list a few more items = here. Let us start with "resynchronization across = OLI".=

 =

When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do = not mention the requirements or behavior for any resynchronization to = recover the defect reports that might be lost during that = window.=

 =

NTIP has thought through these behaviors. =

 =

[Fong] It is quite often that MPLS/GMPLS authors leave this level of = details to sensible implementations. Sending LinkSummary message after = re-establishing LMP adjacency is sensible implementation. :-)=

 =

NTIP sessions go thru a resync process upon a restart. During resync, WDM = and OXC exchange information on the failures/defects that might have been lost = while the session was down. Also, if the NTIP session  went down while = OXC instructed the WDM to start monitoring some ports for defects or for = trace, obviously the command would be lost. NTIP resync also recovers such = lost commands. 

 =

[Fong] This is easily supported by adding a data-link sub-TLV = in LinkSummary message. 

 =

NTIP has also thought thru related requirements regarding persistence of = information on equipment. WDM-LMP or LMP has no thought on such = issues. =

 =

For example if a WDM box reboots for some reason, should it remember which = ports it was supposed to monitor for defects and trace ? Or should the OXC = instruct it again for which ports to monitor ? If WDM equipment has to remember = which ports it had to monitor, it translates into a requirement for WDM to have = persistent storage.

As mentioned above NTIP resync process solves these issues. For details please = refer to NTIP draft .--) 

 =

[Fong] I am not quite sure NTIP thought through its requirement of WDM = persistent storage either :-) Since the Configuration update = message has CStat but there is no message for a PXC to configure the WDM. This = translates to NTIP also requiring persistent store. If this is the case, why would = the monitor and trace request not be in persistent store ?  If the = model is that the OLS does not have persistent store, then it would not know = which port is enabled and would not be able to report a Configuration state. = Can you clarify ?

 =

The point is to show that NTIP has thought through issues specific to = OXC-to-DWDM interface. LMP and WDM-LMP have not. =

 =

Vasant=

-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August = 01, 2001 3:15 PM
To: Andre Fredette
Cc: = ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Andre,=

 =

>>>>= ;>> Funny you should say this given that the colleagues you reference in = your note claim that LMP is not needed at all. 
[Sahay, = Vasant ]=

I am wondering how we can keep our discussion = positive and constructive instead of pointing out assertions or getting into legal = analysis of statements.

My statement neither confirms nor denies my colleague's stand on = "need for LMP". The statement simply is "Andre if you were to base OLI = on LMP you will suffer the baggage".=

 =

>>>>>>> I believe (with a lot = of other people) that the use of TCP for this protocol is broken.  Please = refer to the numerous previous posts regarding this issue.=

[Sahay, Vasant ]=

If we used TCP for LMP it will certainly be broken = because LMP is  a WAN protocol and has to consider round trip delays, = variable losses and congestion. But not so for NTIP. NTIP runs in a controlled = local environment where the congestion control sophistications can be = disabled.=

By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable = transport. It can be one of the many available prorocols used for reliable = transport. =

The fundamental difference (in reliable = transmission) between NTIP and LMP is that NTIP is layered to run over a reliable = transport protocol, whereas WDM-LMP has an application implementing the = reliablity. =

 =

Also, in this context, on the LMP-baggage front, you = will need two flavors of retransmission schemes one for WAN (LMP) traffic, = and the other for  local traffic (WDM-LMP). Does that sound like = extra work ? 


 

>>>>>>>>>Furthermore if = you want to compare true protocol complexity, add the TCP states and events to = your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, = Vasant]=

The complexity of a readymade module is not a = consideration. The complexity of WDM-LMP and LMP code to be developed is the question = here. The objective is to compare the development and integration risk and = not the states within TCP or any existing transport protocol for that = matter.=


 

Vasant

 ---Origi= nal Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August = 01, 2001 7:59 AM
To: Sahay, Vasant = [SC9:6909:EXCH]
Cc: = ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns = derive from misunderstandings on your part.  Please see my comments = below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:

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


Funny you should say this given that the colleagues you reference in = your note claim that LMP is not needed at all.  However, your assertion that = there is still a lot of functionality that needs to be added to LMP is just = that, an assertion.  Furthermore, if this is truly the case, it would be = easy to separate the base LMP functionality (i.e., 99% of what's currently in = LMP), and create a separate document for the additional LMP functionality you = believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in = LMP which is not required by the OLI requirements is link bundling.  The = mechanisms for this feature may still be useful, but can also be easily = ignored. 


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


I believe (with a lot of other people) that the use of TCP for this = protocol is broken.  Please refer to the numerous previous posts regarding = this issue.



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


Fault isolation is not an integral part of the LMP protocol.  The = LMP spec describes how switching devices (e.g., OXCs) can use the fault = notification information from LMP to localize faults and make the appropriate = switching decisions.  We clearly spelled out in LMP-WDM that the OLS does = not participate in fault localization (only fault detection and = notification).



There are more examples of extra work due = to LMP but we can discuss them one at a time.=


The above concerns are the only ones you have ever mentioned.  = Given my explanations above, I still don't believe you have Identified any = examples of "extra work".



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


After you have fully specified NTIP, I'm sure that the only difference = will be attributable to the treatment of application-level acks (which the = majority on this discussion list feel are required for a correct protocol).  =

Furthermore if you want to compare true protocol complexity, add the = TCP states and events to your NTIP count, handle fail-over of TCP sessions, and = then come talk to me.

Andre



Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, = 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; = ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com] =

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

To: 'Andre Fredette'; 'ccamp@ops.ietf.org' =

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:fredette@photonex.com]<= /span>

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

To: ccamp@ops.ietf.org

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:kireeti@juniper.net]

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

>To: jamoussi@nortelnetworks.com; = kireeti@juniper.net;

>osama@nortelnetworks.com

>Cc: bon@nortelnetworks.com; = ccamp@ops.ietf.org;

>vasants@nortelnetworks.com

>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_01C11D38.6F8E5EE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Aug 2001 20:49:20 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B9056@ICARIAN> From: Fong Liaw To: 'Vasant Sahay' , Andre Fredette , Jonathan Lang , Bilel Jamoussi , Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Fri, 3 Aug 2001 20:45:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11C97.F25D1330" 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_01C11C97.F25D1330 Content-Type: text/plain; charset="iso-8859-1" Hi Vasant I have been watching this thread for a while. I believe both LMP, LMP-WDM, and NTIP bring contribution to the OLI requirements. Single out requirements from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for bringing in the importance of link verification and control channel maintenance etc.. More comments below. Best Regards, -Fong -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Thursday, August 02, 2001 2:46 PM To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. [Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-) NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. [Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) [Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ? If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ? The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11C97.F25D1330 Content-Type: text/html; charset="iso-8859-1"
Hi Vasant
 
I have been watching this thread for a while. I believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI requirements.  Single out requirements
from NTIP is not a fair statement since LMP/LMP-WDM can claim the same for
bringing in the importance of link verification and control channel maintenance etc.. 
 
More comments below.  Best Regards, -Fong
 
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama Aboul-Magd
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors. 
 
[Fong] It is quite often that MPLS/GMPLS authors leave this level of details to sensible implementations. Sending LinkSummary message after re-establishing LMP adjacency is sensible implementation. :-)
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. 
 
[Fong] This is easily supported by adding a data-link sub-TLV in LinkSummary message. 
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. 
 
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) 
 
[Fong] I am not quite sure NTIP thought through its requirement of WDM persistent storage either :-) Since the Configuration update message has CStat but there is no message for a PXC to configure the WDM. This translates to NTIP also requiring persistent store. If this is the case, why would the monitor and trace request not be in persistent store ?  If the model is that the OLS does not have persistent store, then it would not know which port is enabled and would not be able to report a Configuration state. Can you clarify ?
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11C97.F25D1330-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Aug 2001 10:14:34 -0700 Date: Fri, 3 Aug 2001 09:56:51 -0700 (PDT) From: Kireeti Kompella Message-Id: <200108031656.JAA14631@kummer.juniper.net> To: gnewsome@lucent.com, lberger@movaz.com Subject: Re: new gmpls signaling drafts Cc: ccamp@ops.ietf.org George, What you suggest would be very helpful, but is also a fair amount of work for the authors/editors. Going over the drafts one more time would be necessary anyway. So, I'm inclined to go with Lou's idea: would the original commentators check whether their comments have been incorporated, and email either the list or the editors? And others are of course invited to reread and make comments as well. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 Aug 2001 09:33:55 -0700 Message-Id: <4.3.2.7.2.20010803115137.024c9df0@mo-ex1> Date: Fri, 03 Aug 2001 11:55:39 -0400 To: George Newsome From: Lou Berger Subject: Re: new gmpls signaling drafts Cc: Lou Berger ,ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I of course can't speak for the chairs, but I'd suggest that anyone who has specific issues related to the revised drafts do raise the issues on the list. (or privately if you/they prefer.) Lou At 05:13 PM 8/1/01, George Newsome wrote: >Lou, > >Now that I'm back from my vaccation, and am struggling through the many >emails, I have got to the new gmpls documents that you announced. > >draft-ietf-mpls-generalized-signaling-05.txt >draft-ietf-mpls-generalized-rsvp-te-04.txt >draft-ietf-mpls-generalized-cr-ldp-04.txt > >As there were a very large number of comments posted, it is almost >impossible to determine from the documents how those comments were >handled, or even if they were handled. While the comments were comming >in Bert Wijnen asked the CCAMP WG chairs to summarize the issues and >post the summaries. I haven't seen any such summary (but perhaps I just >missed it). > >I also expected to see a statement from the editors as to how each issue >was resolved. > >Is there any intention to provide such a summary and statement of issue >resolution? >Without this information I find it very hard to consider the documents >ready. > >Regards > > George Newsome > >=========================================================================================== > > From: "Wijnen, Bert (Bert)" > > To: ccamp-wg > > Subject: WG Last Call on GMPLS documents > > Date: Tue, 19 Jun 2001 23:28:06 +0200 > > MIME-Version: 1.0 > > Content-Type: text/plain > > > > When flooded with the many postings/comments, I sometimes hate > > it when people are giving so much comments. But at the other hand, > > it also shows that we do get feedback from the community. > > > > The WG Last Call was a joint call between MPLS and CCAMP WGs. > > This was done because the 4 documents were in transit from MPLS > > to CCAMP WG. As a result we saw a lot of (too much!) cross posting. > > > > > - from now on we want discussion on CCAMP mailing list. Pls do not > > > copy MPLS and IPO mailing lists... if you want to participate, pls > > > join CCAMP mailing list. > > > - BUT... before you send more comments... pls hold off for a bit. > > > There are some 1000 or so postings to the WG Last Call. > > > I have asked the CCAMP WG chairs to try and make a summary of > > > the issues. Once they have done that, they will post them and try to > > > find out how many people agree/disagree with each issue. > > > I.e. they will try to find out if there is WG consensus on what the > > > issues are. > > > - I believe there were some suggested "fixes" to address some issues > > > as well. The WG chairs will also try to summarize these and again > > > then try to find out how much WG support there is for these "fixes". > > > - Then we will take it from there. > > > > > Thanks, > > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 16:07:17 -0700 Message-Id: <4.3.2-J.20010803075152.00c0eb60@mail.onw.kddlabs.co.jp> Date: Fri, 03 Aug 2001 08:09:37 +0900 To: ccamp@ops.ietf.org From: Tomohiro Otani Subject: BER value of TLV in LMP-WDM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear all, I am not sure that this has been discussed or not yet. Regarding the bit error ratio (BER) value of TLV defined in LMP-WDM draft, the applicable BER or BER threshold is defined to set as 1x10^(-5) or 1x10^(-7). >From the carrier's point of view, this value is a little bit coarse, and a finer value such as 3.2x10^(-9) or 5.8x10^(-5) is preferable. (fortunately, some bits are still reserved) Imagining that the future OLS will have a forward error correction (FEC) function, the BER can be kept high even with some degradation, however, it may suddenly degrade once quite large degradation occurs. (this is mainly coming from the very steep curve of the relationship between an uncorrected BER and a corrected BER) In this case, we might care about the threshold of BER for switching. and a more finer value should be executable. With best regards, TOMO ------------------------------------ Tomohiro Otani KDDI R&D Laboratories, Inc. Optical network laboratory TEL: +81-492-78-7357 FAX: +81-492-78-7510 E-mail: otani@kddlabs.co.jp (From 7/1, otani@kddilabs.jp) Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 14:50:40 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C958A5@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Vasant Sahay" , Andre Fredette , Jonathan Lang , "Bilel Jamoussi" , "Osama Aboul-Magd" Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Thu, 2 Aug 2001 14:46:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11B9C.93A05150" 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_01C11B9C.93A05150 Content-Type: text/plain; charset="iso-8859-1" Andre, Jonathan, Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI". When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window. NTIP has thought through these behaviors. NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands. NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues. For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage. As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--) The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not. Vasant -----Original Message----- From: Sahay, Vasant [SC9:6909:EXCH] Sent: Wednesday, August 01, 2001 3:15 PM To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11B9C.93A05150 Content-Type: text/html; charset="iso-8859-1"
Andre, Jonathan,
Besides broken reliable transport in LMP I will like to list a few more items here. Let us start with "resynchronization across OLI".
 
When an LMP session fails for some reason and recovers later, WDM-LMP or LMP do not mention the requirements or behavior for any resynchronization to recover the defect reports that might be lost during that window.
 
NTIP has thought through these behaviors.
 
NTIP sessions go thru a resync process upon a restart. During resync, WDM and OXC exchange information on the failures/defects that might have been lost while the session was down. Also, if the NTIP session  went down while OXC instructed the WDM to start monitoring some ports for defects or for trace, obviously the command would be lost. NTIP resync also recovers such lost commands.
 
NTIP has also thought thru related requirements regarding persistence of information on equipment. WDM-LMP or LMP has no thought on such issues.
For example if a WDM box reboots for some reason, should it remember which ports it was supposed to monitor for defects and trace ? Or should the OXC instruct it again for which ports to monitor ? If WDM equipment has to remember which ports it had to monitor, it translates into a requirement for WDM to have persistent storage.
As mentioned above NTIP resync process solves these issues. For details please refer to NTIP draft .--)
 
The point is to show that NTIP has thought through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have not.
 
Vasant
-----Original Message-----
From: Sahay, Vasant [SC9:6909:EXCH]
Sent: Wednesday, August 01, 2001 3:15 PM
To: Andre Fredette
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11B9C.93A05150-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 14:31:59 -0700 Message-ID: <710197BD5AF9D4119E4400508BCFA13601411C79@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: "Dawkins, Spencer" , "'''ccamp@ops.ietf.org' ' '" Cc: "Ewart Tempest" Subject: RE: Optical Link Interface Date: Thu, 2 Aug 2001 17:28:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11B9A.09D98B50" 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_01C11B9A.09D98B50 Content-Type: text/plain; charset="iso-8859-1" Spencer, I don't really want to get involved in this monotanous debate. However, to answer your question below, yes, all traffic being passed will be painted with the same brush wrt sequenced delivery, even if the order of delivery of some of this data is not important. Alarms/notifications fall very much into the "I do care" category. The degree to which misdelivery of other types of application messages fall into the "I do care" category totally depends on the application protocol - without being familiar with the OLI or the proposed LMP-WDM/NTIP message sets, I cannot comment on the %age of messages conveyed within a typical OLI session for which ordered delivery will be important. TCP also has another benefit, however, which seems to have been overlooked, and that is end-to-end flow control. I'll let the LMP-WDM/NTIP respective propenents lay down their flow control mechanisms, or otherwise specify why they think it is not required. Ewart -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Thursday, August 02, 2001 1:16 PM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Dear Vasant, Are there any other TCP optimizations you are considering? Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)... Spencer -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Wednesday, August 01, 2001 5:15 PM To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Dear Spencer, LMP is a WAN protocol hence losses, round trip times and congestion control are more involved. NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple. Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application. Please see my related comments in other ccamp responses as well. Vasant -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Tuesday, July 31, 2001 2:17 PM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface 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 is an interesting overview, but doesn't BEGIN to reflect the volume level. Thanks for any insights you can provide. Spencer ------_=_NextPart_001_01C11B9A.09D98B50 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Spencer,
 
I don't really want to get involved in this monotanous debate. However, to answer your question below, yes, all traffic being passed will be painted with the same brush wrt sequenced delivery, even if the order of delivery of some of this data is not important. Alarms/notifications fall very much into the "I do care" category. The degree to which misdelivery of other types of application messages fall into the "I do care" category totally depends on the application protocol - without being familiar with the OLI or the proposed LMP-WDM/NTIP message sets, I cannot comment on the %age of messages conveyed within a typical OLI session for which ordered delivery will be important.
 
TCP also has another benefit, however, which seems to have been overlooked, and that is end-to-end flow control. I'll let the LMP-WDM/NTIP respective propenents lay down their flow control mechanisms, or otherwise specify why they think it is not required.
 
Ewart
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Thursday, August 02, 2001 1:16 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

Dear Vasant,
 
Are there any other TCP optimizations you are considering?
 
Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)...
 
Spencer
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Wednesday, August 01, 2001 5:15 PM
To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

Dear Spencer,
LMP is a WAN protocol hence losses, round trip times and congestion control are more involved.
NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple.  Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application.
 
Please see my related comments in other ccamp responses as well.
 
Vasant
 
 
 
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Tuesday, July 31, 2001 2:17 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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 is an interesting overview, but doesn't BEGIN to reflect the volume level.
 
Thanks for any insights you can provide.
 
Spencer
------_=_NextPart_001_01C11B9A.09D98B50-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 13:30:27 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C9570B@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Dawkins, Spencer" , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Thu, 2 Aug 2001 13:26:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11B91.6C761390" 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_01C11B91.6C761390 Content-Type: text/plain; charset="iso-8859-1" Dear Spencer, We have also recommended shortening the retransmit timer and turning Nagle off. In-order delivery is a requirement for NTIP/OLI. As an example, if a DWDM system reports a defect such as SF (SIgnal Fail) for a port to OXC, the OXC will condider the port failed untill a DC (Defect Clear) is reported by DWDM. Hence maintaining the order of failure reporting(SF), and clearing of failure(DC) is critical. When we co-authored the requirements for OLI we specified that OLI needs a reliable transport protocol. We dont want OLI to reinvent a new mechanism for recovering lost messages. NTIP is designed to use services from an existing reliable transport protocol. TCP is a reasonable and mature solution so we picked it. As we go further, if a better reliable transport protocol is identifed we are open to adopting it. However LMP invents that part and the details are not thought through yet. Also, as you know the round trip delays, flow control and congestion control in any implementation will have different implications for WAN and LAN environment. Since LMP is proposed over WAN as plain LMP and over LAN as WDM-LMP, the recovery scheme will need additional work on tuning it for the two applications.Reinventing a solution (as in case of LMP), has additional technical, business and time-to-market issues. Regards Vasant -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Thursday, August 02, 2001 10:16 AM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Dear Vasant, Are there any other TCP optimizations you are considering? Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)... Spencer -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Wednesday, August 01, 2001 5:15 PM To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Dear Spencer, LMP is a WAN protocol hence losses, round trip times and congestion control are more involved. NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple. Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application. Please see my related comments in other ccamp responses as well. Vasant -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Tuesday, July 31, 2001 2:17 PM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface 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 is an interesting overview, but doesn't BEGIN to reflect the volume level. Thanks for any insights you can provide. Spencer ------_=_NextPart_001_01C11B91.6C761390 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Dear Spencer,
We have also recommended shortening the retransmit timer and turning Nagle off.
 
In-order delivery  is a requirement for NTIP/OLI. As an example, if a DWDM system reports a defect such as SF (SIgnal Fail) for a port to OXC, the OXC will condider the port failed untill a DC (Defect Clear) is reported by DWDM. Hence maintaining the order of failure reporting(SF), and clearing of failure(DC) is critical.
 
When we co-authored the requirements for OLI we specified that OLI needs a reliable transport protocol. We dont want OLI to reinvent a new mechanism for recovering lost messages. NTIP is designed to use services from an existing reliable transport protocol. TCP is a reasonable and mature solution so we picked it. As we go further, if a better reliable transport protocol is identifed we are open to adopting it.
 
However LMP invents that part and the details are not thought through yet. Also, as you know the round trip delays, flow control and congestion control in any implementation will have different implications for WAN and LAN environment. Since LMP is proposed over WAN as plain LMP and over LAN as WDM-LMP, the recovery scheme will need additional work on tuning it for the two applications.Reinventing a solution (as in case of LMP), has additional technical, business and time-to-market issues.
 
Regards
Vasant
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Thursday, August 02, 2001 10:16 AM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

Dear Vasant,
 
Are there any other TCP optimizations you are considering?
 
Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)...
 
Spencer
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Wednesday, August 01, 2001 5:15 PM
To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

Dear Spencer,
LMP is a WAN protocol hence losses, round trip times and congestion control are more involved.
NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple.  Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application.
 
Please see my related comments in other ccamp responses as well.
 
Vasant
 
 
 
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Tuesday, July 31, 2001 2:17 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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 is an interesting overview, but doesn't BEGIN to reflect the volume level.
 
Thanks for any insights you can provide.
 
Spencer
------_=_NextPart_001_01C11B91.6C761390-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 11:08:04 -0700 Message-ID: From: "Dawkins, Spencer" To: "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Thu, 2 Aug 2001 12:15:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11B76.BEC2C190" 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_01C11B76.BEC2C190 Content-Type: text/plain; charset="iso-8859-1" Dear Vasant, Are there any other TCP optimizations you are considering? Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)... Spencer -----Original Message----- From: Vasant Sahay [mailto:vasants@nortelnetworks.com] Sent: Wednesday, August 01, 2001 5:15 PM To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Dear Spencer, LMP is a WAN protocol hence losses, round trip times and congestion control are more involved. NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple. Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application. Please see my related comments in other ccamp responses as well. Vasant -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Tuesday, July 31, 2001 2:17 PM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface 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 is an interesting overview, but doesn't BEGIN to reflect the volume level. Thanks for any insights you can provide. Spencer ------_=_NextPart_001_01C11B76.BEC2C190 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Dear Vasant,
 
Are there any other TCP optimizations you are considering?
 
Another frequent reason given for not using TCP is that TCP delays delivery of received data while missing data is recovered. TCP forces in-order delivery, even if there's no dependence on ordering (so, in this case, does the order alarms are received in really matter?)...
 
Spencer
-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Wednesday, August 01, 2001 5:15 PM
To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

Dear Spencer,
LMP is a WAN protocol hence losses, round trip times and congestion control are more involved.
NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple.  Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application.
 
Please see my related comments in other ccamp responses as well.
 
Vasant
 
 
 
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Tuesday, July 31, 2001 2:17 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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 is an interesting overview, but doesn't BEGIN to reflect the volume level.
 
Thanks for any insights you can provide.
 
Spencer
------_=_NextPart_001_01C11B76.BEC2C190-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 Aug 2001 05:56:21 -0700 Message-ID: <3B694D52.ACDD4BED@lucent.com> Date: Thu, 02 Aug 2001 08:53:38 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: manoj juneja CC: kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: GMPLS Routing Drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, First, I've to confess that I haven't read the related drafts very carefully. Below is just what I think. > My thinking is totally different. I am saying that what is > the advantage of having control channel network information in routing > protocols. > > Say I have following type of network. There are some SDH/SONET interfaces > between the nodes. According to what u are saying, that routing databases at > each of these nodes are aware of IPCCs (between each of these) and data > channel/interfaces. But I am saying that routing protocol should be aware of > only the data interfaces. It should not be aware of control channels. As > control channel information is not going to change dynamically, this can be > statically configured. For e.g. I can configure that for data > channels/interfaces say 1..10 the list of vaious CCIds to use. For different > data channel/interfaces, I can use different set of control channels. Only > information that the routing module be aware of is about data > channels/interfaces. > > A ---> B ---> C > | > | > V > D > > Do u feel that control channel information is a dynamic information (i.e. > going to change very often) ? > Control channel information is not dynamic in the normal case. But it could be very dynamic in case of network failure, migration, upgrading etc. Actually, your thinking is not different from mine but addresses a different perspective. In GMPLS, logically there are two routing "entities", one for the control traffic, one for the user traffic. You are right that the routing entity for user traffic doesn't care about the topology etc. of the control plane network. However, in the implementation, both topology information could be disseminated through a same engine (or "protocol"), the control plane network OSPF or ISIS. So I don't see disagreement but misunderstanding. Am I right, Kireeti? Thanks, Yangguang > Regards, > manoj. > > >From: Yangguang Xu > >To: manoj juneja > >CC: kireeti@juniper.net, ccamp@ops.ietf.org > >Subject: Re: GMPLS Routing Drafts > >Date: Wed, 01 Aug 2001 19:25:50 -0400 > > > >Manoj, > > > >I think Kireeti is right. Probably the confusion comes from "control > >channels". > >It's actually a control network running OSPF or ISIS. The control network > >topology doesn't need to be the same as the data plane topology. However, > >you > >can assume that each pair of network elements have IP reachability through > >the > >control network. GMPLS transport network topology is disseminated through > >opaque > >LSA (in case of OSPF). At each NE, there are two logical topology > >databases. One > >for the control plane network, a vanilla IP network. Another one is for the > >data > >plane network, similar to OSPF-TE topology database. > > > >Regards, > > > >Yangguang > > > >manoj juneja wrote: > > > > > > Hi Kireeti, > > > I have read the second last para of the draft. It > > > states "We call the interfaces over which regular routing adjacencies > > > are established "control channels". This definition restricts its scope > > > to routing adjacencies i.e. the control channels over which OSPF > > > control packets are going to be sent. Does this mean for sending the > > > GMPLS control messages, the same routing adjacencies are going to be > > > used ? If yes, then how to distinguish between the control channels > > > between two OSPF instances and GMPLS instances ? If no, then how this > > > GMPLS control channel information is transmitted in routing protocols ? > > > > > > Regards, > > > manoj. > > > > > > >From: Kireeti Kompella > > > >To: ccamp@ops.ietf.org > > > >Subject: Re: GMPLS Routing Drafts > > > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > > > > > > > >Hi Manoj, > > > > > > > > > In section 5.1 of Ist draft, it is mentioned > > > > > that "control channels are advertised into routing as normal links > >as > > > > > mentioned in previous section". But in previous section of document > >I, > > > > > there is no reference of control channels. > > > > > > > >Read the second last para of section 5. > > > > > > > > > Furthermore, in OSPF > > > > > extensions document (IInd draft), there is no mention of control > > > > > channels at all. > > > > > > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft > > > >deals with the formats of the GMPLS TE extensions. As the abstract > >says: > > > > > > > > This document specifies encoding of extensions to the OSPF routing > > > > protocol in support of Generalized Multi-Protocol Label Switching > > > > (GMPLS). The description of the extensions is specified in [GMPLS- > > > > ROUTING]. > > > > > > > >BTW, since you have a penchant for pedantry, let me point out that > > > >it is inconsistent to call a "missing reference" (or a "no mention") > > > >an "inconsistency". > > > > > > > >On the other hand, we do appreciate your careful reading. > > > > > > > >Kireeti. > > > > > > > > > > _________________________________________________________________ > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 20:20:25 -0700 From: "manoj juneja" To: skalipat@starpower.net, kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: GMPLS Routing Drafts Date: Wed, 01 Aug 2001 20:16:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Sitaram, I do appreciate ur response. My question was totally different. My main doubt is why should I need information of GMPLS control channel network in GMPLS routing instance ? IMHO, the GMPLS routing instance should be aware of data channel interfaces and not the control channel interfaces (used for GMPLS control messages and not the control channels used for OSPF routing advertisements) ? Regards, manoj. >From: "S Kalipatnapu" >To: "manoj juneja" , , > >Subject: Re: GMPLS Routing Drafts >Date: Wed, 1 Aug 2001 20:12:07 -0400 > >Manoj, > >I am not sure, if I understand your question completely and Kireeti may >give >a better answer, but if it helps, it may be noted that sub-IP routing >instance uses control channels for advertising sub-IP domain reachability, >while the IP routing instance advertises over the data channel forwarding >adjacencies created by the GMPLS control plane. > >Cheers, >--Sitaram > >----- Original Message ----- >From: "manoj juneja" >To: ; >Sent: Wednesday, August 01, 2001 5:01 PM >Subject: Re: GMPLS Routing Drafts > > > > Hi Kireeti, > > I have read the second last para of the draft. It > > states "We call the interfaces over which regular routing adjacencies > > are established "control channels". This definition restricts its scope > > to routing adjacencies i.e. the control channels over which OSPF > > control packets are going to be sent. Does this mean for sending the > > GMPLS control messages, the same routing adjacencies are going to be > > used ? If yes, then how to distinguish between the control channels > > between two OSPF instances and GMPLS instances ? If no, then how this > > GMPLS control channel information is transmitted in routing protocols ? > > > > Regards, > > manoj. > > > > > > > > >From: Kireeti Kompella > > >To: ccamp@ops.ietf.org > > >Subject: Re: GMPLS Routing Drafts > > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > > > > > >Hi Manoj, > > > > > > > In section 5.1 of Ist draft, it is mentioned > > > > that "control channels are advertised into routing as normal links >as > > > > mentioned in previous section". But in previous section of document >I, > > > > there is no reference of control channels. > > > > > >Read the second last para of section 5. > > > > > > > Furthermore, in OSPF > > > > extensions document (IInd draft), there is no mention of control > > > > channels at all. > > > > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft > > >deals with the formats of the GMPLS TE extensions. As the abstract >says: > > > > > > This document specifies encoding of extensions to the OSPF routing > > > protocol in support of Generalized Multi-Protocol Label Switching > > > (GMPLS). The description of the extensions is specified in [GMPLS- > > > ROUTING]. > > > > > >BTW, since you have a penchant for pedantry, let me point out that > > >it is inconsistent to call a "missing reference" (or a "no mention") > > >an "inconsistency". > > > > > >On the other hand, we do appreciate your careful reading. > > > > > >Kireeti. > > > > > > > > > _________________________________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 20:14:09 -0700 From: "manoj juneja" To: xuyg@lucent.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: GMPLS Routing Drafts Date: Wed, 01 Aug 2001 20:11:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Yangguang, My thinking is totally different. I am saying that what is the advantage of having control channel network information in routing protocols. Say I have following type of network. There are some SDH/SONET interfaces between the nodes. According to what u are saying, that routing databases at each of these nodes are aware of IPCCs (between each of these) and data channel/interfaces. But I am saying that routing protocol should be aware of only the data interfaces. It should not be aware of control channels. As control channel information is not going to change dynamically, this can be statically configured. For e.g. I can configure that for data channels/interfaces say 1..10 the list of vaious CCIds to use. For different data channel/interfaces, I can use different set of control channels. Only information that the routing module be aware of is about data channels/interfaces. A ---> B ---> C | | V D Do u feel that control channel information is a dynamic information (i.e. going to change very often) ? Regards, manoj. >From: Yangguang Xu >To: manoj juneja >CC: kireeti@juniper.net, ccamp@ops.ietf.org >Subject: Re: GMPLS Routing Drafts >Date: Wed, 01 Aug 2001 19:25:50 -0400 > >Manoj, > >I think Kireeti is right. Probably the confusion comes from "control >channels". >It's actually a control network running OSPF or ISIS. The control network >topology doesn't need to be the same as the data plane topology. However, >you >can assume that each pair of network elements have IP reachability through >the >control network. GMPLS transport network topology is disseminated through >opaque >LSA (in case of OSPF). At each NE, there are two logical topology >databases. One >for the control plane network, a vanilla IP network. Another one is for the >data >plane network, similar to OSPF-TE topology database. > >Regards, > >Yangguang > >manoj juneja wrote: > > > > Hi Kireeti, > > I have read the second last para of the draft. It > > states "We call the interfaces over which regular routing adjacencies > > are established "control channels". This definition restricts its scope > > to routing adjacencies i.e. the control channels over which OSPF > > control packets are going to be sent. Does this mean for sending the > > GMPLS control messages, the same routing adjacencies are going to be > > used ? If yes, then how to distinguish between the control channels > > between two OSPF instances and GMPLS instances ? If no, then how this > > GMPLS control channel information is transmitted in routing protocols ? > > > > Regards, > > manoj. > > > > >From: Kireeti Kompella > > >To: ccamp@ops.ietf.org > > >Subject: Re: GMPLS Routing Drafts > > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > > > > > >Hi Manoj, > > > > > > > In section 5.1 of Ist draft, it is mentioned > > > > that "control channels are advertised into routing as normal links >as > > > > mentioned in previous section". But in previous section of document >I, > > > > there is no reference of control channels. > > > > > >Read the second last para of section 5. > > > > > > > Furthermore, in OSPF > > > > extensions document (IInd draft), there is no mention of control > > > > channels at all. > > > > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft > > >deals with the formats of the GMPLS TE extensions. As the abstract >says: > > > > > > This document specifies encoding of extensions to the OSPF routing > > > protocol in support of Generalized Multi-Protocol Label Switching > > > (GMPLS). The description of the extensions is specified in [GMPLS- > > > ROUTING]. > > > > > >BTW, since you have a penchant for pedantry, let me point out that > > >it is inconsistent to call a "missing reference" (or a "no mention") > > >an "inconsistency". > > > > > >On the other hand, we do appreciate your careful reading. > > > > > >Kireeti. > > > > > > > _________________________________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 18:59:21 -0700 Message-ID: <3B68B3B3.50B72F07@lucent.com> Date: Wed, 01 Aug 2001 21:58:11 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Ayan Banerjee CC: "'ccamp@ops.ietf.org'" , "'manojkumarjuneja@hotmail.com'" Subject: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ayan, > The TSpec, as I understand it, carries only bandwidth information > for some label types. I think it carries more than that. It carries the signal type, and a signal type specifies the bandwidth information implicitly. More important, a signal type specifies what type of circuit connection you want to switch, e.g. a SONET LSP or a SDH LSP, and other details. Please refer to the SONET/SDH draft. > As a result, we do need the encoding type > and the switching capability field for a mutli-service platform > to allocate resources and/or validate a particular connection > encoding type. I think we agree until here. > My point is that we don't need switching capability field. The previous version works fine. Again, the encoding type + signal type can identify what kind of connection you want to set up. No further information is needed. For example, if a NE receives a request with encoding type = SONET, signal type = STS-1. Even the NE has dual switching fabrics, say one STS-1 SF and one packet SF, the NE knows exactly what to do. > For example, if a TE link has both SDH and SONET "ports" bundled > within it (a list of interface switching capability descriptors > allow for this), it has to be notified that this request is for a > SONET port. This is not negotiation, it is a request to get a resource > for a port that can carry a particular type of connection. The TE-link > should not at this time give you a resource label for a SDH port when > you request for a SONET port. As a result, this field also needs to be > carried while signaling setup request is made. > First, the example is a little bit weird to me (probably because of my limited experience). If the NE is a SONET/SDH gateway, SONET and SDH ports should be separate to east bound and west bound. They wouldn't mix. However, let take your example. First, if you have both SDH and SONET "ports", they should be bundled as two different logical links. Your routing algorithm should specify which bundle to use. Then at each node, the local intelligence chooses the a component interface ID from the bundle ID in the ERO. When the next node receives the request with the component interface ID, it should choose the egress port with the same physical attributes. So you don't need switching capacity field, neither the "port" encoding type. If they are not bundled separately, from the signal type, a NE knows the request is for a SONET STS-1 (for example), it chooses the SONET port, not the SDH port. The key is that the encoding type is the requested LSP encoding type, not the "port" encoding type. In either case, a NE doesn't need to worry about the port encoding type in the signaling other than the LSP encoding type + signal type. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 18:43:01 -0700 Message-ID: From: Ayan Banerjee To: 'manoj juneja ' , "'xuyg@lucent.com '" Cc: "'ccamp@ops.ietf.org '" Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 1 Aug 2001 18:41:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, I was just giving an example with respect to your query why we need to carry encoding information along with switching capability. I am sure that there are other examples where one can concot similar scenarios. I am sure that if you have a suggestion as to how to incorporate multi-service platforms in the GMPLS framework we can look into it. Thanks, Ayan -----Original Message----- From: manoj juneja To: abanerjee@calient.net; xuyg@lucent.com Cc: ccamp@ops.ietf.org Sent: 8/1/2001 5:46 PM Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Hi Ayan, I think the concept of adding both SDH and SONET links in one TE link is not fine. If we restrict the definition of TE link by saying that it must contain the ports/links of same technology or type. We are trying to add more complexity in signalling protocols by expanding the definition of TE link. U need to take care of both SDH and SONET links only at the gateways (SDH and SONET interworking points only). These things can be done easily by restricting the definition of a TE link. Please correct me if I am wrong. Regards, manoj >From: Ayan Banerjee >To: 'Yangguang Xu' >CC: "'ccamp@ops.ietf.org'" , >"'manojkumarjuneja@hotmail.com'" >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt >Date: Wed, 1 Aug 2001 17:03:48 -0700 > >Yangguang, > >The TSpec, as I understand it, carries only bandwidth information >for some label types. As a result, we do need the encoding type >and the switching capability field for a mutli-service platform >to allocate resources and/or validate a particular connection >encoding type. I think we agree until here. > >For example, if a TE link has both SDH and SONET "ports" bundled >within it (a list of interface switching capability descriptors >allow for this), it has to be notified that this request is for a >SONET port. This is not negotiation, it is a request to get a resource >for a port that can carry a particular type of connection. The TE-link >should not at this time give you a resource label for a SDH port when >you request for a SONET port. As a result, this field also needs to be >carried while signaling setup request is made. > >Thanks, >Ayan > > > > >-----Original Message----- >From: Yangguang Xu [mailto:xuyg@lucent.com] >Sent: Wednesday, August 01, 2001 4:15 PM >To: Ayan Banerjee >Cc: 'ccamp@ops.ietf.org'; 'manojkumarjuneja@hotmail.com' >Subject: Re: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >Ayan, > >I think Manoj is right. In GMPLS signaling, encoding type and signal type >in >TSpec together should form one meaningful unit to specify what type of LSP >to >create. In another word, you should parse the traffic parameters according >to >the encoding type. So the encoding type is NOT for the "port". Encoding >type >and >other traffic parameters together should be able to specify which type of >LSP to >create. BTW, at the signaling time, you don't need to specify/negotiate >"port" >attribute. If encoding type is a "port" attribute as you stated, it >shouldn't be >in GMPLS signaling. > >Regards, > >Yangguang > > > >Ayan Banerjee wrote: > > > > Manoj, > > > > It is possible that a "port" on a multi-service platform may behave > > dynamically in one of two (or more) different ways depending on the > > internal switching capabilities. For example, a port may be described > > to be PSC capable and TDM capable at the same time. This capability > > of the port is the "switching capability" of a port. The "switching > > capability" and the "encoding" are orthogonal fields. For example, > > it is possible to request for a TDM switching capability with > > specific encoding of SONET (or SDH). For a distant node to be aware > > of how the LSP is to be setup (that is for the transit node to set up > > its internal switching appropriately) and to allow for a particular > > valid encoding on the port for this requested switching capability, it > > is necessary to carry both fields (in the connection setup request). > > > > The MAX LSP bandwidth that is announced per switching capability lets > > a remote (source) node whether there is available bandwidth with respect > > to connection setup. It may be desired to restrict the switching >capability > > of a port based on the connection setup priority. The announcements > > via routing of the LSP bandwidth across each priority for a given > > switching capability serves this purpose. > > > > Thanks, > > Ayan > > > > > > -----Original Message----- > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Sent: Wednesday, August 01, 2001 10:43 AM > > To: jdrake@calient.net; zwlin@lucent.com > > Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > > kireeti@juniper.net > > Subject: RE: Doubt in draft > > draft-ietf-mpls-generalized-signalling-05.txt > > > > Hi John, > > There are "switching Capability" and "encoding" fields inside > > "switching type" field. The switching capability includes the same set >of > > values as LSP encoding type. Even encoding field also indicate LSP >encoding > > type. What is the need for this duplication in Generalized Label Request > > Object? The max. LSP bandwidth for different priority levels (p= 0...7) >is > > also specified and is only valid in case switching cap/LSP encoding type >is > > TDM. If I am establishing just a normal SDH/SONET LSP then why do I need > > different priority levels ? I think it is only valid if I establish > > SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP > > bandwidth at different priority levels should indicate differnet LOVCs >viz. > > VT1.5...VT6 or VC-2...VC-11. > > > > I think all the fields viz. LSP encoding type (in Generalized Label Req > > object), swiching capability (in switching type), Encoding (in switching > > type) indicate more or less the similar type of meaning. > > I think the switching type field (in generalized label request object) > > should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. > > > > Please correct me if I am wrong. > > > > Regards, > > manoj. > > > > >From: John Drake > > >To: Zhi-Wei Lin , manoj juneja > > > > > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, >Kireeti > > >Kompella > > >Subject: RE: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >Date: Wed, 1 Aug 2001 08:54:56 -0700 > > > > > >Zhi, > > > > > >I thought that Vishal had answered this a while ago. A TE Link can now > > >have > > >multiple switching (nee multiplexing) capabilities. Given this, it's > > >necessary in signalling to identify which switching capability the LSP > > >wishes to use. > > > > > >Thanks, > > > > > >John > > > > > >-----Original Message----- > > >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > >Sent: Tuesday, July 31, 2001 10:14 PM > > >To: manoj juneja > > >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > > >Kireeti Kompella > > >Subject: Re: Doubt in draft > > >draft-ietf-mpls-generalized-signalling-05.txt > > > > > > > > >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 > > > > _________________________________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 17:49:20 -0700 From: "manoj juneja" To: abanerjee@calient.net, xuyg@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 01 Aug 2001 17:46:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Ayan, I think the concept of adding both SDH and SONET links in one TE link is not fine. If we restrict the definition of TE link by saying that it must contain the ports/links of same technology or type. We are trying to add more complexity in signalling protocols by expanding the definition of TE link. U need to take care of both SDH and SONET links only at the gateways (SDH and SONET interworking points only). These things can be done easily by restricting the definition of a TE link. Please correct me if I am wrong. Regards, manoj >From: Ayan Banerjee >To: 'Yangguang Xu' >CC: "'ccamp@ops.ietf.org'" , >"'manojkumarjuneja@hotmail.com'" >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt >Date: Wed, 1 Aug 2001 17:03:48 -0700 > >Yangguang, > >The TSpec, as I understand it, carries only bandwidth information >for some label types. As a result, we do need the encoding type >and the switching capability field for a mutli-service platform >to allocate resources and/or validate a particular connection >encoding type. I think we agree until here. > >For example, if a TE link has both SDH and SONET "ports" bundled >within it (a list of interface switching capability descriptors >allow for this), it has to be notified that this request is for a >SONET port. This is not negotiation, it is a request to get a resource >for a port that can carry a particular type of connection. The TE-link >should not at this time give you a resource label for a SDH port when >you request for a SONET port. As a result, this field also needs to be >carried while signaling setup request is made. > >Thanks, >Ayan > > > > >-----Original Message----- >From: Yangguang Xu [mailto:xuyg@lucent.com] >Sent: Wednesday, August 01, 2001 4:15 PM >To: Ayan Banerjee >Cc: 'ccamp@ops.ietf.org'; 'manojkumarjuneja@hotmail.com' >Subject: Re: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >Ayan, > >I think Manoj is right. In GMPLS signaling, encoding type and signal type >in >TSpec together should form one meaningful unit to specify what type of LSP >to >create. In another word, you should parse the traffic parameters according >to >the encoding type. So the encoding type is NOT for the "port". Encoding >type >and >other traffic parameters together should be able to specify which type of >LSP to >create. BTW, at the signaling time, you don't need to specify/negotiate >"port" >attribute. If encoding type is a "port" attribute as you stated, it >shouldn't be >in GMPLS signaling. > >Regards, > >Yangguang > > > >Ayan Banerjee wrote: > > > > Manoj, > > > > It is possible that a "port" on a multi-service platform may behave > > dynamically in one of two (or more) different ways depending on the > > internal switching capabilities. For example, a port may be described > > to be PSC capable and TDM capable at the same time. This capability > > of the port is the "switching capability" of a port. The "switching > > capability" and the "encoding" are orthogonal fields. For example, > > it is possible to request for a TDM switching capability with > > specific encoding of SONET (or SDH). For a distant node to be aware > > of how the LSP is to be setup (that is for the transit node to set up > > its internal switching appropriately) and to allow for a particular > > valid encoding on the port for this requested switching capability, it > > is necessary to carry both fields (in the connection setup request). > > > > The MAX LSP bandwidth that is announced per switching capability lets > > a remote (source) node whether there is available bandwidth with respect > > to connection setup. It may be desired to restrict the switching >capability > > of a port based on the connection setup priority. The announcements > > via routing of the LSP bandwidth across each priority for a given > > switching capability serves this purpose. > > > > Thanks, > > Ayan > > > > > > -----Original Message----- > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Sent: Wednesday, August 01, 2001 10:43 AM > > To: jdrake@calient.net; zwlin@lucent.com > > Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > > kireeti@juniper.net > > Subject: RE: Doubt in draft > > draft-ietf-mpls-generalized-signalling-05.txt > > > > Hi John, > > There are "switching Capability" and "encoding" fields inside > > "switching type" field. The switching capability includes the same set >of > > values as LSP encoding type. Even encoding field also indicate LSP >encoding > > type. What is the need for this duplication in Generalized Label Request > > Object? The max. LSP bandwidth for different priority levels (p= 0...7) >is > > also specified and is only valid in case switching cap/LSP encoding type >is > > TDM. If I am establishing just a normal SDH/SONET LSP then why do I need > > different priority levels ? I think it is only valid if I establish > > SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP > > bandwidth at different priority levels should indicate differnet LOVCs >viz. > > VT1.5...VT6 or VC-2...VC-11. > > > > I think all the fields viz. LSP encoding type (in Generalized Label Req > > object), swiching capability (in switching type), Encoding (in switching > > type) indicate more or less the similar type of meaning. > > I think the switching type field (in generalized label request object) > > should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. > > > > Please correct me if I am wrong. > > > > Regards, > > manoj. > > > > >From: John Drake > > >To: Zhi-Wei Lin , manoj juneja > > > > > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, >Kireeti > > >Kompella > > >Subject: RE: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >Date: Wed, 1 Aug 2001 08:54:56 -0700 > > > > > >Zhi, > > > > > >I thought that Vishal had answered this a while ago. A TE Link can now > > >have > > >multiple switching (nee multiplexing) capabilities. Given this, it's > > >necessary in signalling to identify which switching capability the LSP > > >wishes to use. > > > > > >Thanks, > > > > > >John > > > > > >-----Original Message----- > > >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > >Sent: Tuesday, July 31, 2001 10:14 PM > > >To: manoj juneja > > >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > > >Kireeti Kompella > > >Subject: Re: Doubt in draft > > >draft-ietf-mpls-generalized-signalling-05.txt > > > > > > > > >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 > > > > _________________________________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 17:06:20 -0700 Message-ID: From: Ayan Banerjee To: 'Yangguang Xu' Cc: "'ccamp@ops.ietf.org'" , "'manojkumarjuneja@hotmail.com'" Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 1 Aug 2001 17:03:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yangguang, The TSpec, as I understand it, carries only bandwidth information for some label types. As a result, we do need the encoding type and the switching capability field for a mutli-service platform to allocate resources and/or validate a particular connection encoding type. I think we agree until here. For example, if a TE link has both SDH and SONET "ports" bundled within it (a list of interface switching capability descriptors allow for this), it has to be notified that this request is for a SONET port. This is not negotiation, it is a request to get a resource for a port that can carry a particular type of connection. The TE-link should not at this time give you a resource label for a SDH port when you request for a SONET port. As a result, this field also needs to be carried while signaling setup request is made. Thanks, Ayan -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: Wednesday, August 01, 2001 4:15 PM To: Ayan Banerjee Cc: 'ccamp@ops.ietf.org'; 'manojkumarjuneja@hotmail.com' Subject: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Ayan, I think Manoj is right. In GMPLS signaling, encoding type and signal type in TSpec together should form one meaningful unit to specify what type of LSP to create. In another word, you should parse the traffic parameters according to the encoding type. So the encoding type is NOT for the "port". Encoding type and other traffic parameters together should be able to specify which type of LSP to create. BTW, at the signaling time, you don't need to specify/negotiate "port" attribute. If encoding type is a "port" attribute as you stated, it shouldn't be in GMPLS signaling. Regards, Yangguang Ayan Banerjee wrote: > > Manoj, > > It is possible that a "port" on a multi-service platform may behave > dynamically in one of two (or more) different ways depending on the > internal switching capabilities. For example, a port may be described > to be PSC capable and TDM capable at the same time. This capability > of the port is the "switching capability" of a port. The "switching > capability" and the "encoding" are orthogonal fields. For example, > it is possible to request for a TDM switching capability with > specific encoding of SONET (or SDH). For a distant node to be aware > of how the LSP is to be setup (that is for the transit node to set up > its internal switching appropriately) and to allow for a particular > valid encoding on the port for this requested switching capability, it > is necessary to carry both fields (in the connection setup request). > > The MAX LSP bandwidth that is announced per switching capability lets > a remote (source) node whether there is available bandwidth with respect > to connection setup. It may be desired to restrict the switching capability > of a port based on the connection setup priority. The announcements > via routing of the LSP bandwidth across each priority for a given > switching capability serves this purpose. > > Thanks, > Ayan > > > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, August 01, 2001 10:43 AM > To: jdrake@calient.net; zwlin@lucent.com > Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > kireeti@juniper.net > Subject: RE: Doubt in draft > draft-ietf-mpls-generalized-signalling-05.txt > > Hi John, > There are "switching Capability" and "encoding" fields inside > "switching type" field. The switching capability includes the same set of > values as LSP encoding type. Even encoding field also indicate LSP encoding > type. What is the need for this duplication in Generalized Label Request > Object? The max. LSP bandwidth for different priority levels (p= 0...7) is > also specified and is only valid in case switching cap/LSP encoding type is > TDM. If I am establishing just a normal SDH/SONET LSP then why do I need > different priority levels ? I think it is only valid if I establish > SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP > bandwidth at different priority levels should indicate differnet LOVCs viz. > VT1.5...VT6 or VC-2...VC-11. > > I think all the fields viz. LSP encoding type (in Generalized Label Req > object), swiching capability (in switching type), Encoding (in switching > type) indicate more or less the similar type of meaning. > I think the switching type field (in generalized label request object) > should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. > > Please correct me if I am wrong. > > Regards, > manoj. > > >From: John Drake > >To: Zhi-Wei Lin , manoj juneja > > > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti > >Kompella > >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt > >Date: Wed, 1 Aug 2001 08:54:56 -0700 > > > >Zhi, > > > >I thought that Vishal had answered this a while ago. A TE Link can now > >have > >multiple switching (nee multiplexing) capabilities. Given this, it's > >necessary in signalling to identify which switching capability the LSP > >wishes to use. > > > >Thanks, > > > >John > > > >-----Original Message----- > >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > >Sent: Tuesday, July 31, 2001 10:14 PM > >To: manoj juneja > >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > >Kireeti Kompella > >Subject: Re: Doubt in draft > >draft-ietf-mpls-generalized-signalling-05.txt > > > > > >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 > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 16:26:33 -0700 Message-ID: <3B688FFE.B3FA3F8C@lucent.com> Date: Wed, 01 Aug 2001 19:25:50 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: manoj juneja CC: kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: GMPLS Routing Drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, I think Kireeti is right. Probably the confusion comes from "control channels". It's actually a control network running OSPF or ISIS. The control network topology doesn't need to be the same as the data plane topology. However, you can assume that each pair of network elements have IP reachability through the control network. GMPLS transport network topology is disseminated through opaque LSA (in case of OSPF). At each NE, there are two logical topology databases. One for the control plane network, a vanilla IP network. Another one is for the data plane network, similar to OSPF-TE topology database. Regards, Yangguang manoj juneja wrote: > > Hi Kireeti, > I have read the second last para of the draft. It > states "We call the interfaces over which regular routing adjacencies > are established "control channels". This definition restricts its scope > to routing adjacencies i.e. the control channels over which OSPF > control packets are going to be sent. Does this mean for sending the > GMPLS control messages, the same routing adjacencies are going to be > used ? If yes, then how to distinguish between the control channels > between two OSPF instances and GMPLS instances ? If no, then how this > GMPLS control channel information is transmitted in routing protocols ? > > Regards, > manoj. > > >From: Kireeti Kompella > >To: ccamp@ops.ietf.org > >Subject: Re: GMPLS Routing Drafts > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > > > >Hi Manoj, > > > > > In section 5.1 of Ist draft, it is mentioned > > > that "control channels are advertised into routing as normal links as > > > mentioned in previous section". But in previous section of document I, > > > there is no reference of control channels. > > > >Read the second last para of section 5. > > > > > Furthermore, in OSPF > > > extensions document (IInd draft), there is no mention of control > > > channels at all. > > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft > >deals with the formats of the GMPLS TE extensions. As the abstract says: > > > > This document specifies encoding of extensions to the OSPF routing > > protocol in support of Generalized Multi-Protocol Label Switching > > (GMPLS). The description of the extensions is specified in [GMPLS- > > ROUTING]. > > > >BTW, since you have a penchant for pedantry, let me point out that > >it is inconsistent to call a "missing reference" (or a "no mention") > >an "inconsistency". > > > >On the other hand, we do appreciate your careful reading. > > > >Kireeti. > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 16:16:41 -0700 Message-ID: <3B688D6A.5ECA441@lucent.com> Date: Wed, 01 Aug 2001 19:14:50 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Ayan Banerjee CC: "'ccamp@ops.ietf.org'" , "'manojkumarjuneja@hotmail.com'" Subject: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ayan, I think Manoj is right. In GMPLS signaling, encoding type and signal type in TSpec together should form one meaningful unit to specify what type of LSP to create. In another word, you should parse the traffic parameters according to the encoding type. So the encoding type is NOT for the "port". Encoding type and other traffic parameters together should be able to specify which type of LSP to create. BTW, at the signaling time, you don't need to specify/negotiate "port" attribute. If encoding type is a "port" attribute as you stated, it shouldn't be in GMPLS signaling. Regards, Yangguang Ayan Banerjee wrote: > > Manoj, > > It is possible that a "port" on a multi-service platform may behave > dynamically in one of two (or more) different ways depending on the > internal switching capabilities. For example, a port may be described > to be PSC capable and TDM capable at the same time. This capability > of the port is the "switching capability" of a port. The "switching > capability" and the "encoding" are orthogonal fields. For example, > it is possible to request for a TDM switching capability with > specific encoding of SONET (or SDH). For a distant node to be aware > of how the LSP is to be setup (that is for the transit node to set up > its internal switching appropriately) and to allow for a particular > valid encoding on the port for this requested switching capability, it > is necessary to carry both fields (in the connection setup request). > > The MAX LSP bandwidth that is announced per switching capability lets > a remote (source) node whether there is available bandwidth with respect > to connection setup. It may be desired to restrict the switching capability > of a port based on the connection setup priority. The announcements > via routing of the LSP bandwidth across each priority for a given > switching capability serves this purpose. > > Thanks, > Ayan > > > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, August 01, 2001 10:43 AM > To: jdrake@calient.net; zwlin@lucent.com > Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > kireeti@juniper.net > Subject: RE: Doubt in draft > draft-ietf-mpls-generalized-signalling-05.txt > > Hi John, > There are "switching Capability" and "encoding" fields inside > "switching type" field. The switching capability includes the same set of > values as LSP encoding type. Even encoding field also indicate LSP encoding > type. What is the need for this duplication in Generalized Label Request > Object? The max. LSP bandwidth for different priority levels (p= 0...7) is > also specified and is only valid in case switching cap/LSP encoding type is > TDM. If I am establishing just a normal SDH/SONET LSP then why do I need > different priority levels ? I think it is only valid if I establish > SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP > bandwidth at different priority levels should indicate differnet LOVCs viz. > VT1.5...VT6 or VC-2...VC-11. > > I think all the fields viz. LSP encoding type (in Generalized Label Req > object), swiching capability (in switching type), Encoding (in switching > type) indicate more or less the similar type of meaning. > I think the switching type field (in generalized label request object) > should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. > > Please correct me if I am wrong. > > Regards, > manoj. > > >From: John Drake > >To: Zhi-Wei Lin , manoj juneja > > > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti > >Kompella > >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt > >Date: Wed, 1 Aug 2001 08:54:56 -0700 > > > >Zhi, > > > >I thought that Vishal had answered this a while ago. A TE Link can now > >have > >multiple switching (nee multiplexing) capabilities. Given this, it's > >necessary in signalling to identify which switching capability the LSP > >wishes to use. > > > >Thanks, > > > >John > > > >-----Original Message----- > >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > >Sent: Tuesday, July 31, 2001 10:14 PM > >To: manoj juneja > >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; > >Kireeti Kompella > >Subject: Re: Doubt in draft > >draft-ietf-mpls-generalized-signalling-05.txt > > > > > >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 > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 15:56:36 -0700 Message-ID: <001d01c11ae7$caf3fe00$4e5a2c42@tpidl6z5ynrc41> From: "S Kalipatnapu" To: "manoj juneja" , , Subject: Re: GMPLS Routing Drafts Date: Wed, 1 Aug 2001 20:12:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, I am not sure, if I understand your question completely and Kireeti may give a better answer, but if it helps, it may be noted that sub-IP routing instance uses control channels for advertising sub-IP domain reachability, while the IP routing instance advertises over the data channel forwarding adjacencies created by the GMPLS control plane. Cheers, --Sitaram ----- Original Message ----- From: "manoj juneja" To: ; Sent: Wednesday, August 01, 2001 5:01 PM Subject: Re: GMPLS Routing Drafts > Hi Kireeti, > I have read the second last para of the draft. It > states "We call the interfaces over which regular routing adjacencies > are established "control channels". This definition restricts its scope > to routing adjacencies i.e. the control channels over which OSPF > control packets are going to be sent. Does this mean for sending the > GMPLS control messages, the same routing adjacencies are going to be > used ? If yes, then how to distinguish between the control channels > between two OSPF instances and GMPLS instances ? If no, then how this > GMPLS control channel information is transmitted in routing protocols ? > > Regards, > manoj. > > > > >From: Kireeti Kompella > >To: ccamp@ops.ietf.org > >Subject: Re: GMPLS Routing Drafts > >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > > > >Hi Manoj, > > > > > In section 5.1 of Ist draft, it is mentioned > > > that "control channels are advertised into routing as normal links as > > > mentioned in previous section". But in previous section of document I, > > > there is no reference of control channels. > > > >Read the second last para of section 5. > > > > > Furthermore, in OSPF > > > extensions document (IInd draft), there is no mention of control > > > channels at all. > > > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft > >deals with the formats of the GMPLS TE extensions. As the abstract says: > > > > This document specifies encoding of extensions to the OSPF routing > > protocol in support of Generalized Multi-Protocol Label Switching > > (GMPLS). The description of the extensions is specified in [GMPLS- > > ROUTING]. > > > >BTW, since you have a penchant for pedantry, let me point out that > >it is inconsistent to call a "missing reference" (or a "no mention") > >an "inconsistency". > > > >On the other hand, we do appreciate your careful reading. > > > >Kireeti. > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 15:18:17 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C94D41@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Dawkins, Spencer" , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 15:15:28 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AD7.7879BEE0" 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_01C11AD7.7879BEE0 Content-Type: text/plain; charset="iso-8859-1" Dear Spencer, LMP is a WAN protocol hence losses, round trip times and congestion control are more involved. NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple. Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application. Please see my related comments in other ccamp responses as well. Vasant -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Tuesday, July 31, 2001 2:17 PM To: '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface 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 is an interesting overview, but doesn't BEGIN to reflect the volume level. Thanks for any insights you can provide. Spencer ------_=_NextPart_001_01C11AD7.7879BEE0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Dear Spencer,
LMP is a WAN protocol hence losses, round trip times and congestion control are more involved.
NTIP runs in a controlled environment where the OXC and DWDM are co-located. The traffic engineering is basic and simple.  Also the platforms are not general purpose OS but embedded systems with optimized code. Exponential back off can be disabled for this application.
 
Please see my related comments in other ccamp responses as well.
 
Vasant
 
 
 
-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Tuesday, July 31, 2001 2:17 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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 is an interesting overview, but doesn't BEGIN to reflect the volume level.
 
Thanks for any insights you can provide.
 
Spencer
------_=_NextPart_001_01C11AD7.7879BEE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 15:18:11 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C94D3D@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Andre Fredette Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 15:14:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AD7.57E375E0" 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_01C11AD7.57E375E0 Content-Type: text/plain; charset="iso-8859-1" Andre, >>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Sahay, Vasant ] I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements. My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage". >>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. [Sahay, Vasant ] If we used TCP for LMP it will certainly be broken because LMP is a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled. By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport. The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity. Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for local traffic (WDM-LMP). Does that sound like extra work ? >>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. [Sahay, Vasant] The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter. Vasant ---Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, August 01, 2001 7:59 AM To: Sahay, Vasant [SC9:6909:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11AD7.57E375E0 Content-Type: text/html; charset="iso-8859-1"
Andre,
 
>>>>>> Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Sahay, Vasant ]
I am wondering how we can keep our discussion positive and constructive instead of pointing out assertions or getting into legal analysis of statements.
My statement neither confirms nor denies my colleague's stand on "need for LMP". The statement simply is "Andre if you were to base OLI on LMP you will suffer the baggage".
 
>>>>>>> I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.
[Sahay, Vasant ]
If we used TCP for LMP it will certainly be broken because LMP is  a WAN protocol and has to consider round trip delays, variable losses and congestion. But not so for NTIP. NTIP runs in a controlled local environment where the congestion control sophistications can be disabled.
By the way, we are not married to TCP. In fact while co-authoring the OLI requirements we have only asked for a reliable transport. It can be one of the many available prorocols used for reliable transport.
The fundamental difference (in reliable transmission) between NTIP and LMP is that NTIP is layered to run over a reliable transport protocol, whereas WDM-LMP has an application implementing the reliablity.
 
Also, in this context, on the LMP-baggage front, you will need two flavors of retransmission schemes one for WAN (LMP) traffic, and the other for  local traffic (WDM-LMP). Does that sound like extra work ? 

 
>>>>>>>>>Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.
[Sahay, Vasant]
The complexity of a readymade module is not a consideration. The complexity of WDM-LMP and LMP code to be developed is the question here. The objective is to compare the development and integration risk and not the states within TCP or any existing transport protocol for that matter.

 
Vasant
 ---Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.


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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).


There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".


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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre


Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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_01C11AD7.57E375E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 14:55:43 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C94CFA@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Jonathan Lang , Jonathan Lang , "'Mannie, Eric '" , "Bilel Jamoussi" , "'''Andre Fredette' ' '" , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 14:52:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AD4.3DDA2520" 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_01C11AD4.3DDA2520 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Here are my comments on some excerpts. Best Vasant >[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" ? [Jonathan]alarm-retransmission. ---------- [vasant]The fact that you were recommending "window sizes" approach but now have chosen to go the "alarm-retransmission" route tells me not much thought has gone into it. This level of definition is what makes me nervous about the use of LMP as basis for OLI. >>>>>>>>>[Jonathan]Are you speaking as a WDM vendor here? [vasant]Yes. And on behalf of others too. ---------------------------------------------------------------------------- ------------- -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Wednesday, August 01, 2001 1:16 AM To: Sahay, Vasant [SC9:6909:EXCH]; Jonathan Lang; 'Mannie, Eric '; Jamoussi, Bilel [BL60:1A00-M:EXCH]; '''Andre Fredette' ' '; '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Vasant, Please see inline comments. Thanks, Jonathan >>>>>>>>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. [Jonathan]You're confusing RSVP refresh with RSVP message acks. Of course the rate would be much higher than RSVP refresh rate. >>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? [Jonathan]The message ack procedures of LMP are essentially the same as those defined in RFC2961. >[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" ? [Jonathan]alarm-retransmission. >>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. [Jonathan]Are you speaking as a WDM vendor here? >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:Eric.Mannie@ebone.com ] Sent: Monday, July 30, 2001 3:21 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' '; ''ccamp@ops.ietf.org' ' 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'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com < mailto:fredette@photonex.com > ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net < mailto:kireeti@juniper.net > ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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_01C11AD4.3DDA2520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

Jonathan,
Here are my = comments on some excerpts.

Best
Vasant

>[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" ?
[Jonathan]alarm-retransmission.
----------
[vasant]The fact = that you were recommending "window sizes" approach but now = have chosen to go the "alarm-retransmission" route tells me = not much thought has gone into it. This level of definition is what makes me nervous = about the use of LMP as basis for OLI.


>>>>>>>>>[Jonathan]Are you = speaking as a WDM vendor here?
[vasant]Yes. And on = behalf of others too.

---------------------------------------------------------= --------------------------------
-----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]=
Sent: Wednesday, August 01, 2001 1:16 = AM
To: Sahay, Vasant [SC9:6909:EXCH]; = Jonathan Lang; 'Mannie, Eric ';
Jamoussi, Bilel [BL60:1A00-M:EXCH]; = '''Andre Fredette' ' ';
'''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link = Interface


Vasant,
  Please see inline = comments.

Thanks,
Jonathan


>>>>>>>>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.
[Jonathan]You're confusing RSVP = refresh with RSVP message acks.  Of course
the rate would be much higher than = RSVP refresh rate.


>>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?
[Jonathan]The message ack procedures = of LMP are essentially the same as
those defined in RFC2961.


>[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" ?
[Jonathan]alarm-retransmission.


>>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.
[Jonathan]Are you speaking as a WDM = vendor here?


>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:Eric.Mannie@ebone.com =
<mailto:Eric.Mannie@ebone.com&g= t; ]
Sent: Monday, July 30, 2001 3:21 PM =
To: Jamoussi, Bilel = [BL60:1A00-M:EXCH]; ''Andre Fredette' ';
''ccamp@ops.ietf.org' '
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 =3D = 9.
Kind regards,
Eric
Eric Mannie
EBONE
-----Original Message-----
From: Bilel Jamoussi
To: 'Andre Fredette'; = 'ccamp@ops.ietf.org'
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:fredette@photonex.com =
<mailto:fredette@photonex.com&g= t; 
< mailto:fredette@photonex.com = <mailto:fredette@photonex.com&g= t; > ]
Sent: Thursday, July 26, 2001 2:52 PM =
To: ccamp@ops.ietf.org
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:kireeti@juniper.net =
<mailto:kireeti@juniper.net>&n= bsp;
< mailto:kireeti@juniper.net = <mailto:kireeti@juniper.net> = > ]
>Sent: Wednesday, July 25, 2001 = 9:57 PM
>To: jamoussi@nortelnetworks.com; = kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; = ccamp@ops.ietf.org;
>vasants@nortelnetworks.com =
>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_01C11AD4.3DDA2520-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 14:51:54 -0700 Message-ID: From: Ayan Banerjee To: "'ccamp@ops.ietf.org'" Cc: "'manojkumarjuneja@hotmail.com'" Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 1 Aug 2001 14:50:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, It is possible that a "port" on a multi-service platform may behave dynamically in one of two (or more) different ways depending on the internal switching capabilities. For example, a port may be described to be PSC capable and TDM capable at the same time. This capability of the port is the "switching capability" of a port. The "switching capability" and the "encoding" are orthogonal fields. For example, it is possible to request for a TDM switching capability with specific encoding of SONET (or SDH). For a distant node to be aware of how the LSP is to be setup (that is for the transit node to set up its internal switching appropriately) and to allow for a particular valid encoding on the port for this requested switching capability, it is necessary to carry both fields (in the connection setup request). The MAX LSP bandwidth that is announced per switching capability lets a remote (source) node whether there is available bandwidth with respect to connection setup. It may be desired to restrict the switching capability of a port based on the connection setup priority. The announcements via routing of the LSP bandwidth across each priority for a given switching capability serves this purpose. Thanks, Ayan -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Wednesday, August 01, 2001 10:43 AM To: jdrake@calient.net; zwlin@lucent.com Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; kireeti@juniper.net Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Hi John, There are "switching Capability" and "encoding" fields inside "switching type" field. The switching capability includes the same set of values as LSP encoding type. Even encoding field also indicate LSP encoding type. What is the need for this duplication in Generalized Label Request Object? The max. LSP bandwidth for different priority levels (p= 0...7) is also specified and is only valid in case switching cap/LSP encoding type is TDM. If I am establishing just a normal SDH/SONET LSP then why do I need different priority levels ? I think it is only valid if I establish SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP bandwidth at different priority levels should indicate differnet LOVCs viz. VT1.5...VT6 or VC-2...VC-11. I think all the fields viz. LSP encoding type (in Generalized Label Req object), swiching capability (in switching type), Encoding (in switching type) indicate more or less the similar type of meaning. I think the switching type field (in generalized label request object) should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. Please correct me if I am wrong. Regards, manoj. >From: John Drake >To: Zhi-Wei Lin , manoj juneja > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti >Kompella >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt >Date: Wed, 1 Aug 2001 08:54:56 -0700 > >Zhi, > >I thought that Vishal had answered this a while ago. A TE Link can now >have >multiple switching (nee multiplexing) capabilities. Given this, it's >necessary in signalling to identify which switching capability the LSP >wishes to use. > >Thanks, > >John > >-----Original Message----- >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >Sent: Tuesday, July 31, 2001 10:14 PM >To: manoj juneja >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; >Kireeti Kompella >Subject: Re: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 14:14:23 -0700 Message-ID: <3B687104.12B81278@lucent.com> Date: Wed, 01 Aug 2001 17:13:40 -0400 From: George Newsome Organization: Lucent Technologies, Bell Labs MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org Subject: Re: new gmpls signaling drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lou, Now that I'm back from my vaccation, and am struggling through the many emails, I have got to the new gmpls documents that you announced. draft-ietf-mpls-generalized-signaling-05.txt draft-ietf-mpls-generalized-rsvp-te-04.txt draft-ietf-mpls-generalized-cr-ldp-04.txt As there were a very large number of comments posted, it is almost impossible to determine from the documents how those comments were handled, or even if they were handled. While the comments were comming in Bert Wijnen asked the CCAMP WG chairs to summarize the issues and post the summaries. I haven't seen any such summary (but perhaps I just missed it). I also expected to see a statement from the editors as to how each issue was resolved. Is there any intention to provide such a summary and statement of issue resolution? Without this information I find it very hard to consider the documents ready. Regards George Newsome =========================================================================================== > From: "Wijnen, Bert (Bert)" > To: ccamp-wg > Subject: WG Last Call on GMPLS documents > Date: Tue, 19 Jun 2001 23:28:06 +0200 > MIME-Version: 1.0 > Content-Type: text/plain > > When flooded with the many postings/comments, I sometimes hate > it when people are giving so much comments. But at the other hand, > it also shows that we do get feedback from the community. > > The WG Last Call was a joint call between MPLS and CCAMP WGs. > This was done because the 4 documents were in transit from MPLS > to CCAMP WG. As a result we saw a lot of (too much!) cross posting. > > > - from now on we want discussion on CCAMP mailing list. Pls do not > > copy MPLS and IPO mailing lists... if you want to participate, pls > > join CCAMP mailing list. > > - BUT... before you send more comments... pls hold off for a bit. > > There are some 1000 or so postings to the WG Last Call. > > I have asked the CCAMP WG chairs to try and make a summary of > > the issues. Once they have done that, they will post them and try to > > find out how many people agree/disagree with each issue. > > I.e. they will try to find out if there is WG consensus on what the > > issues are. > > - I believe there were some suggested "fixes" to address some issues > > as well. The WG chairs will also try to summarize these and again > > then try to find out how much WG support there is for these "fixes". > > - Then we will take it from there. > > > Thanks, > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 14:12:34 -0700 Message-ID: From: Yanhe Fan To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: Drafts update Date: Wed, 1 Aug 2001 17:11:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 - Yes 4. draft-many-ccamp-gmpls-framework-00.txt - Wait 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - Wait 6. draft-many-ccamp-gmpls-routing-00.txt - Yes Yanhe Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 14:02:42 -0700 From: "manoj juneja" To: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: GMPLS Routing Drafts Date: Wed, 01 Aug 2001 14:01:18 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Kireeti, I have read the second last para of the draft. It states "We call the interfaces over which regular routing adjacencies are established "control channels". This definition restricts its scope to routing adjacencies i.e. the control channels over which OSPF control packets are going to be sent. Does this mean for sending the GMPLS control messages, the same routing adjacencies are going to be used ? If yes, then how to distinguish between the control channels between two OSPF instances and GMPLS instances ? If no, then how this GMPLS control channel information is transmitted in routing protocols ? Regards, manoj. >From: Kireeti Kompella >To: ccamp@ops.ietf.org >Subject: Re: GMPLS Routing Drafts >Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) > >Hi Manoj, > > > In section 5.1 of Ist draft, it is mentioned > > that "control channels are advertised into routing as normal links as > > mentioned in previous section". But in previous section of document I, > > there is no reference of control channels. > >Read the second last para of section 5. > > > Furthermore, in OSPF > > extensions document (IInd draft), there is no mention of control > > channels at all. > >Control channels are part of "regular" OSPF; the GMPLS OSPF draft >deals with the formats of the GMPLS TE extensions. As the abstract says: > > This document specifies encoding of extensions to the OSPF routing > protocol in support of Generalized Multi-Protocol Label Switching > (GMPLS). The description of the extensions is specified in [GMPLS- > ROUTING]. > >BTW, since you have a penchant for pedantry, let me point out that >it is inconsistent to call a "missing reference" (or a "no mention") >an "inconsistency". > >On the other hand, we do appreciate your careful reading. > >Kireeti. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 13:48:53 -0700 Message-Id: <4.3.2.7.2.20010801165211.01e28860@bucket.cisco.com> Date: Wed, 01 Aug 2001 16:52:29 -0400 To: "'ccamp@ops.ietf.org'" From: "Thomas D. Nadeau" Subject: RE: Drafts Update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 - YES 6. draft-many-ccamp-gmpls-routing-00.txt - YES Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 13:41:17 -0700 Message-ID: From: Jonathan Lang To: "'ccamp@ops.ietf.org'" , "'kireeti@juniper.net'" Subject: RE: Drafts Update Date: Wed, 1 Aug 2001 13:36:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" My thoughts on the drafts: 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 - not sure 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - YES 6. draft-many-ccamp-gmpls-routing-00.txt - YES Thanks, Jonathan Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 13:26:54 -0700 Date: Wed, 1 Aug 2001 16:25:48 -0400 (EDT) From: Yong Xue To: yxue@UU.NET cc: "'ccamp@ops.ietf.org '" , "'kireeti@juniper.net '" Subject: Re: AW: Drafts Update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > My opinion: > > 1. draft-dubuc-lmp-mib-02.txt - not sure. > 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 - not sure. > 6. draft-many-ccamp-gmpls-routing-00.txt - YES > /Yong Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 12:28:26 -0700 Date: Wed, 1 Aug 2001 12:26:44 -0700 (PDT) From: Kireeti Kompella Message-Id: <200108011926.MAA05945@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Re: GMPLS Routing Drafts Hi Manoj, > In section 5.1 of Ist draft, it is mentioned > that "control channels are advertised into routing as normal links as > mentioned in previous section". But in previous section of document I, > there is no reference of control channels. Read the second last para of section 5. > Furthermore, in OSPF > extensions document (IInd draft), there is no mention of control > channels at all. Control channels are part of "regular" OSPF; the GMPLS OSPF draft deals with the formats of the GMPLS TE extensions. As the abstract says: This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. BTW, since you have a penchant for pedantry, let me point out that it is inconsistent to call a "missing reference" (or a "no mention") an "inconsistency". On the other hand, we do appreciate your careful reading. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 12:20:17 -0700 Message-ID: <3B68561B.526E37E6@nayna.com> Date: Wed, 01 Aug 2001 12:18:51 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: "'ccamp@ops.ietf.org '" , "'kireeti@juniper.net '" Subject: Re: AW: Drafts update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kireeti: My opinions. > > 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 - Wait till London meeting > is done. > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - No > Opinion. > 6. draft-many-ccamp-gmpls-routing-00.txt - YES. > Cheers, sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 12:18:38 -0700 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" Cc: Subject: RE: Drafts update Date: Wed, 1 Aug 2001 12:17:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kireeti, My votes: 1. draft-dubuc-lmp-mib-02.txt 2. draft-fontana-ccamp-gmpls-g709-00.txt 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 6. draft-many-ccamp-gmpls-routing-00.txt [Yes] Thanks, -Vishal _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 12:10:01 -0700 Message-ID: From: "Mannie, Eric" To: "'ccamp@ops.ietf.org '" , "'kireeti@juniper.net '" Subject: AW: Drafts update Date: Wed, 1 Aug 2001 21:08:26 +0200 MIME-Version: 1.0 Content-Type: text/plain Hello 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 - wait and see. 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - YES. 6. draft-many-ccamp-gmpls-routing-00.txt - YES. Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 11:17:54 -0700 From: "manoj juneja" To: kireeti@kummer.juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: GMPLS Routing Drafts Date: Wed, 01 Aug 2001 11:15:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Kireeti, There is some inconsistency in draft-many-ccamp-gmpls -routing-00.txt (Ist draft) and draft-kompella-ospf-gmpls-extensions -02.txt (IInd draft).In section 5.1 of Ist draft, it is mentioned that "control channels are advertised into routing as normal links as mentioned in previous section". But in previous section of document I, there is no reference of control channels. Furthermore, in OSPF extensions document (IInd draft), there is no mention of control channels at all. Regards, manoj. >From: Kireeti Kompella >To: ccamp@ops.ietf.org >Subject: GMPLS Routing Drafts >Date: Wed, 1 Aug 2001 10:55:07 -0700 (PDT) > >Hi, > >To clarify: the GMPLS routing drafts have been separated into >a common document (draft-many-ccamp-gmpls-routing-00.txt) and >protocol specific documents (draft-ietf-isis-gmpls-extensions-03.txt >and draft-kompella-ospf-gmpls-extensions-02.txt). This follows >the pattern we took for the signalling drafts -- thanks, Rob, >for suggesting this. > >The common spec will be in CCAMP. > >I talked to John Moy, and he thought that CCAMP was a good >place for the OSPF GMPLS spec. > >Tony and Tony, on the other hand, prefer to keep the ISIS >GMPLS spec in the ISIS WG. > >Note that the OSPF TE LSAs are well separated from "regular" >LSAs, so a hands-off approach works well. In IS-IS, the >separation is not as complete, and the issues of limited TLV >space as well as fragment space mean that it would be useful >to have the gods of ISIS watch over the spec. > >Kireeti. > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 11:15:57 -0700 Message-ID: <3B6846F8.1B7DB7E6@lucent.com> Date: Wed, 01 Aug 2001 14:14:16 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: GMPLS Routing Drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, > The common spec will be in CCAMP. > For different technologies SONET/SDH, OTN, pure optical etc., there will be different extensions to routing. Are we going a spec. with appendixes or separate documents? Thanks, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 11:08:59 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: SE-Style of Reservation in GMPLS Date: Wed, 01 Aug 2001 11:07:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Does GMPLS support Shared Explicit style of reservation in true sense (except using this SE style of reservation for restoration/re\ -routing) ? In RSVP-TE, when using SE style of reservation u can assign different labels to different senders. But in SDH/SONET case, u can't allocate different labels to different senders as Labels represent the actual bandwidth only. Please clarify. Regards, manoj _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 10:57:02 -0700 Date: Wed, 1 Aug 2001 10:55:07 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: GMPLS Routing Drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, To clarify: the GMPLS routing drafts have been separated into a common document (draft-many-ccamp-gmpls-routing-00.txt) and protocol specific documents (draft-ietf-isis-gmpls-extensions-03.txt and draft-kompella-ospf-gmpls-extensions-02.txt). This follows the pattern we took for the signalling drafts -- thanks, Rob, for suggesting this. The common spec will be in CCAMP. I talked to John Moy, and he thought that CCAMP was a good place for the OSPF GMPLS spec. Tony and Tony, on the other hand, prefer to keep the ISIS GMPLS spec in the ISIS WG. Note that the OSPF TE LSAs are well separated from "regular" LSAs, so a hands-off approach works well. In IS-IS, the separation is not as complete, and the issues of limited TLV space as well as fragment space mean that it would be useful to have the gods of ISIS watch over the spec. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 10:45:33 -0700 From: "manoj juneja" To: jdrake@calient.net, zwlin@lucent.com Cc: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, kireeti@juniper.net Bcc: Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 01 Aug 2001 10:42:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi John, There are "switching Capability" and "encoding" fields inside "switching type" field. The switching capability includes the same set of values as LSP encoding type. Even encoding field also indicate LSP encoding type. What is the need for this duplication in Generalized Label Request Object? The max. LSP bandwidth for different priority levels (p= 0...7) is also specified and is only valid in case switching cap/LSP encoding type is TDM. If I am establishing just a normal SDH/SONET LSP then why do I need different priority levels ? I think it is only valid if I establish SDH/SONET LSP as a forwarding adjacency (FA). Furthermore, the max. LSP bandwidth at different priority levels should indicate differnet LOVCs viz. VT1.5...VT6 or VC-2...VC-11. I think all the fields viz. LSP encoding type (in Generalized Label Req object), swiching capability (in switching type), Encoding (in switching type) indicate more or less the similar type of meaning. I think the switching type field (in generalized label request object) should be kept optional for LSP encoding type as PSC-[1-4], FSC and LSC. Please correct me if I am wrong. Regards, manoj. >From: John Drake >To: Zhi-Wei Lin , manoj juneja > >CC: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti >Kompella >Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt >Date: Wed, 1 Aug 2001 08:54:56 -0700 > >Zhi, > >I thought that Vishal had answered this a while ago. A TE Link can now >have >multiple switching (nee multiplexing) capabilities. Given this, it's >necessary in signalling to identify which switching capability the LSP >wishes to use. > >Thanks, > >John > >-----Original Message----- >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >Sent: Tuesday, July 31, 2001 10:14 PM >To: manoj juneja >Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; >Kireeti Kompella >Subject: Re: Doubt in draft >draft-ietf-mpls-generalized-signalling-05.txt > > >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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 09:12:58 -0700 Message-ID: <3B6829FD.710EC6B7@hotair.hobl.lucent.com> Date: Wed, 01 Aug 2001 12:10:37 -0400 From: Siva Sankaranarayanan Reply-To: ssnarayanan@lucent.com Organization: JJ0C21010 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Drafts update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, More votes... 1. draft-dubuc-lmp-mib-02.txt - Don't know. 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 - Yes. 6. draft-many-ccamp-gmpls-routing-00.txt - Yes. Regards, Siva Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 08:56:13 -0700 Message-ID: From: John Drake To: Zhi-Wei Lin , manoj juneja Cc: ccamp@ops.ietf.org, lberger@movaz.com, Eric.Mannie@ebone.com, Kireeti Kompella Subject: RE: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Wed, 1 Aug 2001 08:54:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Zhi, I thought that Vishal had answered this a while ago. A TE Link can now have multiple switching (nee multiplexing) capabilities. Given this, it's necessary in signalling to identify which switching capability the LSP wishes to use. Thanks, John -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, July 31, 2001 10:14 PM To: manoj juneja Cc: ccamp@ops.ietf.org; lberger@movaz.com; Eric.Mannie@ebone.com; Kireeti Kompella Subject: Re: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 08:39:35 -0700 From: Andre Fredette To: Bilel Jamoussi Cc: Vasant Sahay , "'ccamp@ops.ietf.org'" Message-Id: <5.1.0.14.2.20010801113015.030d8080@mailbox> Date: Wed, 01 Aug 2001 11:35:50 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6130284==_.ALT" --=====================_6130284==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bilel, I'm only stating what I heard personally and believe to be true. However, If I misunderstood you, I stand corrected. Do you believe LMP is needed and should be specified by CCAMP? Andre At 11:20 AM 8/1/2001 -0400, Bilel Jamoussi wrote: Andre, Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Jamoussi, Bilel ] when did we say that? I spoke of priorities -- please be don't make untrue statements on other's behalf. Bilel --=====================_6130284==_.ALT Content-Type: text/html; charset="us-ascii" Bilel,

I'm only stating what I heard personally and believe to be true.

However, If I misunderstood you, I stand corrected.

Do you believe LMP is needed and should be specified by CCAMP?

Andre

At 11:20 AM 8/1/2001 -0400, Bilel Jamoussi wrote:
Andre,
Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.
[Jamoussi, Bilel ]  when did we say that? I spoke of priorities -- please be don't make untrue statements on other's behalf.
Bilel
 
--=====================_6130284==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 08:22:30 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Andre Fredette'" , "Vasant Sahay" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 11:20:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A9D.8BC47420" 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_01C11A9D.8BC47420 Content-Type: text/plain; charset="iso-8859-1" Andre, Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. [Jamoussi, Bilel ] when did we say that? I spoke of priorities -- please be don't make untrue statements on other's behalf. Bilel ------_=_NextPart_001_01C11A9D.8BC47420 Content-Type: text/html; charset="iso-8859-1"
Andre,
Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. 
[Jamoussi, Bilel ]   when did we say that? I spoke of priorities -- please be don't make untrue statements on other's behalf.
Bilel 
 
------_=_NextPart_001_01C11A9D.8BC47420-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 08:01:03 -0700 From: Andre Fredette To: Vasant Sahay Cc: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010801101435.030d7f40@mailbox> Date: Wed, 01 Aug 2001 10:58:46 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3906727==_.ALT" --=====================_3906727==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Vasant, You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part. Please see my comments below. At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote: 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. Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all. However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion. Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed. This is done all the time in the IETF. Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling. The mechanisms for this feature may still be useful, but can also be easily ignored. 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. I believe (with a lot of other people) that the use of TCP for this protocol is broken. Please refer to the numerous previous posts regarding this issue. 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. Fault isolation is not an integral part of the LMP protocol. The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions. We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification). There are more examples of extra work due to LMP but we can discuss them one at a time. The above concerns are the only ones you have ever mentioned. Given my explanations above, I still don't believe you have Identified any examples of "extra work". 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. After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me. Andre Cheers Vasant From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com ] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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. --=====================_3906727==_.ALT Content-Type: text/html; charset="us-ascii" Vasant,

You identify what you think is extra work, but I believe your concerns derive from misunderstandings on your part.  Please see my comments below.

At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
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.

Funny you should say this given that the colleagues you reference in your note claim that LMP is not needed at all.  However, your assertion that there is still a lot of functionality that needs to be added to LMP is just that, an assertion.  Furthermore, if this is truly the case, it would be easy to separate the base LMP functionality (i.e., 99% of what's currently in LMP), and create a separate document for the additional LMP functionality you believe is needed.  This is done all the time in the IETF.

Also, as I've said recently, I believe the only additional feature in LMP which is not required by the OLI requirements is link bundling.  The mechanisms for this feature may still be useful, but can also be easily ignored. 

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.

I believe (with a lot of other people) that the use of TCP for this protocol is broken.  Please refer to the numerous previous posts regarding this issue.

 
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.

Fault isolation is not an integral part of the LMP protocol.  The LMP spec describes how switching devices (e.g., OXCs) can use the fault notification information from LMP to localize faults and make the appropriate switching decisions.  We clearly spelled out in LMP-WDM that the OLS does not participate in fault localization (only fault detection and notification).

 
There are more examples of extra work due to LMP but we can discuss them one at a time.

The above concerns are the only ones you have ever mentioned.  Given my explanations above, I still don't believe you have Identified any examples of "extra work".

 
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.

After you have fully specified NTIP, I'm sure that the only difference will be attributable to the treatment of application-level acks (which the majority on this discussion list feel are required for a correct protocol). 

Furthermore if you want to compare true protocol complexity, add the TCP states and events to your NTIP count, handle fail-over of TCP sessions, and then come talk to me.

Andre

 
Cheers
Vasant

From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; ccamp@ops.ietf.org
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:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 8:14 AM
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
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:fredette@photonex.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ccamp@ops.ietf.org
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:kireeti@juniper.net]
>Sent: Wednesday, July 25, 2001 9:57 PM
>To: jamoussi@nortelnetworks.com; kireeti@juniper.net;
>osama@nortelnetworks.com
>Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
>vasants@nortelnetworks.com
>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.
--=====================_3906727==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 07:47:30 -0700 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: AW: Drafts update Date: Wed, 1 Aug 2001 16:43:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable draft-fontana-ccamp-gmpls-g709-00.txt needs an update before making it = a WG document. I am i ndiscussion with the authors. Juergen > -----Urspr=FCngliche Nachricht----- > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > Gesendet: Freitag, 27. Juli 2001 22:37 > An: ccamp@ops.ietf.org > Betreff: Drafts update >=20 >=20 > Hi Folks, >=20 > 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 >=20 > 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 >=20 > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) >=20 > Thanks, > Kireeti. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 01:38:38 -0700 Message-ID: From: Jonathan Lang To: 'Vasant Sahay' , Bilel Jamoussi , IMCEAMAILTO-fredette+40photonex+2Ecom@nt.com Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 01:33:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vasant, Please see inline comments. Thanks, Jonathan >-----Original Message----- >From: Vasant Sahay [mailto:vasants@nortelnetworks.com] >Sent: Tuesday, July 31, 2001 8:18 PM >To: Bilel Jamoussi; IMCEAMAILTO-fredette+40photonex+2Ecom@nt.com >Cc: ccamp@ops.ietf.org >Subject: RE: Optical Link Interface > > >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. I think you're still confused. Please look over our previous email exchange. >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. Please reread the lmp draft before misrepresenting it. The fault localization procedure consists of a fault notification message and message ack. >There are more examples of extra work due to LMP but we can discuss them one at a time. I suggest you mention them; the TCP vs. LMP reliability isn't flying (e.g., see Spencer's email) this was also discussed in Minneapolis. >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:fredette@photonex.com] Sent: Monday, July 30, 2001 1:51 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: John Drake; ccamp@ops.ietf.org 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:jamoussi@nortelnetworks.com] Sent: Monday, July 30, 2001 8:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 01:21:16 -0700 Message-ID: From: Jonathan Lang To: 'Vasant Sahay' , Jonathan Lang , "'Mannie, Eric '" , Bilel Jamoussi , '''Andre Fredette' ' ' , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Wed, 1 Aug 2001 01:16:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vasant, Please see inline comments. Thanks, Jonathan >>>>>>>>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. [Jonathan]You're confusing RSVP refresh with RSVP message acks. Of course the rate would be much higher than RSVP refresh rate. >>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? [Jonathan]The message ack procedures of LMP are essentially the same as those defined in RFC2961. >[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" ? [Jonathan]alarm-retransmission. >>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. [Jonathan]Are you speaking as a WDM vendor here? >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:Eric.Mannie@ebone.com ] Sent: Monday, July 30, 2001 3:21 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' '; ''ccamp@ops.ietf.org' ' 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'; 'ccamp@ops.ietf.org' 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:fredette@photonex.com < mailto:fredette@photonex.com > ] Sent: Thursday, July 26, 2001 2:52 PM To: ccamp@ops.ietf.org 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:kireeti@juniper.net < mailto:kireeti@juniper.net > ] >Sent: Wednesday, July 25, 2001 9:57 PM >To: jamoussi@nortelnetworks.com; kireeti@juniper.net; >osama@nortelnetworks.com >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org; >vasants@nortelnetworks.com >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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 Aug 2001 01:16:42 -0700 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , Heiles Juergen , "'Maarten Vissers'" , ccamp Cc: "t1x1.5" , q11/15 Subject: AW: [T1X1.5] arbitrary contiguous concatenation question Date: Wed, 1 Aug 2001 10:15:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eric, as arbitrary contiguous concatenation is not defined by ITU or T1X1 and = only mentioned in this document it should be clarified here. If you look on a STS-3c-SPE contiguous concatenated signal you notice = that it is not really contiguous when it is combined with other STS-SPE = signals in higher bandwidth STS-N signal. This is due to the two stage = multiplex process defined for SONET (historical reasons). In a first = step a STS-3 is gnerated by byte interleaving 3 STS-1. In a second step = a STS-3x is generated by byte interleaving x STS-3. Some examples: A STS-3c-SPE in a STS-3: The STS-3 has the STS-1 time slots 1,2 and 3. The STS-3c-SPE uses the time slots 1,2 and 3. -> contiguous A STS-3c-SPE in a STS-12: The STS-12 has the STS-1 time slots 1 to 12. The STS-3c-SPE can use the time slots=20 1, 5 and 9 2, 6 and 10 3, 7 and 11 4, 8 and 12=20 -> not contiguous A STS-12c-SPE in a STS-12: The STS-12 has the STS-1 time slots 1 to 12. The STS-12c-SPE uses the time slots 1 to 12. -> contiguous A STS-12c-SPE in a STS-192: The STS-192 has the STS-1 time slots 1 to 192 The STS-12c-SPE can use the time slots 1,2,3,4, 65,66,67,68, 129,130,131,132 5,6,7,8, 69,70,71,72, 133,134,135,136 .... 61,62,53,64, 125,126,127,128, 189,190,191,192 -> not contiguous >From a STS-1 time slot view the STS-Nc-SPE doesn't use contiguous time = slots. Only fro ma STS-3 time slot view a STS-Nc-SPE uses contiguous time = slots. A STS-12c-SPE in a STS-192: The STS-192 has the STS-3 time slots 1 to 64 The STS-12c-SPE can use the time slots 1,2,3,4, 5,6,7,8, .... 61,62,53,64, -> contiguous =20 For arbitrary contiguous concatenation which can have any number of = concetenated STS-1 and any starting time slot we have to define which = time sltos are used, contiguous STS-1 or STS-3time slots? Should = arbitrary contiguous cocnatenation of STS-1s use contiguous STS-1 time = slots and arbitrary concatenation of STS-3c contiguous STS-3 timeslots = in order to aline with arbitrary concatenatin of VC-4? This has to be = defeind in order to achieve interworking as currently only hte number = of concateanted signals and the starting time slot is defined for = arbitrary contiguous concatenation. Another solution as Maarten = mentioned is to list each individual time slot as for virtual = concatenation. This shows me again that it is very difficult to define support for = proprietary features without having detailed information about them. = You assume that you understand the feature, but as soon as you go into = the details later on you detect problems. Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Mittwoch, 25. Juli 2001 14:56 > An: 'Heiles Juergen'; 'Maarten Vissers'; ccamp > Cc: t1x1.5; q11/15 > Betreff: ARE: [T1X1.5] arbitrary contiguous concatenation question >=20 >=20 > Hello Juergen and Maarten, >=20 > I don't understand the relationship between > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that=20 > you are talking > about. >=20 > In addition, the IETF is not specifying any SDH/SONET=20 > interoperability (Not > at all in the GMPLS scope). >=20 > Also, I am not sure to understand why the abstract (B, A)=20 > notation of G.707 > (used to have a clearer specification, and not used=20 > (transported) in any > protocol as far as I know) could imply that contiguous=20 > time-slots are not > contiguous anymore ? >=20 > The "Arbitrary" concatenation that you are speaking about is=20 > a contiguous > concatenation, time-slots are physically contiguous. I don't=20 > 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=20 > physically > contiguous even if you see an issue with the SDH G.707 (B, A) = notation > applied to SONET. >=20 > Also, "flexible arbitrary concatenation" (whatever it is -=20 > everybody seems > to have a different understanding) is not part of > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt. >=20 > I guess also that this discussion is relevant for the ITU-T=20 > and/or T1X1, not > for the ccamp mailing list (of the IETF). >=20 > Kind regards, >=20 > Eric >=20 > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > 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 >=20 >=20 > Maarten, >=20 > good point. Lets hear what the supporters of arbitrary=20 > concatenation have to > say. >=20 > Juergen >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Maarten Vissers [mailto:mvissers@lucent.com] > > 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 >=20