Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 22:14:30 -0700 Message-ID: <3B679007.39683933@lucent.com> Date: Wed, 01 Aug 2001 01:13:43 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Tue, 31 Jul 2001 20:26:41 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C4DE3B@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Bilel Jamoussi" , fredette@photonex.com Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface: re send Date: Tue, 31 Jul 2001 20:23:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A39.63805F60" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11A39.63805F60 Content-Type: text/plain; charset="iso-8859-1" Andre, Bilel, Osama and I have discussed the LMP related extra-work with you in our teleconference a few months ago. The scope of LMP is much wider than just OLI. Before LMP gets accepted as a standard, there is a lot of functionality and requirements in LMP that have to be agreed upon. Dependence on LMP will only complicate and delay OLI. Besides, reliable transport of failure-messages is broken in LMP. The current LMP and WDM-LMP drafts imply that the application will have to build a mechanism for tracking and retransmitting lost messages. This translates into additional baggage for OLI. As an example LMP has ability to isolate faults. It is not needed for OLI. You can argue that you will reuse the same messages in OLI to report faults, but it is not the same thing. When LMP gets fully defined with states and procedures then we will find that the procedure for handling a failure message between two OXCs (LMP), is very different than that for between OXC and DWDM (OLI). As an aside my take is that failure-isolation does not even belong fully in LMP. It is a function that belongs between connection-management and link management. There are more examples of extra work due to LMP but we can discuss them one at a time. I did a quick back of the envelope and came up with a total of 24 states and 46 events in LMP. That is a lot of states for a simple protocol. This does not even include the application states for (potential) retransmission of messages. Cheers Vasant From: Andre Fredette [mailto: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_01C11A39.63805F60 Content-Type: text/html; charset="iso-8859-1"

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

From: Andre Fredette [mailto: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_01C11A39.63805F60-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 20:20:04 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C4DE37@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Bilel Jamoussi" , IMCEAMAILTO-fredette+40photonex+2Ecom@nt.com Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Tue, 31 Jul 2001 20:17:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A38.890CE920" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11A38.890CE920 Content-Type: text/plain; charset="iso-8859-1" Andre, Bilel, Osama and I have discussed the LMP related extra-work with you in our teleconference a few months ago. The scope of LMP is much wider than just OLI. Before LMP gets accepted as a standard, there is a lot of functionality and requirements in LMP that have to be agreed upon. Dependence on LMP will only complicate and delay OLI. Besides, reliable transport of failure-messages is broken in LMP. The current LMP and WDM-LMP drafts imply that the application will have to build a mechanism for tracking and retransmitting lost messages. This translates into additional baggage for OLI. As an example LMP has ability to isolate faults. It is not needed for OLI. You can argue that you will reuse the same messages in OLI to report faults, but it is not the same thing. When LMP gets fully defined with states and procedures then we will find that the procedure for handling a failure message between two OXCs (LMP), is very different than that for between OXC and DWDM (OLI). As an aside my take is that failure-isolation does not even belong fully in LMP. It is a function that belongs between connection-management and link management. There are more examples of extra work due to LMP but we can discuss them one at a time. I did a quick back of the envelope and came up with a total of 24 states and 46 events in LMP. That is a lot of states for a simple protocol. This does not even include the application states for (potential) retransmission of messages. Cheers Vasant From: Andre Fredette [mailto: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_01C11A38.890CE920 Content-Type: text/html; charset="iso-8859-1"
Andre,
Bilel, Osama and I have discussed the LMP related extra-work with you in our teleconference a few months ago.
 
The scope of LMP is much wider than just OLI. Before LMP gets accepted as a standard, there is a lot of functionality and requirements in LMP that have to be agreed upon. Dependence on LMP will only complicate and delay OLI. Besides, reliable transport of failure-messages is broken in LMP. The current LMP and WDM-LMP drafts imply that the application will have to build a mechanism for tracking and retransmitting lost messages. This translates into additional baggage for OLI.
 
As an example LMP has ability to isolate faults. It is not needed for OLI. You can argue that you will reuse the same messages in OLI to report faults, but it is not the same thing. When LMP gets fully defined with states and procedures then we will find that the procedure for handling a failure message between two OXCs (LMP), is very different than that for between OXC and DWDM (OLI). As an aside my take is that failure-isolation does not even belong fully in LMP. It is a function that belongs between connection-management and link management.
 
There are more examples of extra work due to LMP but we can discuss them one at a time.
 
I did a quick back of the envelope and came up with a total of 24 states and 46 events in LMP. That is a lot of states for a simple protocol. This does not even include the application states for (potential) retransmission of messages.
 
Cheers
Vasant

From: Andre Fredette [mailto: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_01C11A38.890CE920-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 14:18:10 -0700 Message-ID: From: "Dawkins, Spencer" To: "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Tue, 31 Jul 2001 16:17:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A06.2405A440" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11A06.2405A440 Content-Type: text/plain; charset="iso-8859-1" Dear Vasant, OK, I'll bite. My copy of TCP/IP Illustrated, volume 1, shows TCP doing exponential backoff (page 299), at a pretty leisurely pace, for about nine minutes before giving up. This is, of course, measured using a general-purpose OS, but at some point - well, how long were you planning to wait for TCP retransmissions? I am somewhat confused as to how this lines up with successfully retransmitting lost "events" in 10s of ms. I am somewhat confused as to how using TCP (with exponential retransmission timers) is a substitute for application-level timers. If you have to run application-level timers anyway... well, I thought that was where SCTP came from! If you guys were flogging SCTP, I would still be confused, but at least I would think that you weren't ignoring decades of wailing about using TCP for real-time signaling. http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html#TopOfPage is an interesting overview, but doesn't BEGIN to reflect the volume level. Thanks for any insights you can provide. Spencer ------_=_NextPart_001_01C11A06.2405A440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface
Dear Vasant,
 
OK, I'll bite.
 
=
My copy of TCP/IP Illustrated, = volume 1,=20 shows TCP doing exponential backoff (page 299), at a pretty leisurely = pace, for=20 about nine minutes before giving up. This is, of course, measured using = a=20 general-purpose OS, but at some point - well, how long were you = planning to wait=20 for TCP retransmissions?
 
I=20 am somewhat confused as to how this lines up with successfully = retransmitting=20 lost "events" in 10s of ms.
 
I=20 am somewhat confused as to how using TCP (with exponential = retransmission=20 timers) is a substitute for application-level timers. If you have to = run=20 application-level timers anyway... well, I thought that was where SCTP = came=20 from!
 
If=20 you guys were flogging SCTP, I would still be confused, but at = least I=20 would think that you weren't ignoring decades of wailing about = using TCP=20 for real-time signaling. http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html= #TopOfPage is=20 an interesting overview, but doesn't BEGIN to reflect the volume=20 level.
 
Thanks for any insights you can=20 provide.
 
Spencer
------_=_NextPart_001_01C11A06.2405A440-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 13:34:44 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006C4D96E@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: Jonathan Lang , "'Mannie, Eric '" , "Bilel Jamoussi" , "'''Andre Fredette' ' '" , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Tue, 31 Jul 2001 13:31:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119FF.D90605D0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C119FF.D90605D0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, My comments are in the text. Regards Vasant -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Tuesday, July 31, 2001 11:55 AM To: Sahay, Vasant [SC9:6909:EXCH]; 'Mannie, Eric '; Jamoussi, Bilel [BL60:1A00-M:EXCH]; '''Andre Fredette' ' '; '''ccamp@ops.ietf.org' ' ' Subject: RE: Optical Link Interface Vasant, Please see inline. Thanks, Jonathan -----Original Message----- From: Vasant Sahay To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' '; ''ccamp@ops.ietf.org' ' Sent: 7/30/2001 4:34 PM Subject: RE: Optical Link Interface >>>>>>>>From my point of view, I don't see any reason to replace a protocol by >>>>>>>>another one if they have the same functionalities. >The misconception here is that they have the same functionalities and >that LMP definition is complete. I believe there is a lot of discussion >and thought that needs to go into LMP if used as basis for OLI. WDM-LMP >being based on LMP will also suffer that thrash. [Jonathan]...and NTIP is complete and will not suffer any thrashing? [vasant]---- NTIP has a much smaller scope than LMP. It focuses on OXC-WDM only. Hence the thrash (if at all) will be much less. >Let us start with reliable transport(or lack thereof). >How are failures conveyed reliably from WDM to OXC ? > >LMP defines ACK messages, however I couldnt find any reference to how >they should be used to recover lost messages. [Jonathan]Failures notification is idempotent. LMP is optimized to react to alarms rapidly and doesn't require stop-and-wait procedures. Alarms are treated as independent events. Eash alarm is transmitted until acknowledged (see Section 6). If an alarm status changes, prior to receiving the Ack, the new status is simply transmitted. For a procedural reference, LMP works very much like that of RSVP-TE message Ids in RFC2961. [vasant]-----that is a lot of traffic.Could cause bottlenecks. Also unlike the usual "telecom alarms" these events (I prefer that name) need to be successfully received in "real time"(failure reporting ---say 10 millisecond). Which means the periodic transmission rate will be 10s of milliseconds--until acknowledged. That will create a lot of traffic for sure.The situation is not the same as RSVP refresh here. The refresh rate will need to be much higher than RSVP. >WDM-LMP draft specifies that an ACK should be sent for each >channelStatus message. This level of definition is far from complete. > >So the question is if a few hundred failures were reported, what is the >nature of this ACK scheme for recovering lost messages ? Are we going to >recommend a stop and wait protocol or a sliding window protocol ? (A >stop and wait scheme is easy to implement but slow at recovering >messages ) Or is the recovery scheme beyond the scope of the protocol ? [Jonathan]Currently, a window size is intentionally not specified. We can add a recommendation in terms of message transmission and processing if that is helpful. [vasant]-----it is not that simple. Once you enter the world of sliding window protocols, you have to test out the window sizes and timers for different networks and operating systems.What I meant by reinventing TCP was this maturing cycle and the sliding window part.Why put implementors through this pain when a readymade solution is available in TCP? [vasant]----I see a contradiction in your statement. May be you can clarify. Earlier you said you retransmit alarms until acknowledged. If you take that approcah you dont need any protocol for message recovery-and you dont need any window sizes. So are you recommending the "alarm-retransmission method" or the "window protocol method" ? >If a sliding window is chosen, the implementor will develop code to >reinvent what TCP does and will have to go through a maturing cycle for >his sliding window scheme. There will also be implementation issues >with managing real time OS timers at application level. [Jonathan]We certainly don't want to reinvent TCP. We don't need such a heavy-weight protocol for this interface. What we need is a reliable lightweight messaging protocol that can react to failures rapidly. >Keep in mind the WDM vendors are not in the business of developing >transmission protocols for reliablity.They need a solution that can be >easily added to their existing systems, many of which are legacy >systems. > >In contrast NTIP has thought through these issues and uses TCP as the >reliable transport. > > >To start with that is one fundamental difference in the transport of >NTIP vs LMP or WDM-LMP > >I am concerned about such open items in LMP which will come to haunt OLI >later. > >Vasant -----Original Message----- From: Mannie, Eric [ mailto: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_01C119FF.D90605D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

Jonathan,
My comments are in the text.

Regards
Vasant

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


Vasant,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Vasant Sahay
To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' = ';
''ccamp@ops.ietf.org' '
Sent: 7/30/2001 4:34 PM
Subject: RE: Optical Link Interface

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

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

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


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

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


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

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



-----Original Message-----
From: Mannie, Eric [ mailto: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_01C119FF.D90605D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 12:30:01 -0700 Message-ID: <3B670718.E8054409@lucent.com> Date: Tue, 31 Jul 2001 15:29:28 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Drafts update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I seemed to have missed a document: 4. draft-many-ccamp-gmpls-framework-00.txt - YES Zhi-Wei Lin wrote: > > Hi Kireeti, > > > 1. draft-dubuc-lmp-mib-02.txt [yes] > > 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes] > > 3. draft-kompella-ospf-gmpls-extensions-02.txt [not sure] > > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes] > > 6. draft-many-ccamp-gmpls-routing-00.txt [yes] Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 12:00:24 -0700 Message-ID: From: Jonathan Lang To: 'Vasant Sahay ' , "'Mannie, Eric '" , 'Bilel Jamoussi ' , '''Andre Fredette' ' ' , "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface Date: Tue, 31 Jul 2001 11:55:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vasant, Please see inline. Thanks, Jonathan -----Original Message----- From: Vasant Sahay To: Mannie, Eric; Bilel Jamoussi; ''Andre Fredette' '; ''ccamp@ops.ietf.org' ' Sent: 7/30/2001 4:34 PM Subject: RE: Optical Link Interface >>>>>>>>From my point of view, I don't see any reason to replace a protocol by >>>>>>>>another one if they have the same functionalities. >The misconception here is that they have the same functionalities and >that LMP definition is complete. I believe there is a lot of discussion >and thought that needs to go into LMP if used as basis for OLI. WDM-LMP >being based on LMP will also suffer that thrash. [Jonathan]...and NTIP is complete and will not suffer any thrashing? >Let us start with reliable transport(or lack thereof). >How are failures conveyed reliably from WDM to OXC ? > >LMP defines ACK messages, however I couldnt find any reference to how >they should be used to recover lost messages. [Jonathan]Failures notification is idempotent. LMP is optimized to react to alarms rapidly and doesn't require stop-and-wait procedures. Alarms are treated as independent events. Eash alarm is transmitted until acknowledged (see Section 6). If an alarm status changes, prior to receiving the Ack, the new status is simply transmitted. For a procedural reference, LMP works very much like that of RSVP-TE message Ids in RFC2961. >WDM-LMP draft specifies that an ACK should be sent for each >channelStatus message. This level of definition is far from complete. > >So the question is if a few hundred failures were reported, what is the >nature of this ACK scheme for recovering lost messages ? Are we going to >recommend a stop and wait protocol or a sliding window protocol ? (A >stop and wait scheme is easy to implement but slow at recovering >messages ) Or is the recovery scheme beyond the scope of the protocol ? [Jonathan]Currently, a window size is intentionally not specified. We can add a recommendation in terms of message transmission and processing if that is helpful. >If a sliding window is chosen, the implementor will develop code to >reinvent what TCP does and will have to go through a maturing cycle for >his sliding window scheme. There will also be implementation issues >with managing real time OS timers at application level. [Jonathan]We certainly don't want to reinvent TCP. We don't need such a heavy-weight protocol for this interface. What we need is a reliable lightweight messaging protocol that can react to failures rapidly. >Keep in mind the WDM vendors are not in the business of developing >transmission protocols for reliablity.They need a solution that can be >easily added to their existing systems, many of which are legacy >systems. > >In contrast NTIP has thought through these issues and uses TCP as the >reliable transport. > > >To start with that is one fundamental difference in the transport of >NTIP vs LMP or WDM-LMP > >I am concerned about such open items in LMP which will come to haunt OLI >later. > >Vasant -----Original Message----- From: Mannie, Eric [ mailto: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: Tue, 31 Jul 2001 08:39:35 -0700 Message-ID: <39469E08BD83D411A3D900204840EC5554C651@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "'ananth.nagarajan@mail.sprint.com'" , kireeti@juniper.net, rpapneja@osf1.gmu.edu Cc: ccamp@ops.ietf.org, "'te-wg@ops.ietf.org'" Subject: RE: Drafts update Date: Tue, 31 Jul 2001 11:37:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" All: I didn't understand why there is lot of confusion in TE drafts. To sum up... OSPF TE Draft is not part of any WG draft-katz-yeung-ospf-traffic-04.txt ISIS TE Draft is part of ISIS WG draft-ietf-isis-traffic-03.txt OSPF Diff TE Drafts are going in TE-WG draft-ietf-ospf-diff-te-00.txt draft-ietf-isis-diff-te-00.txt OSPF GMPLS are in CCAMP WG draft-kompella-ospf-gmpls-extensions-02.txt ISIS GMPLS are in ISIS WG draft-ietf-isis-gmpls-extensions-03.txt I strongly suggest/request, all extensions related to OSPF and ISIS should go to respective (OSPF/ISIS) WGs. Because the extensions (TLVs etc) are closely related to the protocols (irrespective of the features - TE, Diffserv, GMPLS etc) --Venkata Naidu -> presumably because draft-ietf-isis-gmpls-extensions-03.txt (note 03, -> not 02) is already an ISIS WG document. -> -> -----Original Message----- -> From: rpapneja [mailto:rpapneja@osf1.gmu.edu] -> Sent: Tuesday, July 31, 2001 9:52 AM -> To: kireeti -> Cc: rpapneja; ccamp -> Subject: RE: Drafts update -> -> -> Hello Kireeti -> -> A correction- -> -> I meant to say why -> "draft-ietf-isis-gmpls-extensions-02.txt" did not -> make -> it to the list instead of "draft-ietf-isis-traffic-02.txt". -> -> -Rajiv -> -> On Tue, 31 Jul 2001, Rajiv Papneja wrote: -> -> > Hello Kireeti, -> > -> > Here is my opinion on the list of proposed drafts: -> > -> > 1. draft-dubuc-lmp-mib-02.txt: -> {Yes} -> > (CCAMP WG documnet) -> > 2. draft-fontana-ccamp-gmpls-g709-00.txt: -> {Wait} -> > 3. draft-kompella-ospf-gmpls-extensions-02.txt: {Yes} -> > 4. draft-many-ccamp-gmpls-framework-00.txt - Yes: {Yes} -> > 5. -> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt: {Wait} -> > 6. draft-many-ccamp-gmpls-routing-00.txt: {Yes} -> > -> > I was just wondering that why -> (draft-ietf-isis-traffic-02.txt) did -> not -> > make it to the list. Thanks. -> > -> > Regards, -> > -Rajiv -> > -> > ******************************** -> > Rajiv Papneja (GRA) -> > Advanced Internet Laboratory -> > George Mason University, -> > G10, Johnson Center, -> > Fairfax, VA 22030-4444 -> > Tel: 703.993.4703 -> > email: rpapneja@osf1.gmu.edu -> > ******************************** -> > -> > -> > > -----Original Message----- -> > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Kireeti Kompella > > Sent: Saturday, July 28, 2001 5:37 AM > > To: ccamp@ops.ietf.org > > Subject: Drafts update > > > > > > Hi Folks, > > > > Can we get a sense of the consensus whether the following drafts > > should be made CCAMP WG documents? Please respond with > > (a) yes > > (b) no > > (c) wait > > > > 1. draft-dubuc-lmp-mib-02.txt > > 2. draft-fontana-ccamp-gmpls-g709-00.txt > > 3. draft-kompella-ospf-gmpls-extensions-02.txt > > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > 6. draft-many-ccamp-gmpls-routing-00.txt > > > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > > be a WG document, either in MPLS or CCAMP.) > > > > Thanks, > > Kireeti. > > > > > > > > > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 08:07:51 -0700 From: ananth.nagarajan@mail.sprint.com Date: Tue, 31 Jul 2001 10:03:12 -0500 Message-Id: Subject: RE: Drafts update MIME-Version: 1.0 TO: kireeti@juniper.net, rpapneja@osf1.gmu.edu CC: ccamp@ops.ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 31 Jul 2001 10:03:11 -0500" Content-Transfer-Encoding: 7bit presumably because draft-ietf-isis-gmpls-extensions-03.txt (note 03, not 02) is already an ISIS WG document. -----Original Message----- From: rpapneja [mailto:rpapneja@osf1.gmu.edu] Sent: Tuesday, July 31, 2001 9:52 AM To: kireeti Cc: rpapneja; ccamp Subject: RE: Drafts update Hello Kireeti A correction- I meant to say why "draft-ietf-isis-gmpls-extensions-02.txt" did not make it to the list instead of "draft-ietf-isis-traffic-02.txt". -Rajiv On Tue, 31 Jul 2001, Rajiv Papneja wrote: > Hello Kireeti, > > Here is my opinion on the list of proposed drafts: > > 1. draft-dubuc-lmp-mib-02.txt: {Yes} > (CCAMP WG documnet) > 2. draft-fontana-ccamp-gmpls-g709-00.txt: {Wait} > 3. draft-kompella-ospf-gmpls-extensions-02.txt: {Yes} > 4. draft-many-ccamp-gmpls-framework-00.txt - Yes: {Yes} > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt: {Wait} > 6. draft-many-ccamp-gmpls-routing-00.txt: {Yes} > > I was just wondering that why (draft-ietf-isis-traffic-02.txt) did not > make it to the list. Thanks. > > Regards, > -Rajiv > > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University, > G10, Johnson Center, > Fairfax, VA 22030-4444 > Tel: 703.993.4703 > email: rpapneja@osf1.gmu.edu > ******************************** > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Kireeti Kompella > > Sent: Saturday, July 28, 2001 5:37 AM > > To: ccamp@ops.ietf.org > > Subject: Drafts update > > > > > > Hi Folks, > > > > Can we get a sense of the consensus whether the following drafts > > should be made CCAMP WG documents? Please respond with > > (a) yes > > (b) no > > (c) wait > > > > 1. draft-dubuc-lmp-mib-02.txt > > 2. draft-fontana-ccamp-gmpls-g709-00.txt > > 3. draft-kompella-ospf-gmpls-extensions-02.txt > > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > 6. draft-many-ccamp-gmpls-routing-00.txt > > > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > > be a WG document, either in MPLS or CCAMP.) > > > > Thanks, > > Kireeti. > > > > > > > > > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 08:07:37 -0700 Message-ID: From: John Drake To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Drafts update Date: Tue, 31 Jul 2001 08:04:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, > 1. draft-dubuc-lmp-mib-02.txt [yes] > 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes] > 3. draft-kompella-ospf-gmpls-extensions-02.txt [yes] > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes] > 6. draft-many-ccamp-gmpls-routing-00.txt [yes] Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 07:55:17 -0700 Date: Tue, 31 Jul 2001 10:52:00 -0400 (EDT) From: Rajiv Papneja To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: RE: Drafts update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Kireeti A correction- I meant to say why "draft-ietf-isis-gmpls-extensions-02.txt" did not make it to the list instead of "draft-ietf-isis-traffic-02.txt". -Rajiv On Tue, 31 Jul 2001, Rajiv Papneja wrote: > Hello Kireeti, > > Here is my opinion on the list of proposed drafts: > > 1. draft-dubuc-lmp-mib-02.txt: {Yes} > (CCAMP WG documnet) > 2. draft-fontana-ccamp-gmpls-g709-00.txt: {Wait} > 3. draft-kompella-ospf-gmpls-extensions-02.txt: {Yes} > 4. draft-many-ccamp-gmpls-framework-00.txt - Yes: {Yes} > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt: {Wait} > 6. draft-many-ccamp-gmpls-routing-00.txt: {Yes} > > I was just wondering that why (draft-ietf-isis-traffic-02.txt) did not > make it to the list. Thanks. > > Regards, > -Rajiv > > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University, > G10, Johnson Center, > Fairfax, VA 22030-4444 > Tel: 703.993.4703 > email: rpapneja@osf1.gmu.edu > ******************************** > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Kireeti Kompella > > Sent: Saturday, July 28, 2001 5:37 AM > > To: ccamp@ops.ietf.org > > Subject: Drafts update > > > > > > Hi Folks, > > > > Can we get a sense of the consensus whether the following drafts > > should be made CCAMP WG documents? Please respond with > > (a) yes > > (b) no > > (c) wait > > > > 1. draft-dubuc-lmp-mib-02.txt > > 2. draft-fontana-ccamp-gmpls-g709-00.txt > > 3. draft-kompella-ospf-gmpls-extensions-02.txt > > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > 6. draft-many-ccamp-gmpls-routing-00.txt > > > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > > be a WG document, either in MPLS or CCAMP.) > > > > Thanks, > > Kireeti. > > > > > > > > > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 07:11:08 -0700 Date: Tue, 31 Jul 2001 10:07:37 -0400 (EDT) From: Rajiv Papneja To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: RE: Drafts update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Kireeti, Here is my opinion on the list of proposed drafts: 1. draft-dubuc-lmp-mib-02.txt: {Yes} (CCAMP WG documnet) 2. draft-fontana-ccamp-gmpls-g709-00.txt: {Wait} 3. draft-kompella-ospf-gmpls-extensions-02.txt: {Yes} 4. draft-many-ccamp-gmpls-framework-00.txt - Yes: {Yes} 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt: {Wait} 6. draft-many-ccamp-gmpls-routing-00.txt: {Yes} I was just wondering that why (draft-ietf-isis-traffic-02.txt) did not make it to the list. Thanks. Regards, -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Saturday, July 28, 2001 5:37 AM > To: ccamp@ops.ietf.org > Subject: Drafts update > > > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 Jul 2001 05:06:31 -0700 Message-ID: <3B669E2C.CCB6A47E@acm.org> Date: Tue, 31 Jul 2001 08:01:48 -0400 From: Matt Squire Reply-To: mattsquire@acm.org 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 More votes... Yes draft-dubuc-lmp-mib-02.txt Don't know draft-fontana-ccamp-gmpls-g709-00.txt Yes draft-kompella-ospf-gmpls-extensions-02.txt Yes draft-many-ccamp-gmpls-framework-00.txt Don't know draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt Yes draft-many-ccamp-gmpls-routing-00.txt > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Kireeti Kompella > > Sent: Saturday, July 28, 2001 5:37 AM > > To: ccamp@ops.ietf.org > > Subject: Drafts update > > > > > > Hi Folks, > > > > Can we get a sense of the consensus whether the following drafts > > should be made CCAMP WG documents? Please respond with > > (a) yes > > (b) no > > (c) wait > > > > 1. draft-dubuc-lmp-mib-02.txt > > 2. draft-fontana-ccamp-gmpls-g709-00.txt > > 3. draft-kompella-ospf-gmpls-extensions-02.txt > > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > 6. draft-many-ccamp-gmpls-routing-00.txt > > > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > > be a WG document, either in MPLS or CCAMP.) > > > > Thanks, > > Kireeti. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 23:34:42 -0700 From: "Hirokazu Ishimatsu" To: "Kireeti Kompella" , Subject: RE: Drafts update Date: Tue, 31 Jul 2001 15:37:18 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Kireeti, My opinion is : 1. draft-dubuc-lmp-mib-02.txt - Yes 2. draft-fontana-ccamp-gmpls-g709-00.txt - Yes 3. draft-kompella-ospf-gmpls-extensions-02.txt - Yes 4. draft-many-ccamp-gmpls-framework-00.txt - Yes 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - Wait 6. draft-many-ccamp-gmpls-routing-00.txt - Yes Best regards, Hirokazu Ishimatsu > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Saturday, July 28, 2001 5:37 AM > To: ccamp@ops.ietf.org > Subject: Drafts update > > > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 23:06:37 -0700 Message-ID: <3B664AA9.E7AE0AEA@lucent.com> Date: Tue, 31 Jul 2001 02:05:29 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies 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 Hi Kireeti, > 1. draft-dubuc-lmp-mib-02.txt [yes] > 2. draft-fontana-ccamp-gmpls-g709-00.txt [yes] > 3. draft-kompella-ospf-gmpls-extensions-02.txt [not sure] > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [yes] > 6. draft-many-ccamp-gmpls-routing-00.txt [yes] Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 16:37:21 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006BED310@zsc4c008.us.nortel.com> From: "Vasant Sahay" To: "Mannie, Eric" , "Bilel Jamoussi" , "''Andre Fredette' '" , "''ccamp@ops.ietf.org' '" Subject: RE: Optical Link Interface Date: Mon, 30 Jul 2001 16:34:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11950.27A2E6F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11950.27A2E6F0 Content-Type: text/plain; charset="iso-8859-1" >>>>>>>>From my point of view, I don't see any reason to replace a protocol by >>>>>>>>another one if they have the same functionalities. The misconception here is that they have the same functionalities and that LMP definition is complete. I believe there is a lot of discussion and thought that needs to go into LMP if used as basis for OLI. WDM-LMP being based on LMP will also suffer that thrash. Let us start with reliable transport(or lack thereof). How are failures conveyed reliably from WDM to OXC ? LMP defines ACK messages, however I couldnt find any reference to how they should be used to recover lost messages. WDM-LMP draft specifies that an ACK should be sent for each channelStatus message. This level of definition is far from complete. So the question is if a few hundred failures were reported, what is the nature of this ACK scheme for recovering lost messages ? Are we going to recommend a stop and wait protocol or a sliding window protocol ? (A stop and wait scheme is easy to implement but slow at recovering messages ) Or is the recovery scheme beyond the scope of the protocol ? If a sliding window is chosen, the implementor will develop code to reinvent what TCP does and will have to go through a maturing cycle for his sliding window scheme. There will also be implementation issues with managing real time OS timers at application level. Keep in mind the WDM vendors are not in the business of developing transmission protocols for reliablity.They need a solution that can be easily added to their existing systems, many of which are legacy systems. In contrast NTIP has thought through these issues and uses TCP as the reliable transport. To start with that is one fundamental difference in the transport of NTIP vs LMP or WDM-LMP I am concerned about such open items in LMP which will come to haunt OLI later. Vasant -----Original Message----- From: Mannie, Eric [mailto: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 ] 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_01C11950.27A2E6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

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

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

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

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

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

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

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

 
In contrast NTIP has thought through these issues = and uses TCP as the reliable transport.

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

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

Vasant



-----Original Message-----
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]<= /FONT>
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; ]
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_01C11950.27A2E6F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 16:06:50 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D02204040198242E@mail1.tellium.com> From: Bala Rajagopalan To: "'Jonathan Lang '" , Bala Rajagopalan , "'''Andre Fredette ' ' '" Cc: "''''ccamp@ops.ietf.org' ' ' '" Subject: RE: Optical Link Interface - LMP-WDM comments Date: Mon, 30 Jul 2001 19:04:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan & Andre: My intent was to give a constructive suggestion on moving forward. Specifically, if the motivation for NTIP was to do a targetted protocol for OLI, the same purpose could perhaps be achieved by streamlining LMP-WDM. So, please look at the technical issues pointed out and of course, we can discuss these. Some of my questions in the attachment were for clarification also. With regard to Jonathan's comments: 1. OLI: Yes, I am an author in the OLI requirements. I have repeatedly said that OLI is important. Yet, I don't (and didn't) agree with every requirement in the OLI document. (I'm not the only author in that document). The way I see it, we just have the 00 version. Things could change going forward. 2. LMP vs LMP-WDM: I've indicated some particulars about this in the attachment. I'll look into this further. 3. Link verification: It's a matter of cost vs benefit. Again, as I said earlier, this is an area requiring more thought and refinement. Regards, Bala -----Original Message----- From: Jonathan Lang To: Jonathan Lang; ''Bala Rajagopalan ' '; ''Andre Fredette ' ' Cc: '''ccamp@ops.ietf.org' ' ' Sent: 7/30/01 5:37 PM Subject: RE: Optical Link Interface - LMP-WDM comments Bala, [replying to my previous email] I just realized there was an attachment to your email. Having gone over those details, I see you have given specifics to your points (1) and (4). Please ignore my comment for (4) - we will work on clarifications here. I believe my comments on the other points, other than "What specific information are you talking about here?" in (1), are still valid. Thanks, Jonathan -----Original Message----- From: Jonathan Lang To: 'Bala Rajagopalan '; 'Andre Fredette ' Cc: ''ccamp@ops.ietf.org' ' Sent: 7/30/2001 1:47 PM Subject: RE: Optical Link Interface - LMP-WDM comments Bala, Please see inline. Thanks, Jonathan >-----Original Message----- >From: Bala Rajagopalan >To: Andre Fredette >Cc: 'ccamp@ops.ietf.org' >Sent: 7/30/2001 7:38 AM >Subject: Optical Link Interface - LMP-WDM comments > >Andre: > >I'm attaching specific comments on LMP-WDM. Top level issues are >as follows: > >1. Layer mix-up: In some places, the WDM system is required to >send information which is not native to OLS to the OXCs. In fact, >this is very strange, because this information must originate from >the OXC domain, get configured in WDM, and then go back to OXCs. This >is a problem with OLI definition, not LMP-WDM itself. This requires >some discussion and clean up. What specific information are you talking about here? As you say, this is an issue with OLI definition itself and the parameters were discussed at quite length among both LMP-WDM authors and NTIP authors. (I do notice that you are also listed as an OLI author...). Certainly we can revisit these issues if they need to be addressed... >2. Rather than tailoring the procedures for the particular requirements >(OLI), the draft seems to be written with the goal of maximal reuse of >LMP. This sometimes adds to the complexity of the proposal. LMP-WDM was written to satisfy the OLI requirements and reuse the LMP protocol. This is similar to the approach taken for GMPLS RSVP-TE and CR-LDP. >Specifically, LMP-WDM has many "extensions" to LMP, giving the impression >that LMP-WDM is a superset of LMP. I think there are differences in the >situations where LMP is applied as compared to LMP-WDM and these aspects >are not discussed sufficiently. I think a meticulous examination of the >OLI requirements and LMP procedures is necessary to just carve out a set >of procedures for OLI, rather than the superset approach. The maximal >"re-use" argument doesn't make any sense on the WDM side where there is >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is >where NTIP makes a good point). Which LMP-WDM procedures are not required for OLI? >3. I'm afraid the current LMP link verification definition (and as a >corollary, LMP-WDM link verification) has only a marginal value >considering the investment on hardware and protocol implementation. This >is an area that requires more work. If you believe link verification has marginal value, you don't have to implement it (remember it's optional). We have heard otherwise from customers. >4. Some of the procedures in the draft must be more explicitly described >rather than saying that they are same as LMP's. Please clarify which procedures you are referring to. >As you noted, a more careful examination of LMP itself is in order. This is greatly encouraged. I also think it would be useful for you to do a similar analysis of NTIP. Thanks, Jonathan >Regards, > >Bala > >Bala Rajagopalan >Tellium, Inc. >2 Crescent Place >P.O. Box 901 >Oceanport, NJ 07757-0901 >Tel: (732) 923-4237 >Fax: (732) 923-9804 >Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 15:25:15 -0700 Message-ID: From: "Mannie, Eric" To: 'Bilel Jamoussi ' , ''Andre Fredette' ' , "''ccamp@ops.ietf.org' '" Subject: RE: Optical Link Interface Date: Tue, 31 Jul 2001 00:21:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 ] 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: Mon, 30 Jul 2001 15:15:00 -0700 From: Andre Fredette To: Bala Rajagopalan Cc: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010730180451.02fc5a68@mailbox> Date: Mon, 30 Jul 2001 18:09:58 -0400 Subject: RE: Optical Link Interface - LMP-WDM comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Bala, Sorry, but I missed your attachment also. I'll get back to you on your specific issues. Andre At 02:37 PM 7/30/2001 -0700, you wrote: >Bala, > >[replying to my previous email] > >I just realized there was an attachment to your email. Having gone over >those details, I see you have given specifics to your points (1) and (4). >Please ignore my comment for (4) - we will work on clarifications here. I >believe my comments on the other points, other than "What specific >information are you talking about here?" in (1), are still valid. > >Thanks, >Jonathan > >-----Original Message----- >From: Jonathan Lang >To: 'Bala Rajagopalan '; 'Andre Fredette ' >Cc: ''ccamp@ops.ietf.org' ' >Sent: 7/30/2001 1:47 PM >Subject: RE: Optical Link Interface - LMP-WDM comments > > Bala, > Please see inline. > >Thanks, >Jonathan > > >-----Original Message----- > >From: Bala Rajagopalan > >To: Andre Fredette > >Cc: 'ccamp@ops.ietf.org' > >Sent: 7/30/2001 7:38 AM > >Subject: Optical Link Interface - LMP-WDM comments > > > >Andre: > > > >I'm attaching specific comments on LMP-WDM. Top level issues are > >as follows: > > > >1. Layer mix-up: In some places, the WDM system is required to > >send information which is not native to OLS to the OXCs. In fact, > >this is very strange, because this information must originate from > >the OXC domain, get configured in WDM, and then go back to OXCs. This > >is a problem with OLI definition, not LMP-WDM itself. This requires > >some discussion and clean up. >What specific information are you talking about here? As you say, this >is >an issue with OLI definition itself and the parameters were discussed at >quite length among both LMP-WDM authors and NTIP authors. (I do notice >that >you are also listed as an OLI author...). Certainly we can revisit >these >issues if they need to be addressed... > > >2. Rather than tailoring the procedures for the particular requirements > >(OLI), the draft seems to be written with the goal of maximal reuse of > >LMP. This sometimes adds to the complexity of the proposal. >LMP-WDM was written to satisfy the OLI requirements and reuse the LMP >protocol. This is similar to the approach taken for GMPLS RSVP-TE and >CR-LDP. > > >Specifically, LMP-WDM has many "extensions" to LMP, giving the >impression > >that LMP-WDM is a superset of LMP. I think there are differences in the > >situations where LMP is applied as compared to LMP-WDM and these >aspects > >are not discussed sufficiently. I think a meticulous examination of the > >OLI requirements and LMP procedures is necessary to just carve out a >set > >of procedures for OLI, rather than the superset approach. The maximal > >"re-use" argument doesn't make any sense on the WDM side where there is > >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is > >where NTIP makes a good point). >Which LMP-WDM procedures are not required for OLI? > > >3. I'm afraid the current LMP link verification definition (and as a > >corollary, LMP-WDM link verification) has only a marginal value > >considering the investment on hardware and protocol implementation. >This > >is an area that requires more work. >If you believe link verification has marginal value, you don't have to >implement it (remember it's optional). We have heard otherwise from >customers. > > >4. Some of the procedures in the draft must be more explicitly >described > >rather than saying that they are same as LMP's. >Please clarify which procedures you are referring to. > > >As you noted, a more careful examination of LMP itself is in order. >This is greatly encouraged. > >I also think it would be useful for you to do a similar analysis of >NTIP. > >Thanks, >Jonathan > > >Regards, > > > >Bala > > > >Bala Rajagopalan > >Tellium, Inc. > >2 Crescent Place > >P.O. Box 901 > >Oceanport, NJ 07757-0901 > >Tel: (732) 923-4237 > >Fax: (732) 923-9804 > >Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 15:06:40 -0700 Message-ID: From: "Mannie, Eric" To: 'Yangguang Xu ' , "'kireeti@juniper.net '" Cc: "'ccamp@ops.ietf.org '" Subject: RE: Drafts update Date: Tue, 31 Jul 2001 00:04:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear All, >5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure I hope at least that all the people that claimed that virtual concatenation is THE solution will enjoy and support this work since it is only intended to maximize the use of virtual concatenation in a network using GMPLS signaling. I am also claiming that virtual concatenation is THE solution in this draft. It does NOT define ANY concatenation type. It just tries to find an ITU-T converter between standard contiguous concatenation and standard virtual concatenation as close as possible to the source. At least this time I am only referring to ITU-T standards :-) So don't blame me :-) Kind regards, Eric -----Original Message----- From: Yangguang Xu To: kireeti@juniper.net Cc: ccamp@ops.ietf.org Sent: 7/30/01 7:04 PM Subject: Re: Drafts update Kireeti, My "votes" : 1. draft-dubuc-lmp-mib-02.txt - YES 2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure 3. draft-kompella-ospf-gmpls-extensions-02.txt - if 6 is in, should this belong to OSPF WG? 4. draft-many-ccamp-gmpls-framework-00.txt - YES 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure 6. draft-many-ccamp-gmpls-routing-00.txt - YES Thanks, Yangguang > -----Original Message----- > From: kireeti [mailto:kireeti@juniper.net] > Sent: Friday, July 27, 2001 3:37 PM > To: ccamp > Cc: kireeti > Subject: Drafts update > > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 14:45:38 -0700 Message-ID: From: Jonathan Lang To: Jonathan Lang , ''Bala Rajagopalan ' ' , ''Andre Fredette ' ' Cc: "'''ccamp@ops.ietf.org' ' '" Subject: RE: Optical Link Interface - LMP-WDM comments Date: Mon, 30 Jul 2001 14:37:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bala, [replying to my previous email] I just realized there was an attachment to your email. Having gone over those details, I see you have given specifics to your points (1) and (4). Please ignore my comment for (4) - we will work on clarifications here. I believe my comments on the other points, other than "What specific information are you talking about here?" in (1), are still valid. Thanks, Jonathan -----Original Message----- From: Jonathan Lang To: 'Bala Rajagopalan '; 'Andre Fredette ' Cc: ''ccamp@ops.ietf.org' ' Sent: 7/30/2001 1:47 PM Subject: RE: Optical Link Interface - LMP-WDM comments Bala, Please see inline. Thanks, Jonathan >-----Original Message----- >From: Bala Rajagopalan >To: Andre Fredette >Cc: 'ccamp@ops.ietf.org' >Sent: 7/30/2001 7:38 AM >Subject: Optical Link Interface - LMP-WDM comments > >Andre: > >I'm attaching specific comments on LMP-WDM. Top level issues are >as follows: > >1. Layer mix-up: In some places, the WDM system is required to >send information which is not native to OLS to the OXCs. In fact, >this is very strange, because this information must originate from >the OXC domain, get configured in WDM, and then go back to OXCs. This >is a problem with OLI definition, not LMP-WDM itself. This requires >some discussion and clean up. What specific information are you talking about here? As you say, this is an issue with OLI definition itself and the parameters were discussed at quite length among both LMP-WDM authors and NTIP authors. (I do notice that you are also listed as an OLI author...). Certainly we can revisit these issues if they need to be addressed... >2. Rather than tailoring the procedures for the particular requirements >(OLI), the draft seems to be written with the goal of maximal reuse of >LMP. This sometimes adds to the complexity of the proposal. LMP-WDM was written to satisfy the OLI requirements and reuse the LMP protocol. This is similar to the approach taken for GMPLS RSVP-TE and CR-LDP. >Specifically, LMP-WDM has many "extensions" to LMP, giving the impression >that LMP-WDM is a superset of LMP. I think there are differences in the >situations where LMP is applied as compared to LMP-WDM and these aspects >are not discussed sufficiently. I think a meticulous examination of the >OLI requirements and LMP procedures is necessary to just carve out a set >of procedures for OLI, rather than the superset approach. The maximal >"re-use" argument doesn't make any sense on the WDM side where there is >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is >where NTIP makes a good point). Which LMP-WDM procedures are not required for OLI? >3. I'm afraid the current LMP link verification definition (and as a >corollary, LMP-WDM link verification) has only a marginal value >considering the investment on hardware and protocol implementation. This >is an area that requires more work. If you believe link verification has marginal value, you don't have to implement it (remember it's optional). We have heard otherwise from customers. >4. Some of the procedures in the draft must be more explicitly described >rather than saying that they are same as LMP's. Please clarify which procedures you are referring to. >As you noted, a more careful examination of LMP itself is in order. This is greatly encouraged. I also think it would be useful for you to do a similar analysis of NTIP. Thanks, Jonathan >Regards, > >Bala > >Bala Rajagopalan >Tellium, Inc. >2 Crescent Place >P.O. Box 901 >Oceanport, NJ 07757-0901 >Tel: (732) 923-4237 >Fax: (732) 923-9804 >Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 14:35:11 -0700 Message-ID: From: "Bilel Jamoussi" To: "'John Drake'" , "'Andre Fredette'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Mon, 30 Jul 2001 17:31:01 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1193E.EE2EDD40" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1193E.EE2EDD40 Content-Type: text/plain; charset="iso-8859-1" John, 2. I do not think IETF uses company affiliation when measuring consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is an indication that there is an immediate need for NTIP given Nortel is a key player in this space. [John Drake] The fact that you perceive yourself to be a key player shouldn't a priori give your opinion any additional weight [Jamoussi, Bilel ] I am speaking of a market reality and stating facts not perceptions. My point is clear, IETF does not use company affiliations and I am not advocating more or less weight. . WDM-LMP assumes that LMP is a priority, people will implement LMP, hence WDM-LMP is a natural extension. The issues here are: (a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are more urgent than LMP [John Drake] What is the basis for this assertion? When we started the LMP-WDM work we asked you to work on it with us and you refused, citing lack of need. [Jamoussi, Bilel ] This is simply not true. 2. WDM-LMP assumes a peer model between the OXC and the WDM system. The issue: - this model doesn't reflect the reality that OXC and WDM are two different devices - the OXC-WDM relationship is client-server one. [John Drake] This is an assertion. Some of the co-authors of the LMP WDM draft work for WDM vendors and they're happy with the peer relationship between the two devices [Jamoussi, Bilel ] This is an assertion ;-) Bilel. -----Original Message----- From: Andre Fredette [ mailto: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_01C1193E.EE2EDD40 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
John,
2. I do not think IETF uses company affiliation when measuring consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is an indication that there is an immediate need for NTIP given Nortel is a key player in this space.
[John Drake] 

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

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

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

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

and you refused, citing lack of need.

[Jamoussi, Bilel ] This is simply not true.  

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

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

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

the peer relationship between the two devices   

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

Bilel.

-----Original Message-----
From: Andre Fredette [mailto: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_01C1193E.EE2EDD40-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 14:22:00 -0700 From: Andre Fredette To: 'Bala Rajagopalan ' , Jonathan Lang Cc: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010730165546.02cfadc0@mailbox> Date: Mon, 30 Jul 2001 17:20:48 -0400 Subject: RE: Optical Link Interface - LMP-WDM comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This remains the question of the day. (Or is it the past 6 months?) What in LMP is not required for OLI? From my analysis, the only thing I can determine is that the notion of bundles is not needed on the OLS. However, this LMP feature can be treated as an arbitrary "administrative grouping" of links which may prove useful. If not, just use a single "bundle" on the OLS and effectively ignore this LMP feature. Given this analysis, I think it is better to reuse an existing protocol than create a new one. I have a number of issues with the content of NTIP, but I don't think it is worth debating them because I don't think we should create a new protocol to start with. Furthermore, any of the content issues can be addressed in the context of either protocol. Andre At 01:47 PM 7/30/2001 -0700, Jonathan Lang wrote: > >-----Original Message----- > >From: Bala Rajagopalan > >2. Rather than tailoring the procedures for the particular requirements > >(OLI), the draft seems to be written with the goal of maximal reuse of > >LMP. This sometimes adds to the complexity of the proposal. >LMP-WDM was written to satisfy the OLI requirements and reuse the LMP >protocol. This is similar to the approach taken for GMPLS RSVP-TE and >CR-LDP. > > >Specifically, LMP-WDM has many "extensions" to LMP, giving the impression > >that LMP-WDM is a superset of LMP. I think there are differences in the > >situations where LMP is applied as compared to LMP-WDM and these aspects > >are not discussed sufficiently. I think a meticulous examination of the > >OLI requirements and LMP procedures is necessary to just carve out a set > >of procedures for OLI, rather than the superset approach. The maximal > >"re-use" argument doesn't make any sense on the WDM side where there is > >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is > >where NTIP makes a good point). >Which LMP-WDM procedures are not required for OLI? Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 13:54:59 -0700 Message-ID: From: Jonathan Lang To: 'Bala Rajagopalan ' , 'Andre Fredette ' Cc: "''ccamp@ops.ietf.org' '" Subject: RE: Optical Link Interface - LMP-WDM comments Date: Mon, 30 Jul 2001 13:47:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bala, Please see inline. Thanks, Jonathan >-----Original Message----- >From: Bala Rajagopalan >To: Andre Fredette >Cc: 'ccamp@ops.ietf.org' >Sent: 7/30/2001 7:38 AM >Subject: Optical Link Interface - LMP-WDM comments > >Andre: > >I'm attaching specific comments on LMP-WDM. Top level issues are >as follows: > >1. Layer mix-up: In some places, the WDM system is required to >send information which is not native to OLS to the OXCs. In fact, >this is very strange, because this information must originate from >the OXC domain, get configured in WDM, and then go back to OXCs. This >is a problem with OLI definition, not LMP-WDM itself. This requires >some discussion and clean up. What specific information are you talking about here? As you say, this is an issue with OLI definition itself and the parameters were discussed at quite length among both LMP-WDM authors and NTIP authors. (I do notice that you are also listed as an OLI author...). Certainly we can revisit these issues if they need to be addressed... >2. Rather than tailoring the procedures for the particular requirements >(OLI), the draft seems to be written with the goal of maximal reuse of >LMP. This sometimes adds to the complexity of the proposal. LMP-WDM was written to satisfy the OLI requirements and reuse the LMP protocol. This is similar to the approach taken for GMPLS RSVP-TE and CR-LDP. >Specifically, LMP-WDM has many "extensions" to LMP, giving the impression >that LMP-WDM is a superset of LMP. I think there are differences in the >situations where LMP is applied as compared to LMP-WDM and these aspects >are not discussed sufficiently. I think a meticulous examination of the >OLI requirements and LMP procedures is necessary to just carve out a set >of procedures for OLI, rather than the superset approach. The maximal >"re-use" argument doesn't make any sense on the WDM side where there is >no LMP. Or, for that matter, where OXCs don't implement LMP. (This is >where NTIP makes a good point). Which LMP-WDM procedures are not required for OLI? >3. I'm afraid the current LMP link verification definition (and as a >corollary, LMP-WDM link verification) has only a marginal value >considering the investment on hardware and protocol implementation. This >is an area that requires more work. If you believe link verification has marginal value, you don't have to implement it (remember it's optional). We have heard otherwise from customers. >4. Some of the procedures in the draft must be more explicitly described >rather than saying that they are same as LMP's. Please clarify which procedures you are referring to. >As you noted, a more careful examination of LMP itself is in order. This is greatly encouraged. I also think it would be useful for you to do a similar analysis of NTIP. Thanks, Jonathan >Regards, > >Bala > >Bala Rajagopalan >Tellium, Inc. >2 Crescent Place >P.O. Box 901 >Oceanport, NJ 07757-0901 >Tel: (732) 923-4237 >Fax: (732) 923-9804 >Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 13:54:53 -0700 From: Andre Fredette To: Bilel Jamoussi Cc: John Drake , ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010730164259.02bde9d0@mailbox> Date: Mon, 30 Jul 2001 16:51:03 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26705370==_.ALT" --=====================_26705370==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bilel, I might not have worded my response exactly as John did (being the nice guy that I am), but I agree with his answers. In particular, you continue to talk about "unnecessary LMP baggage", or "complexity", but cannot describe what it is. Andre At 01:24 PM 7/30/2001 -0700, John Drake wrote: -----Original Message----- From: Bilel Jamoussi [ mailto: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. --=====================_26705370==_.ALT Content-Type: text/html; charset="us-ascii" 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.
--=====================_26705370==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 13:51:14 -0700 Message-Id: <200107301359.JAA22631@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lmp-00.txt Date: Mon, 30 Jul 2001 09:59:23 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang et al. Filename : draft-ietf-ccamp-lmp-00.txt Pages : 57 Date : 27-Jul-01 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels, links, and bundled links. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage traffic engineering (TE) links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010727132406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010727132406.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 13:27:12 -0700 Message-ID: From: John Drake To: Bilel Jamoussi , 'Andre Fredette' , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Mon, 30 Jul 2001 13:24:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11935.A86866E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11935.A86866E0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Bilel Jamoussi [mailto: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_01C11935.A86866E0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
 
-----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_01C11935.A86866E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 11:41:11 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: lberger@movaz.com, Eric.Mannie@ebone.com Bcc: Subject: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Mon, 30 Jul 2001 11:37:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: 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: Mon, 30 Jul 2001 11:36:51 -0700 Message-ID: <3B65A9D7.7188D23C@research.att.com> Date: Mon, 30 Jul 2001 14:39:19 -0400 From: Guangzhi Li MIME-Version: 1.0 To: kireeti@juniper.net Cc: gli@research.att.com, ccamp@ops.ietf.org Subject: Re: Drafts update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Kireeti, > > My "votes" : > > 1. draft-dubuc-lmp-mib-02.txt - YES > 2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure > 3. draft-kompella-ospf-gmpls-extensions-02.txt - YES > 4. draft-many-ccamp-gmpls-framework-00.txt - YES > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure > 6. draft-many-ccamp-gmpls-routing-00.txt - YES Could 3 and 6 combine together ? Thanks, Guangzhi Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 10:53:14 -0700 Date: Mon, 30 Jul 2001 10:48:13 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107301748.KAA23187@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP agenda Hi, Here's the final agenda. Thanks, Kireeti & Vijay. --------------- Administrivia/Blue Sheets/ Minutes takers 5 min Charter & drafts update 10 min Update from the Design Teams 10 min GMPLS update (Lou Berger) 10 min SONET/SDH (Eric Mannie) 15 min G709 (Dimitri?) 10 min GMPLS MIBs 5 min Architecture (Eric Mannie) 10 min Framework (Yangguang Xu) 5 min SONET/SDH framework (Greg B.) 5 min LMP (Jonathan Lang) 5 min LMP MIB (Martin Dubuc) 5 min OLI Reqts (Andre+Osama) 5 min NTIP (Osama Aboul-Magd) 10 min LMP-WDM (Andre Fredette) 10 min resolution 5 min Tunnel Trace (Ron Bonica) 10 min RSVP for Mesh (Kalmanek/Li) 5 min | subject to time RSVP for OAPS (Dan Guo) 5 min | availability ------------------------------- CCAMP WG documents (Joint with MPLS) draft-ietf-mpls-generalized-cr-ldp-04.txt draft-ietf-mpls-generalized-rsvp-te-04.txt draft-ietf-mpls-generalized-signaling-05.txt draft-ietf-ccamp-gmpls-architecture-00.txt draft-ietf-ccamp-gmpls-sonet-sdh-01.txt draft-ietf-ccamp-lmp-00.txt Under consideration: 1. draft-dubuc-lmp-mib-02.txt 2. draft-fontana-ccamp-gmpls-g709-00.txt 3. draft-kompella-ospf-gmpls-extensions-02.txt 4. draft-many-ccamp-gmpls-framework-00.txt 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt 6. draft-many-ccamp-gmpls-routing-00.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 10:15:32 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Martin Dubuc'" , "'Andre Fredette'" , "'ccamp'" Subject: RE: Optical Link Interface Date: Mon, 30 Jul 2001 13:08:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1191A.4F920BE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1191A.4F920BE0 Content-Type: text/plain; charset="iso-8859-1" Martin, Please see inline: Bilel, I don't see evidence that there is more than one vendor implementing NTIP. [Jamoussi, Bilel ] so what? why is this relevant at this point? I don't see any reasons to standardize it at this point. [Jamoussi, Bilel ] both NTIP and WDM-LMP??? what about the OLI requirements? are you proposing we ignore them? On the other hand, I have seen support for LMP-WDM from several vendors in the past few days. [Jamoussi, Bilel ] vendors of what? Martin [Jamoussi, Bilel ] Do you have any comments on my proposal to progress the work? Bilel. -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Monday, July 30, 2001 11: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. 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 ] 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_01C1191A.4F920BE0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Martin,
 
Please see inline:
Bilel,
 
I don't see evidence that there is more than one vendor implementing NTIP.
[Jamoussi, Bilel ] so what? why is this relevant at this point?
 
I don't see any reasons to standardize it at this point.
[Jamoussi, Bilel ] both NTIP and WDM-LMP??? what about the OLI requirements? are you proposing we ignore them?
 
On the other hand, I have seen support for LMP-WDM from several vendors in the past few days.
[Jamoussi, Bilel ] vendors of what?
 
Martin
[Jamoussi, Bilel ] Do you have any comments on my proposal to progress the work? 
Bilel.
-----Original Message-----
From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, 2001 11: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.

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]
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_01C1191A.4F920BE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 10:05:28 -0700 Message-ID: <3B65939E.B060AE9A@lucent.com> Date: Mon, 30 Jul 2001 13:04:30 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: kireeti@juniper.net CC: ccamp@ops.ietf.org Subject: Re: Drafts update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, My "votes" : 1. draft-dubuc-lmp-mib-02.txt - YES 2. draft-fontana-ccamp-gmpls-g709-00.txt - not sure 3. draft-kompella-ospf-gmpls-extensions-02.txt - if 6 is in, should this belong to OSPF WG? 4. draft-many-ccamp-gmpls-framework-00.txt - YES 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - not sure 6. draft-many-ccamp-gmpls-routing-00.txt - YES Thanks, Yangguang > -----Original Message----- > From: kireeti [mailto:kireeti@juniper.net] > Sent: Friday, July 27, 2001 3:37 PM > To: ccamp > Cc: kireeti > Subject: Drafts update > > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 09:08:39 -0700 Date: Mon, 30 Jul 2001 09:06:05 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107301606.JAA22432@kummer.juniper.net> To: kireeti@juniper.net, xuyg@lucent.com Subject: Re: Drafts update Cc: ccamp@ops.ietf.org Hi Yangguang, > May I ask why draft-xu-bgp-gmpls-01.txt is not in the list? You certainly may. It is not in CCAMP's scope/charter. We'll have a discussion on the charter at this IETF, but a) a discussion doesn't mean that everything discussed gets on the charter; b) even if on the charter, it's way too early to even begin deliberations on whether this should be a WG doc. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 09:08:33 -0700 content-class: urn:content-classes:message Subject: RE: Optical Link Interface MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11911.952C0287" Date: Mon, 30 Jul 2001 12:06:25 -0400 Message-ID: Thread-Topic: Optical Link Interface Thread-Index: AcEZDTShlW6qeG38RWWzTAuGiSCl9AAA4y1A From: "Martin Dubuc" To: "Bilel Jamoussi" , "Andre Fredette" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C11911.952C0287 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bilel, =20 I don't see evidence that there is more than one vendor implementing NTIP. I don't see any reasons to standardize it at this point. On the other hand, I have seen support for LMP-WDM from several vendors in the past few days. =20 Martin -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Monday, July 30, 2001 11:14 AM To: 'Andre Fredette'; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface Andre,=20 2 comments on you statistics, then a proposal to progress:=20 1. The stats are not that significant, since there was no "last call" period announced in advance to gauge community interest. 2. I do not think IETF uses company affiliation when measuring consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is an indication that there is an immediate need for NTIP given Nortel is a key player in this space. ------=20 All,=20 Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a merged version),=20 - There is consensus on a single protocol which I respect.=20 - Key distinctions between NTIP and WDM-LMP:=20 1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence WDM-LMP is a natural extension. The issues here are: (a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are more urgent than LMP=20 (b) there is significant baggage to be carried from LMP down to the WDM-LMP=20 2. WDM-LMP assumes a peer model between the OXC and the WDM system. The issue:=20 - this model doesn't reflect the reality that OXC and WDM are two different devices - the OXC-WDM relationship is client-server one. I suggest merging the two proposals as follows:=20 - remove unnecessary LMP baggage=20 - adopt a client-server model=20 - allow for TCP as the transport=20 - clarify a simplified autodiscovery mechanism=20 Bilel.=20 -----Original Message-----=20 From: Andre Fredette [ mailto:fredette@photonex.com]=20 Sent: Thursday, July 26, 2001 2:52 PM=20 To: ccamp@ops.ietf.org=20 Subject: RE: Optical Link Interface=20 From my count on the mailing list we have the following results so far: LMP-WDM: 8=20 NTIP: 3 (All from Nortel)=20 Agnostic: 1=20 And then there are the other 16 co-authors of LMP-WDM who haven't posted (perhaps because they don't think they have any new points to add).=20 Andre=20 At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:=20 >Kireeti,=20 >=20 >I have been following this thread with great interest. I agree with your=20 >conclusion that we should pick one protocol and move forward.=20 >=20 >You are talking about WG reaching a consensus. I cannot see how this is >possible given the two very different views I see in the latest email=20 >exchanges.=20 >=20 >How can we resolve the current dispute? What forum should we use to make=20 >a final decision on this?=20 >=20 >Martin=20 >=20 >-----Original Message-----=20 >From: Kireeti Kompella [ mailto:kireeti@juniper.net]=20 >Sent: Wednesday, July 25, 2001 9:57 PM=20 >To: jamoussi@nortelnetworks.com; kireeti@juniper.net;=20 >osama@nortelnetworks.com=20 >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;=20 >vasants@nortelnetworks.com=20 >Subject: RE: Optical Link Interface=20 >=20 >=20 >Hi Osama,=20 >=20 > > Even though I don't think reviving CR-LDP and RSVP-TE history will get=20 >us=20 > > anywhere=20 >=20 >"Those who forget (ignore) history are doomed to repeat it."=20 >=20 >Yes, it makes for painful recollections. We're living with the=20 >consequences now, though, and I don't want to again.=20 >=20 > > the existence of two protocols here have proven to be useful.=20 >=20 >That's not what I'm hearing, either from customers, or from the=20 >WG (admittedly, the sample is small).=20 >=20 >Listen carefully: I don't want LMP-WDM and NTIP moving forward.=20 >Just NTIP (or NTIP and LMP) is OKAY if that is what the WG=20 >consensus is. LMP-WDM and LMP works too.=20 >=20 >So: you've got the WG chairs (scarred and grumpy), the ADs=20 >and TA (speak up if I'm misrepresenting you), and customers=20 >saying, Pick one protocol and move forward. Let's do that.=20 >And, please, as Vijay says, let's resolve this already.=20 >=20 >Kireeti.=20 ------_=_NextPart_001_01C11911.952C0287 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface
Bilel,
 
I=20 don't see evidence that there is more than one vendor=20 implementing NTIP. I don't see any reasons to standardize it at = this point.=20 On the other hand, I have seen support for LMP-WDM from several = vendors in=20 the past few days.
 
Martin
-----Original Message-----
From: Bilel Jamoussi=20 [mailto:jamoussi@nortelnetworks.com]
Sent: Monday, July 30, = 2001=20 11:14 AM
To: 'Andre Fredette';=20 'ccamp@ops.ietf.org'
Subject: RE: Optical Link=20 Interface

Andre,

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

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

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

------

All,

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

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

- Key distinctions between NTIP and WDM-LMP: =

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

(a) this assumption is not accurate, the functions = of NTIP (or=20 WDM-LMP) are more urgent than LMP
(b) there = is=20 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=20 system. The issue:

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

I suggest merging the two proposals as = follows:

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

Bilel.

-----Original Message-----
From: Andre=20 Fredette [mailto:fredette@photonex.com]=20
Sent: Thursday, July 26, 2001 2:52 PM =
To: ccamp@ops.ietf.org
Subject: RE: = Optical=20 Link Interface


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

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

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

Andre

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

------_=_NextPart_001_01C11911.952C0287-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 09:01:58 -0700 content-class: urn:content-classes:message Subject: RE: Drafts update MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jul 2001 11:59:12 -0400 Message-ID: Thread-Topic: Drafts update Thread-Index: AcEW39AAl/Y7GhhrTMGdD6z7IsoImwCMEGiw From: "Martin Dubuc" To: "Kireeti Kompella" Cc: Response below. -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, July 27, 2001 4:37 PM To: ccamp@ops.ietf.org Subject: Drafts update Hi Folks, Can we get a sense of the consensus whether the following drafts should be made CCAMP WG documents? Please respond with (a) yes (b) no (c) wait 1. draft-dubuc-lmp-mib-02.txt [YES] 2. draft-fontana-ccamp-gmpls-g709-00.txt [NO OPINION] 3. draft-kompella-ospf-gmpls-extensions-02.txt [YES] 4. draft-many-ccamp-gmpls-framework-00.txt [YES] 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt [NO OPINION] 6. draft-many-ccamp-gmpls-routing-00.txt [YES] (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this be a WG document, either in MPLS or CCAMP.) Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 08:50:53 -0700 From: ananth.nagarajan@mail.sprint.com Date: Mon, 30 Jul 2001 10:49:09 -0500 Message-Id: Subject: RE: Drafts update MIME-Version: 1.0 TO: ccamp@ops.ietf.org, kireeti@juniper.net Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 30 Jul 2001 10:49:09 -0500" Content-Transfer-Encoding: 7bit Kireeti, My "votes" : 1. draft-dubuc-lmp-mib-02.txt - YES 2. draft-fontana-ccamp-gmpls-g709-00.txt - YES 3. draft-kompella-ospf-gmpls-extensions-02.txt - YES 4. draft-many-ccamp-gmpls-framework-00.txt - YES - as a co-author :-) 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - Wait and see 6. draft-many-ccamp-gmpls-routing-00.txt - YES Thanks, Ananth -----Original Message----- From: kireeti [mailto:kireeti@juniper.net] Sent: Friday, July 27, 2001 3:37 PM To: ccamp Cc: kireeti Subject: Drafts update Hi Folks, Can we get a sense of the consensus whether the following drafts should be made CCAMP WG documents? Please respond with (a) yes (b) no (c) wait 1. draft-dubuc-lmp-mib-02.txt 2. draft-fontana-ccamp-gmpls-g709-00.txt 3. draft-kompella-ospf-gmpls-extensions-02.txt 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt 6. draft-many-ccamp-gmpls-routing-00.txt (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this be a WG document, either in MPLS or CCAMP.) Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 08:17:18 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Andre Fredette'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Mon, 30 Jul 2001 11:14:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1190A.4F6D1200" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1190A.4F6D1200 Content-Type: text/plain; charset="iso-8859-1" Andre, 2 comments on you statistics, then a proposal to progress: 1. The stats are not that significant, since there was no "last call" period announced in advance to gauge community interest. 2. I do not think IETF uses company affiliation when measuring consensus. If it did, then the fact that 3 from Nortel are supporting NTIP, is an indication that there is an immediate need for NTIP given Nortel is a key player in this space. ------ All, Now to focus the discussion back on the OLI solutions (NTIP or LMP-WDM, or a merged version), - There is consensus on a single protocol which I respect. - Key distinctions between NTIP and WDM-LMP: 1. WDM-LMP assumes that LMP is a priority, people will implement LMP, hence WDM-LMP is a natural extension. The issues here are: (a) this assumption is not accurate, the functions of NTIP (or WDM-LMP) are more urgent than LMP (b) there is significant baggage to be carried from LMP down to the WDM-LMP 2. WDM-LMP assumes a peer model between the OXC and the WDM system. The issue: - this model doesn't reflect the reality that OXC and WDM are two different devices - the OXC-WDM relationship is client-server one. I suggest merging the two proposals as follows: - remove unnecessary LMP baggage - adopt a client-server model - allow for TCP as the transport - clarify a simplified autodiscovery mechanism Bilel. -----Original Message----- From: Andre Fredette [mailto: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_01C1190A.4F6D1200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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]<= /FONT>
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_01C1190A.4F6D1200-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 07:41:28 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D0220404032F3A26@mail1.tellium.com> From: Bala Rajagopalan To: Andre Fredette Cc: "'ccamp@ops.ietf.org'" Subject: Optical Link Interface - LMP-WDM comments Date: Mon, 30 Jul 2001 10:38:33 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11905.4F0CA366" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11905.4F0CA366 Content-Type: text/plain; charset="iso-8859-1" Andre: I'm attaching specific comments on LMP-WDM. Top level issues are as follows: 1. Layer mix-up: In some places, the WDM system is required to send information which is not native to OLS to the OXCs. In fact, this is very strange, because this information must originate from the OXC domain, get configured in WDM, and then go back to OXCs. This is a problem with OLI definition, not LMP-WDM itself. This requires some discussion and clean up. 2. Rather than tailoring the procedures for the particular requirements (OLI), the draft seems to be written with the goal of maximal reuse of LMP. This sometimes adds to the complexity of the proposal. Specifically, LMP-WDM has many "extensions" to LMP, giving the impression that LMP-WDM is a superset of LMP. I think there are differences in the situations where LMP is applied as compared to LMP-WDM and these aspects are not discussed sufficiently. I think a meticulous examination of the OLI requirements and LMP procedures is necessary to just carve out a set of procedures for OLI, rather than the superset approach. The maximal "re-use" argument doesn't make any sense on the WDM side where there is no LMP. Or, for that matter, where OXCs don't implement LMP. (This is where NTIP makes a good point). 3. I'm afraid the current LMP link verification definition (and as a corollary, LMP-WDM link verification) has only a marginal value considering the investment on hardware and protocol implementation. This is an area that requires more work. 4. Some of the procedures in the draft must be more explicitly described rather than saying that they are same as LMP's. As you noted, a more careful examination of LMP itself is in order. Regards, Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Andre Fredette [mailto:fredette@photonex.com] > Sent: Friday, July 27, 2001 11:02 AM > To: Bala Rajagopalan > Cc: 'ccamp@ops.ietf.org' > Subject: RE: Optical Link Interface - Correction > > > Bala, > > Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP > debate, though I > do know that you think the OLI is important and you care that > the solution > is a good one. I also agree (as I've stated before) that > either LMP-WDM or > NTIP could be made to work. I just believe that having the > group focus on > one protocol rather than two will have a better end result > and aid in wider > deployment. > > I'd also be glad to work on streamlining LMP-WDM. > > As I see it, the basic requirements are the same for both LMP > and OLI for > the following: > 1. Control Channel Maintenance (A.K.A. a light weight hello protocol). > 2. The ability to exchange information on links (link > summary, perhaps with > a few different TLVs) > 3. Discovery/Test. (Note: The main purpose here is for two > devices to agree > on ID's for each link so information exchange regarding > the links is > possible. The only reasonable way it is possible to > automate this, is to > send some type of test messages on the physical links). > To do this, > you need to be able > to terminate the links. > 4. Fault Notification (By the way, I think the ChannelStatus Message > defined in LMP-WDM > could replace the current ChannelFail Message in LMP) > 5. Notification whether a link is in use (ChannelActive Message). > > Because of this we have proposed basing the OLI on LMP. > > If these features need streamlining for LMP-WDM, they > probably also need > streamlining for LMP, so let's fix them once. > > If there are other LMP-WDM-specific procedures that need to > be streamlined, > I'm all ears. > > The major difference I see is that LMP needs is the ability > to manage link > bundles for the purpose of routing advertisements, but the > OLI doesn't. In > the LMP-WDM case, I was expecting we'd usually have a single > link bundle > (effectively ignoring this feature of LMP). > > Regarding the discovery portion of LMP (i.e., "link connectivity > verification"), from a protocol standpoint, it should work. It does > require that the PXC be able to terminate each port with an > appropriate > interface (from LMP: "For the LMP Test procedure, the free > (unallocated) > data-bearing links MUST be opaque (i.e., able to be > terminated)"). The PXC > would need to support termination of the various types of > ports that could > be used (e.g., SONET, SDH). But, this is more of a hardware > requirement > than a protocol requirement. > > Andre > > At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote: > > >Forgot to attach the new NTIP draft. > >Also, I meant "working on (4)", not (3). > > > > > >Bala Rajagopalan > >Tellium, Inc. > >2 Crescent Place > >P.O. Box 901 > >Oceanport, NJ 07757-0901 > >Tel: (732) 923-4237 > >Fax: (732) 923-9804 > >Email: braja@tellium.com > > > > > -----Original Message----- > > > From: Bala Rajagopalan > > > Sent: Friday, July 27, 2001 9:28 AM > > > To: 'Andre Fredette'; ccamp@ops.ietf.org > > > Subject: RE: Optical Link Interface > > > > > > > > > Andre: > > > > > > I believe you're counting me in the "agnostic" category. > > > I hope this is not taken as "don't care", since I > > > do have an interest in making a choice quickly. > > > > > > I have looked at the LMP-WDM draft (again) and the new > > > NTIP draft sent by Osama (attached). I see the following: > > > > > > 1. Both these solutions gloss over the details of > > > auto-discovery between OXCs and WDM. (Note: the > > > issues are the same regardless of the protocol used > > > and neither provides full details. Furthermore, > > > the hardware requirements and actions under both > > > are the same). > > > > > > 2. If we leave out (1), then the other functions are > > > based on messaging over the control channel > > > between the OXC and the WDM. This messaging > > > can be done one way or the other. > > > > > > 3. Both require control channel maintenance using > > > (simple) keepalive. > > > > > > 4. It seems LMP-WDM can be streamlined to make it > > > more lean and mean. > > > > > > Unless there is a significant technical issue > > > of one choice over the other, we have to consider > > > the fact that LMP-WDM has the first mover advantage. > > > Is it possible for > > > the NTIP proponents to seriously consider working on > > > (3)? Specifically, focus LMP-WDM on OLI requirements > > > only and not carry any unrelated LMP concepts into > > > LMP-WDM. Would this satisfy the design motivation for NTIP? > > > > > > Regards, > > > > > > Bala > > > > > > > > > Bala Rajagopalan > > > Tellium, Inc. > > > 2 Crescent Place > > > P.O. Box 901 > > > Oceanport, NJ 07757-0901 > > > Tel: (732) 923-4237 > > > Fax: (732) 923-9804 > > > Email: braja@tellium.com > > > > > > > -----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_000_01C11905.4F0CA366 Content-Type: application/msword; name="draft-fredette-lmp-wdm-01-comments.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-fredette-lmp-wdm-01-comments.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAHgEAAAAAAAAA EAAAIAEAAAEAAAD+////AAAAABsBAAAcAQAAHQEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAADSEBAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHt4BABZBAQAWQQEADR0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAMQAAAAAAAAAxAAAAMQA AAAAAAAAxAAAAAAAAADEAAAAAAAAAMQAAAAAAAAAxAAAABQAAAAAAAAAAAAAANgAAAAAAAAA2AAA AAAAAADYAAAAAAAAANgAAAAAAAAA2AAAACwAAAAEAQAALAIAANgAAAAAAAAAOzEAAPYAAADeAwAA AAAAAN4DAAAAAAAA3gMAAAAAAADeAwAAAAAAAN4DAAAAAAAA3gMAAAAAAADeAwAAAAAAAN4DAAAA AAAAADEAAAIAAAACMQAAAAAAAAIxAAAAAAAAAjEAAAAAAAACMQAAAAAAAAIxAAAAAAAAAjEAACQA AAAxMgAA9AEAACU0AAA+AAAAJjEAABUAAAAAAAAAAAAAAAAAAAAAAAAAxAAAAAAAAADeAwAAAAAA AAAAAAAAAAAAAAAAAAAAAADeAwAAAAAAAN4DAAAAAAAA3gMAAAAAAADeAwAAAAAAACYxAAAAAAAA nioAAAAAAADEAAAAAAAAAMQAAAAAAAAA3gMAAAAAAAAAAAAAAAAAAN4DAAAAAAAAvAMAACIAAACe KgAAAAAAAJ4qAAAAAAAAnioAAAAAAADeAwAAsg8AAMQAAAAAAAAA3gMAAAAAAADEAAAAAAAAAN4D AAAAAAAAADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAAAAAADYAAAAAAAAAMQAAAAAAAAAxAAA AAAAAADEAAAAAAAAAMQAAAAAAAAA3gMAAAAAAAAAMQAAAAAAAJ4qAACIBQAAnioAAAAAAAAmMAAA OgAAAMowAAAsAAAAxAAAAAAAAADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEAAAAAAADeAwAAAAAAADADAACMAAAAcCKyDpoY wQHYAAAAAAAAANgAAAAAAAAAkBMAAA4XAAD2MAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ1O ZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgIFMuIEJyb3Jzb24gKEF4aW93 YXZlIE5ldHdvcmtzKSANSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICBTLiBEaGFy YW5pa290YSAoTmF5bmEgTmV0d29ya3MsIEluYykgDUV4cGlyYXRpb24gRGF0ZTogSmFudWFyeSAy MDAxICAgICAgICAgICAgICAgSi4gRHJha2UgKENhbGllbnQgTmV0d29ya3MpIA0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBMLiBFZHdhcmRzIChpTGFtYmRhIE5ldHdv cmtzKSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEdveWFs IChBeGlvd2F2ZSBOZXR3b3JrcykgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBSLiBLcmlzaG5hbiAoQXhpb3dhdmUgTmV0d29ya3MpIA0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEouIFNoYW50aWdyYW0gKFBob3RvbkV4IENvcnAuKSANICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRS4gU255ZGVyIChQaG90 b25FeCBDb3JwLikgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR2Vv cmdlIFN3YWxsb3cgKENpc2NvIFN5c3RlbXMpIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEcuIFR1bXVsdXJpIChDYWxpZW50IE5ldHdvcmtzKSANICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWS4gWHVlIChVVU5FVC9Xb3JsZENv bSkgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEou IFl1IChaYWZmaXJlLCBJbmMpIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBFZGl0b3JzOiANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFuZHJlIEZyZWRldHRlIChQaG90b25FeCBDb3JwLikgDSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEpvbmF0aGFuIExhbmcgKENhbGllbnQgTmV0d29ya3MpIA0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKdWx5IDIwMDEgDSAgICANICAgICAgICBMaW5rIE1hbmFnZW1lbnQg UHJvdG9jb2wgKExNUCkgZm9yIFdETSBUcmFuc21pc3Npb24gU3lzdGVtcyANICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1m cmVkZXR0ZS1sbXAtd2RtLTAyLnR4dCANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANICAgIA1TdGF0dXMgb2YgdGhpcyBNZW1vIA0gICAgDSAgIFRoaXMgZG9jdW1lbnQgaXMg YW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCANICAgYWxs IHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2IFtSRkMyMDI2XS4gDSAgICANICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcgDSAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuIE5vdGUgdGhhdCANICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDSAgIERyYWZ0cy4gDSAgICANICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg DSAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIA0gICBhdCBhbnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtIERyYWZ0cyBhcyANICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDSAgICANICAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0gICBodHRwOi8v d3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQgDSAgICANICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANICAg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQ0NDQ0NDQ0NICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXSAN DA1JbnRlcm5ldCBEcmFmdCAgICAgICBkcmFmdC1tYW55LW9saS1yZXF0cy0wMC50eHQgICAgICAg ICAgICBKdWx5IDIwMDEgDSANQUJTVFJBQ1QgDSAgIEEgc3VpdGUgb2YgcHJvdG9jb2xzIGlzIGJl aW5nIGRldmVsb3BlZCBpbiB0aGUgSUVURiB0byBhbGxvdyANICAgbmV0d29ya3MgY29uc2lzdGlu ZyBvZiBwaG90b25pYyBzd2l0Y2hlcyAoUFhDcyksIG9wdGljYWwgDSAgIGNyb3NzY29ubmVjdHMg KE9YQ3MpLCByb3V0ZXJzLCBzd2l0Y2hlcywgRFdETSB0cmFuc21pc3Npb24gc3lzdGVtcywgDSAg IGFuZCBvcHRpY2FsIGFkZC1kcm9wIG11bHRpcGxleG9ycyAoT0FETXMpIHRvIHVzZSBhbiBNUExT LWJhc2VkIA0gICBjb250cm9sIHBsYW5lIHRvIGR5bmFtaWNhbGx5IHByb3Zpc2lvbiByZXNvdXJj ZXMgYW5kIHRvIHByb3ZpZGUgDSAgIG5ldHdvcmsgc3Vydml2YWJpbGl0eSB1c2luZyBwcm90ZWN0 aW9uIGFuZCByZXN0b3JhdGlvbiB0ZWNobmlxdWVzLiAgDSAgIEFzIHBhcnQgb2YgdGhpcyBwcm90 b2NvbCBzdWl0ZSwgdGhlIExpbmsgTWFuYWdlbWVudCBQcm90b2NvbCAoTE1QKSANICAgW0xNUF0g aXMgZGVmaW5lZCB0byAibWFpbnRhaW4gY29udHJvbCBjaGFubmVsIGNvbm5lY3Rpdml0eSwgdmVy aWZ5IA0gICBjb21wb25lbnQgbGluayBjb25uZWN0aXZpdHksIGFuZCBpc29sYXRlIGxpbmssIGZp YmVyLCBvciBjaGFubmVsIA0gICBmYWlsdXJlcyB3aXRoaW4gdGhlIG5ldHdvcmsuIiAgSW4gaXQn cyBwcmVzZW50IGZvcm0sIFtMTVBdIGZvY3VzZXMgDSAgIG9uIHBlZXIgY29tbXVuaWNhdGlvbnMg KGVnLiBPWEMtdG8tT1hDKS4gIEluIHRoaXMgZG9jdW1lbnQgd2UgDSAgIHByb3Bvc2UgZXh0ZW5z aW9ucyB0byBMTVAgZm9yIHVzZSB3aXRoIERXRE0gdHJhbnNtaXNzaW9uIHN5c3RlbXMuICANICAg VGhlc2UgZXh0ZW5zaW9ucyBhcmUgaW50ZW5kZWQgdG8gc2F0aXNmeSB0aGUgIk9wdGljYWwgTGlu ayBJbnRlcmZhY2UgDSAgIFJlcXVpcmVtZW50cyIgZGVzY3JpYmVkIGluIFtPTEldLiANIA1DT05U RU5UUyANMS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjMgDTIuIExNUCBFeHRlbnNpb25zIGZvciBXRE0gVHJhbnNwb3J0 IFN5c3RlbXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0yLjEuIENvbnRyb2wgQ2hhbm5l bCBNYW5hZ2VtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANMi4y LiBMaW5rIFZlcmlmaWNhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjYgDTIuMy4gTGluayBTdW1tYXJpemF0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0yLjMuMS4gTGluayBHcm91cCBJRC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANMi4zLjIuIExpbmsg RGVzY3JpcHRvci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjggDTIuMy4zLiBTaGFyZWQgUmlzayBMaW5rIEdyb3VwIElkZW50aWZpZXIgKFNSTEcpOi4uLi4u Li4uLi4uLi4uLi4uLi4uLjEwIA0yLjMuNC4gV2F2ZWxlbmd0aC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANMi4zLjUuIEJpdCBFcnJvciBSYXRl IChCRVIpIEVzdGltYXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEgDTIuMy42 LiBPcHRpY2FsIFByb3RlY3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjExIA0yLjMuNy4gU3BhbiBMZW5ndGg6Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANMi4zLjguIEFkbWluaXN0cmF0aXZlIEdyb3VwIChD b2xvcikuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDTIuNC4gRmF1bHQgTWFu YWdlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEz IA0yLjQuMS4gQ2hhbm5lbFN0YXR1cyBNZXNzYWdlIChNc2dUeXBlID0gVEJEKS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNCANMi40LjEuMS4gQ2hhbm5lbCBTdGF0dXMgVExWLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUgDTIuNC4xLjIuIEdyb3VwIFN0YXR1cyBU TFYuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IA0yLjQuMi4g Q2hhbm5lbFN0YXR1c0FjayBNZXNzYWdlIChNc2dUeXBlID0gVEJEKS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xNyANMi40LjMuIENoYW5uZWxTdGF0dXNSZXEgTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCku Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTggDTIuNC4zLjEuIENoYW5uZWwgRW50aXR5IFRMVi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4IA0yLjQuMy4yLiBHcm91cCBF bnRpdHkgVExWLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOSAN Mi41LiBUcmFjZSBNb25pdG9yaW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTkgDTIuNS4xLiBUcmFjZU1vbml0b3IgTWVzc2FnZSAoTXNnVHlwZSA9IFRC RCkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5IA0yLjUuMS4xLiBTT05FVCBTZWN0aW9uIFRy YWNlIFRMVi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMCANMi41LjEuMi4g VHJhY2UgVExWLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMjEgDTIuNS4yLiBUcmFjZU1vbml0b3JBY2sgTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCkuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjIyIA0yLjUuMy4gVHJhY2VNb25pdG9yTmFjayBNZXNzYWdlIChN c2dUeXBlID0gVEJEKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMiANMi41LjQuIFRyYWNlTWlzbWF0 Y2ggTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjMgDTIu NS41LiBUcmFjZU1pc21hdGNoQWNrIE1lc3NhZ2UgKE1zZ1R5cGUgPSBUQkQpLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjI0IA0yLjUuNi4gVHJhY2VSZXEgTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCkuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNSANMi41LjcuIFRyYWNlUmVwb3J0IE1lc3NhZ2Ug KE1zZ1R5cGUgPSBUQkQpLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjUgDTMuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjI2IA00LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4yNyANNS4gQXV0aG9yJ3MgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjggDQ0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdIA0MDUlu dGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAgICAgICAgICAg IEp1bHkgMjAwMSANIA0gICAgDSAgICANMS4gSW50cm9kdWN0aW9uIA0gICAgDSAgIEZ1dHVyZSBu ZXR3b3JrcyB3aWxsIGNvbnNpc3Qgb2YgcGhvdG9uaWMgc3dpdGNoZXMgKFBYQ3MpLCBvcHRpY2Fs IA0gICBjcm9zc2Nvbm5lY3RzIChPWENzKSwgcm91dGVycywgc3dpdGNoZXMsIERXRE0gdHJhbnNt aXNzaW9uIHN5c3RlbXMsIA0gICBhbmQgb3B0aWNhbCBhZGQtZHJvcCBtdWx0aXBsZXhvcnMgKE9B RE1zKSB0aGF0IHVzZSB0aGUgR01QTFMgY29udHJvbCANICAgcGxhbmUgdG8gZHluYW1pY2FsbHkg cHJvdmlzaW9uIHJlc291cmNlcyBhbmQgdG8gcHJvdmlkZSBuZXR3b3JrIA0gICBzdXJ2aXZhYmls aXR5IHVzaW5nIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIHRlY2huaXF1ZXMuICBBIHBhaXIg DSAgIG9mIG5vZGVzIChlLmcuLCBhIFBYQyBhbmQgYSBEV0RNIHN5c3RlbSkgbWF5IGJlIGNvbm5l Y3RlZCBieSANICAgdGhvdXNhbmRzIG9mIGZpYmVycy4gRnVydGhlcm1vcmUsIG11bHRpcGxlIGZp YmVycyBhbmQvb3IgbXVsdGlwbGUgDSAgIHdhdmVsZW5ndGhzIG1heSBiZSBjb21iaW5lZCBpbnRv IGEgc2luZ2xlIGJ1bmRsZWQgbGluay4gIFtMTVBdIA0gICBEZWZpbmVzIHRoZSBMaW5rIE1hbmFn ZW1lbnQgUHJvdG9jb2wgKExNUCkgdG8gIm1haW50YWluIGNvbnRyb2wgDSAgIGNoYW5uZWwgY29u bmVjdGl2aXR5LCB2ZXJpZnkgY29tcG9uZW50IGxpbmsgY29ubmVjdGl2aXR5LCBhbmQgDSAgIGlz b2xhdGUgbGluaywgZmliZXIsIG9yIGNoYW5uZWwgZmFpbHVyZXMgd2l0aGluIHRoZSBuZXR3b3Jr LiIgIEluIA0gICBpdCdzIHByZXNlbnQgZm9ybSwgW0xNUF0gZm9jdXNlcyBvbiBwZWVyIGNvbW11 bmljYXRpb25zIChlZy4gIE9YQy0NICAgdG8tT1hDKSBhcyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUg MS4gIEluIHRoaXMgZG9jdW1lbnQsIGV4dGVuc2lvbnMgdG8gDSAgIExNUCBmb3IgdXNlIHdpdGgg RFdETSB0cmFuc21pc3Npb24gc3lzdGVtcyBhcmUgcHJvcG9zZWQuICBUaGVzZSANICAgZXh0ZW5z aW9ucyBhcmUgaW50ZW5kZWQgdG8gc2F0aXNmeSB0aGUgIk9wdGljYWwgTGluayBJbnRlcmZhY2Ug DSAgIFJlcXVpcmVtZW50cyIgZGVzY3JpYmVkIGluIFtPTEldLiAgSXQgaXMgYXNzdW1lZCB0aGF0 IHRoZSByZWFkZXIgaXMgDSAgIGZhbWlsaWFyIHdpdGggTE1QIGFzIGRlZmluZWQgaW4gW0xNUF0u IA0gICAgDSAgICANICAgICAgICAgICAgKy0tLS0tLSsgICAgICAgKy0tLS0tLSsgICAgICAgKy0t LS0tLSsgICAgICAgKy0tLS0tLSsgDSAgICAgICAgICAgIHwgICAgICB8IC0tLS0tIHwgICAgICB8 ICAgICAgIHwgICAgICB8IC0tLS0tIHwgICAgICB8IA0gICAgICAgICAgICB8IE9YQzEgfCAtLS0t LSB8IFdETTEgfCA9PT09PSB8IFdETTIgfCAtLS0tLSB8IE9YQzIgfCANICAgICAgICAgICAgfCAg ICAgIHwgLS0tLS0gfCAgICAgIHwgICAgICAgfCAgICAgIHwgLS0tLS0gfCAgICAgIHwgDSAgICAg ICAgICAgICstLS0tLS0rICAgICAgICstLS0tLS0rICAgICAgICstLS0tLS0rICAgICAgICstLS0t LS0rIA0gICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIF4gICAgDSAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICANICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLUxNUC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICANICAgIA0gICAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUgMTogQ3VycmVudCBMTVAgTW9kZWwgDSAgICANICAgIA0gICBBIGdyZWF0 IGRlYWwgb2YgaW5mb3JtYXRpb24gYWJvdXQgYSBsaW5rIGJldHdlZW4gdHdvIE9YQ3MgaXMga25v d24gDSAgIGJ5IHRoZSBEV0RNIHRyYW5zbWlzc2lvbiBzeXN0ZW0uICBFeHBvc2luZyB0aGlzIGlu Zm9ybWF0aW9uIHRvIHRoZSANICAgY29udHJvbCBwbGFuZSB2aWEgTE1QIGNhbiBpbXByb3ZlIG5l dHdvcmsgdXNhYmlsaXR5IGJ5IGZ1cnRoZXIgDSAgIHJlZHVjaW5nIHJlcXVpcmVkIG1hbnVhbCBj b25maWd1cmF0aW9uIGFuZCBhbHNvIGdyZWF0bHkgZW5oYW5jaW5nIA0gICBmYXVsdCBkZXRlY3Rp b24gYW5kIHJlY292ZXJ5LiAgRmF1bHQgZGV0ZWN0aW9uIGlzIHBhcnRpY3VsYXJseSBhbiANICAg aXNzdWUgd2hlbiB0aGUgbmV0d29yayBpcyB1c2luZyBhbGwtb3B0aWNhbCBwaG90b25pYyBzd2l0 Y2hlcyAoUFhDKS4gDSAgIE9uY2UgYSBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkLCBQWENzIGhh dmUgb25seSBsaW1pdGVkIHZpc2liaWxpdHkgDSAgIGludG8gdGhlIGhlYWx0aCBvZiB0aGUgY29u bmVjdGlvbi4gIEV2ZW4gdGhvdWdoIHRoZSBQWEMgaXMgYWxsLQ0gICBvcHRpY2FsLCBsb25nLWhh dWwgRFdETSB0cmFuc21pc3Npb24gc3lzdGVtcyB0eXBpY2FsbHkgdGVybWluYXRlIA0gICBjaGFu bmVscyBlbGVjdHJpY2FsbHkgYW5kIHJlZ2VuZXJhdGUgdGhlbSBvcHRpY2FsbHksIHdoaWNoIHBy ZXNlbnRzIA0gICBhbiBvcHBvcnR1bml0eSB0byBtb25pdG9yIHRoZSBoZWFsdGggb2YgYSBjaGFu bmVsIGJldHdlZW4gUFhDcy4gIFRoZSANICAgbW9kZWwgZm9yIGV4dGVuZGluZyBMTVAgdG8gV0RN IHRyYW5zbWlzc2lvbiBzeXN0ZW1zIGlzIHNob3duIGluIA0gICBGaWd1cmUgMi4gDQ0NDQ0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDNdIA0MDUludGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAw LnR4dCAgICAgICAgICAgIEp1bHkgMjAwMSANIA0gICAgDSAgICANICAgICAgICAgICAgKy0tLS0t LSsgICAgICAgKy0tLS0tLSsgICAgICAgKy0tLS0tLSsgICAgICAgKy0tLS0tLSsgDSAgICAgICAg ICAgIHwgICAgICB8IC0tLS0tIHwgICAgICB8ICAgICAgIHwgICAgICB8IC0tLS0tIHwgICAgICB8 IA0gICAgICAgICAgICB8IE9YQzEgfCAtLS0tLSB8IFdETTEgfCA9PT09PSB8IFdETTIgfCAtLS0t LSB8IE9YQzIgfCANICAgICAgICAgICAgfCAgICAgIHwgLS0tLS0gfCAgICAgIHwgICAgICAgfCAg ICAgIHwgLS0tLS0gfCAgICAgIHwgDSAgICAgICAgICAgICstLS0tLS0rICAgICAgICstLS0tLS0r ICAgICAgICstLS0tLS0rICAgICAgICstLS0tLS0rIA0gICAgICAgICAgICAgIF4gIF4gICAgICAg ICAgICAgXiAgICAgICAgICAgICAgXiAgICAgICAgICAgIF4gIF4gICAgDSAgICAgICAgICAgICAg fCAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgfCAgICANICAg ICAgICAgICAgICB8ICArLS0tLS1MTVAtLS0tLSsgICAgICAgICAgICAgICstLS0tLUxNUC0tLS0r ICB8IA0gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgDSAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS1MTVAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgDSAgICANICAgICAgICAgICAgICAgICAgICAgICBGaWd1 cmUgMjogRXh0ZW5kZWQgTE1QIE1vZGVsICANICAgIA0gICAgDSAgIEluIHRoaXMgbW9kZWwsIGFu IE9YQyBtYXkgaGF2ZSBtdWx0aXBsZSBMTVAgc2Vzc2lvbnMgY29ycmVzcG9uZGluZyANICAgdG8g bXVsdGlwbGUgcGVlcmluZyByZWxhdGlvbnNoaXBzLiAgQXQgZWFjaCBsZXZlbCwgTE1QIHByb3Zp ZGVzIGxpbmsgDSAgIG1hbmFnZW1lbnQgZnVuY3Rpb25hbGl0eSAoaS5lLiwgY29udHJvbCBjaGFu bmVsIG1hbmFnZW1lbnQsIHBoeXNpY2FsIA0gICBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLCBs aW5rIHByb3BlcnR5IGNvcnJlbGF0aW9uKSBmb3IgdGhhdCANICAgcGVlcmluZyByZWxhdGlvbnNo aXAuICBGb3IgZXhhbXBsZSwgdGhlIE9YQy1PWEMgTE1QIHNlc3Npb25zIGluIA0gICBGaWd1cmUg MiBhcmUgdXNlZCB0byBidWlsZCB0cmFmZmljLWVuZ2luZWVyaW5nIChURSkgbGlua3MgZm9yIEdN UExTIA0gICBzaWduYWxpbmcgYW5kIHJvdXRpbmcsIGFuZCBhcmUgbWFuYWdlZCBhcyBkZXNjcmli ZWQgaW4gW0xNUF0uIEF0IHRoZSANICAgdHJhbnNwb3J0IGxldmVsLCB0aGUgT1hDLVdETSBMTVAg c2Vzc2lvbiAoc2hvd24gaW4gRmlndXJlIDIpIGlzIHVzZWQgDSAgIHRvIGF1Z21lbnQga25vd2xl ZGdlIGFib3V0IHRoZSBsaW5rcyBiZXR3ZWVuIHRoZSBPWENzLiAgVGhlIA0gICBtYW5hZ2VtZW50 IG9mIHRoZXNlIExNUCBzZXNzaW9ucyBpcyBkaXNjdXNzZWQgaW4gdGhpcyBkcmFmdC4gSXQgaXMg DSAgIGltcG9ydGFudCB0byBub3RlIHRoZSBhbiBPWEMgbWF5IHBlZXIgd2l0aCBvbmUgb3IgbW9y ZSBPTFOScyBhbmQgYW4gDSAgIE9MUyBtYXkgcGVlciB3aXRoIG9uZSBvciBtb3JlIE9YQ5JzLiAN ICAgIA0gICBBbHRob3VnaCB0aGVyZSBhcmUgbWFueSBzaW1pbGFyaXRpZXMgYmV0d2VlbiBhbiBP WEMtT1hDIExNUCBzZXNzaW9uIA0gICBhbmQgYW4gT1hDLVdETSBMTVAgc2Vzc2lvbiwgcGFydGlj dWxhcmx5IGZvciBjb250cm9sIG1hbmFnZW1lbnQgYW5kIA0gICBsaW5rIHZlcmlmaWNhdGlvbiwg dGhlcmUgYXJlIHNvbWUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYXMgd2VsbC4gDSAgIFRoZXNl IGRpZmZlcmVuY2VzIGNhbiBwcmltYXJpbHkgYmUgYXR0cmlidXRlZCB0byB0aGUgbmF0dXJlIG9m IGFuIA0gICBPWEMtV0RNIGxpbmssIGFuZCB0aGUgcHVycG9zZSBvZiBPWEMtV0RNIExNUCBzZXNz aW9ucy4gIEFzIA0gICBwcmV2aW91c2x5IG1lbnRpb25lZCwgdGhlIE9YQy1PWEMgbGlua3MgcHJv dmlkZSB0aGUgYmFzaXMgZm9yIEdNUExTIA0gICBzaWduYWxpbmcgYW5kIHJvdXRpbmcgYXQgdGhl IG9wdGljYWwgbGF5ZXIuICBUaGUgaW5mb3JtYXRpb24gDSAgIGV4Y2hhbmdlZCBvdmVyIExNUC1X RE0gc2Vzc2lvbnMgaXMgdXNlZCB0byBhdWdtZW50IGtub3dsZWRnZSBhYm91dCANICAgdGhlIGxp bmtzIGJldHdlZW4gT1hDcy4gIA0gICAgDVRoZXJlIGlzIGEgbG90IG9mIGZvY3VzIG9uICJnZXR0 aW5nIGFkZGl0aW9uYWwga25vd2xlZGdlIiBvZiBsaW5rcywgYnV0IGxpdHRsZSBvbiBpbnRlcmFj dGlvbiBiZXR3ZWVuIFdETSBhbmQgT1hDIGZvciBwcm92aXNpb25pbmcgJiBtYW5hZ2VtZW50IHB1 cnBvc2VzIChlLmcuLCBzdXBwcmVzc2luZyBhbGFybXMvdHJhY2UgbW9uaXRvcmluZy9ldGMpLiBJ biBmYWN0LCBJIGJlbGlldmUgdGhlc2UgbGF0dGVyIGZ1bmN0aW9ucyBhcmUgbW9yZSBpbXBvcnRh bnQgYXBwbGljYXRpb25zIGZvciBPTEkgdGhhbiBnZXR0aW5nIGxpbmsgaW5mb3JtYXRpb24uIFlv dSBtaWdodCB3YW50IHRvIGdpdmUgYSBiZXR0ZXIgcGVyc3BlY3RpdmUgb2YgdGhlIHByb3Zpc2lv bmluZyBhbmQgbWFuYWdlbWVudCBwcm9ibGVtIGhlcmUgYW5kIGV4cGxhaW4gaG93IExNUC1XRE0g aGVscHMuDQ0gICBJbiBvcmRlciBmb3IgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBvdmVyIHRo ZSBPWEMtV0RNIExNUCBzZXNzaW9ucyANICAgdG8gYmUgdXNlZCBieSB0aGUgT1hDLU9YQyBzZXNz aW9uLCB0aGUgaW5mb3JtYXRpb24gbXVzdCBiZSANICAgY29vcmRpbmF0ZWQgYnkgdGhlIE9YQy4g IEhvd2V2ZXIsIHRoZSB0d28gTE1QIHNlc3Npb25zIGFyZSBydW4gDSAgIGluZGVwZW5kZW50bHkg YW5kIE1VU1QgYmUgbWFpbnRhaW5lZCBzZXBhcmF0ZWx5LiAgT25lIGNyaXRpY2FsIA0gICByZXF1 aXJlbWVudCB3aGVuIHJ1bm5pbmcgYW4gT1hDLVdETSBMTVAgc2Vzc2lvbiBpcyB0aGUgYWJpbGl0 eSBvZiANICAgdGhlIFdETSB0byBtYWtlIGEgZGF0YS1iZWFyaW5nIGxpbmsgdHJhbnNwYXJlbnQg d2hlbiBub3QgZG9pbmcgdGhlIA0gICB2ZXJpZmljYXRpb24gcHJvY2VkdXJlLiAgVGhpcyBpcyBi ZWNhdXNlIHRoZSBzYW1lIGRhdGEtYmVhcmluZyBsaW5rIA0gICBtYXkgYmUgdmVyaWZpZWQgYmV0 d2VlbiBPWEMtV0RNIGFuZCBiZXR3ZWVuIE9YQy1PWEMuICBDdXJyZW50bHksIHRoZSANICAgQmVn aW5WZXJpZnkgcHJvY2VkdXJlIGlzIHVzZWQgdG8gY29vcmRpbmF0ZSB0aGUgVGVzdCBwcm9jZWR1 cmUgKGFuZCANICAgaGVuY2UgdGhlIHRyYW5zcGFyZW5jeS9vcGFxdWVuZXNzIG9mIHRoZSBkYXRh LWJlYXJpbmcgbGlua3MpIGFzIA0gICBkZXNjcmliZWQgaW4gW0xNUF0uIA0NVGhpcyBhc3N1bWVz IHRoYXQgdGhlIHNhbWUgb3ZlcmhlYWQgYnl0ZXMgbWF5IGJlIHVzZWQgZm9yIExNUCBhbmQgTE1Q LVdETS4gV2h5IHNob3VsZCB0aGlzIGJlIHRoZSBjYXNlPyBJbiBmYWN0LCBpdCBzaG91bGQgYmUg Y29uc2lkZXJlZCB3aGV0aGVyIHNlcGFyYXRlIHNldCBvZiBPSCBieXRlcyBiZSBtYW5kYXRlZCBm b3IgdGhlc2UgcHVycG9zZXMuDSAgICANDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQwNSW50ZXJuZXQgRHJhZnQg ICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAgICAgICAgSnVseSAyMDAxIA0g DSAgIFRvIG1haW50YWluIGluZGVwZW5kZW5jZSBiZXR3ZWVuIHRoZSBzZXNzaW9ucywgaXQgTVVT VCBiZSBwb3NzaWJsZSANICAgZm9yIHRoZSBMTVAgc2Vzc2lvbnMgdG8gY29tZSB1cCBpbiBhbnkg b3JkZXIuICBJbiBwYXJ0aWN1bGFyLCBpdCANICAgTVVTVCBiZSBwb3NzaWJsZSBmb3IgYW4gT1hD LU9YQyBMTVAgc2Vzc2lvbiB0byBjb21lIHVwIHdpdGhvdXQgYW4gDSAgIE9YQy1XRE0gTE1QIHNl c3Npb24gYmVpbmcgYnJvdWdodCB1cCwgYW5kIHZpY2UtdmVyc2EuIA0NSSB3b3VsZCBzdGF0ZSB0 aGlzIGV2ZW4gc3Ryb25nZXIuIFRoZXJlIHNob3VsZCBiZSBubyBhc3N1bXB0aW9ucyBvbiB3aGV0 aGVyIGV2ZW4gKHJlZ3VsYXIpIExNUCBpcyBydW5uaW5nIGJldHdlZW4gT1hDcy4gSXNuJ3QgaXQg dGhlIGNhc2UgdGhhdCBldmVuIEdNUExTIGlzIG5vdCBtYW5kYXRlZCB0byB1c2UgT0xJPyBJIHdv dWxkIGNvbXBsZXRlbHkgZGVjb3VwbGUgTE1QIGZyb20gTE1QLVdETSAob3RoZXIgdGhhbiBvZiBj b3Vyc2UgZm9yIHJldXNpbmcgTE1QIGRlc2lnbiBhbmQgbWVzc2FnZSBwYXJhZGlnbXMgaW4gTE1Q LVdETSkuIA0gICAgDSAgIFRoaXMgZHJhZnQgZm9jdXNlcyBvbiBleHRlbnNpb25zIHJlcXVpcmVk IGZvciB1c2Ugd2l0aCBvcGFxdWUgDSAgIHRyYW5zbWlzc2lvbiBzeXN0ZW1zLiAgV29yayBpcyBv bmdvaW5nIGluIHRoZSBhcmVhIG9mIGNvbXBsZXRlbHkgDSAgIHRyYW5zcGFyZW50IHdhdmVsZW5n dGggcm91dGluZzsgaG93ZXZlciwgaXQgaXMgcHJlbWF0dXJlIHRvIGlkZW50aWZ5IA0gICB0aGUg bmVjZXNzYXJ5IGNoYXJhY3RlcmlzdGljcyB0byBhZHZlcnRpc2UuICBUaGF0IHNhaWQsIHRoZSBw cm90b2NvbCANICAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIG5lY2Vz c2FyeSBmcmFtZXdvcmsgaW4gd2hpY2ggDSAgIHRvIGFkdmVydGlzZSBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGFzIGl0IGlzIGRlZW1lZCBhcHByb3ByaWF0ZS4gDSAgICANICAgQWRkaXRpb25hbCBk ZXRhaWxzIGFib3V0IHRoZSBleHRlbnNpb25zIHJlcXVpcmVkIGZvciBMTVAgYXJlIA0gICBvdXRs aW5lZCBpbiB0aGUgbmV4dCBzZWN0aW9uLiANDQ0gICAgDTIuIExNUCBFeHRlbnNpb25zIGZvciBX RE0gVHJhbnNwb3J0IFN5c3RlbXMgDSAgICANICAgQXMgY3VycmVudGx5IGRlZmluZWQsIExNUCBj b25zaXN0cyBvZiBmb3VyIHR5cGVzIG9mIGZ1bmN0aW9uczogDSAgICANICAgICAxLiBDb250cm9s IENoYW5uZWwgTWFuYWdlbWVudCANICAgICAyLiBMaW5rIFZlcmlmaWNhdGlvbiANICAgICAzLiBM aW5rIFN1bW1hcml6YXRpb24gDSAgICAgNC4gRmF1bHQgTG9jYWxpemF0aW9uIA0gICAgDSAgICAN ICAgSXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCB0aGUgc3VidGxlIGRpc3RpbmN0 aW9ucyBiZXR3ZWVuIA0gICB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIGxpbmtzIGJlaW5nIGNvbnNp ZGVyZWQgaW4gdGhlIGV4dGVuZGVkIExNUC0NICAgV0RNLiAgRm9yIGV4YW1wbGUsIGluIEZpZ3Vy ZSAyIHdoZW4gT1hDMSBhbmQgT1hDMiBjb21wbGV0ZSB0aGUgDSAgIHZlcmlmeSBwcm9jZXNzLCB0 aGUgbGlua3MgYmVpbmcgdmVyaWZpZWQgYXJlIHRoZSBlbmQtdG8tZW5kIGxpbmtzIA0gICBiZXR3 ZWVuIHRoZSBPWEMncy4gIEl0IGlzIHRoZSBURSBsaW5rIGNvbXBvc2VkIG9mIHRoZXNlICJwb3J0 cyIgb3IgDSAgICJjb21wb25lbnQgbGlua3MiIHRoYXQgYXJlIGFkdmVydGlzZWQgaW4gdGhlIHJv dXRpbmcgcHJvdG9jb2xzIGFuZCANICAgdXNlZCBmb3IgdGhlIHB1cnBvc2VzIG9mIGNvbm5lY3Rp b24gc2V0dXAuICBUaGUgdmVyaWZ5IHByb2NlZHVyZSANICAgYmV0d2VlbiBPWEMxIGFuZCBXRE0x LCBvbiB0aGUgb3RoZXIgaGFuZCB2ZXJpZmllcyB0aGUgc2hvcnRlciBsaW5rIA0gICBiZXR3ZWVu IHRoZXNlIHR3byBub2Rlcy4gIEhvd2V2ZXIsIGVhY2ggb2YgdGhlc2Ugc2hvcnRlciBsaW5rcyBp cyBhIA0gICBzZWdtZW50IG9mIG9uZSBvZiB0aGUgbGFyZ2VyIGVuZC10by1lbmQgbGlua3MuICBU aGUgdmVyaWZ5IHNlcnZlcyANICAgdHdvIGZ1bmN0aW9uczogdG8gdmVyaWZ5IGNvbm5lY3Rpdml0 eSBhbmQgZXhjaGFuZ2UgaGFuZGxlcyBieSB3aGljaCANICAgZWFjaCBwb3J0IG9yIGNvbXBvbmVu dCBsaW5rIGlzIHJlZmVycmVkLiAgRnVydGhlcm1vcmUsIGl0IGlzIHVwIHRvIA0gICB0aGUgT1hD IHRvIGNvcnJlbGF0ZSB0aGUgaGFuZGxlcyBiZXR3ZWVuIHRoZSB2YXJpb3VzIExNUCBzZXNzaW9u cy4gDSAgICANICAgT25jZSBhIGNvbnRyb2wgY2hhbm5lbCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBh bmQgdGhlIE9YQy1XRE0gDSAgIHZlcmlmaWNhdGlvbiBwcm9jZWR1cmUgaGFzIGJlZW4gY29tcGxl dGVkIHN1Y2Nlc3NmdWxseSwgdGhlIE9YQyBhbmQgDSAgIFdETSB0cmFuc21pc3Npb24gc3lzdGVt IG1heSBleGNoYW5nZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgbGluayANICAgY29uZmlndXJhdGlv biAobGluayBzdW1tYXJpemF0aW9uKS4gIEFuIE9YQyBtYXkgYWxzbyByZWNlaXZlIA0gICBub3Rp ZmljYXRpb24gZnJvbSBhIFdETSB0cmFuc21pc3Npb24gc3lzdGVtIChmYXVsdCBub3RpZmljYXRp b24pLiANICAgIA0gICBJbiBzdWJzZXF1ZW50IHNlY3Rpb25zLCBzcGVjaWZpYyBjaGFuZ2VzIGFy ZSBwcm9wb3NlZCB0byBleHRlbmQgTE1QIA0gICB0byB3b3JrIHdpdGggV0RNIHRyYW5zbWlzc2lv biBzeXN0ZW1zLiANICAgIA0yLjEuIENvbnRyb2wgQ2hhbm5lbCBNYW5hZ2VtZW50IA0gICAgDQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA1XSANDA1JbnRlcm5ldCBEcmFmdCAgICAgICBkcmFmdC1tYW55LW9saS1yZXF0 cy0wMC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANICAgQXMgaW4gW0xNUF0sIHdlIGRvIG5v dCBzcGVjaWZ5IHRoZSBleGFjdCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgDSAgIGNvbnRyb2wgY2hh bm5lbDsgaXQgY291bGQgYmUsIGZvciBleGFtcGxlLCBhIHNlcGFyYXRlIHdhdmVsZW5ndGggb3Ig DSAgIGZpYmVyLCBhbiBFdGhlcm5ldCBsaW5rLCBhbiBJUCB0dW5uZWwgdGhyb3VnaCBhIHNlcGFy YXRlIG1hbmFnZW1lbnQgDSAgIG5ldHdvcmssIG9yIHRoZSBvdmVyaGVhZCBieXRlcyBvZiBhIGRh dGEtYmVhcmluZyBsaW5rLiANDUZvciBhbnkgb2YgdGhlIGluLWJhbmQgbWVjaGFuaXNtcyAod2F2 ZWxlbmd0aCwgT0ggYnl0ZXMsIGV0YyksIG1vcmUgc3BlY2lmaWNhdGlvbiBpcyBuZWVkZWQuIEku ZS4sIGl0IGhhcyB0byBiZSBzcGVjaWZpZWQgd2hpY2ggd2F2ZWxlbmd0aCBvciBPSCBieXRlcyBz aG91bGQgYmUgdXNlZC4gSWYgdGhpcyBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQs IHJlZmVyIHRvIGEgcGxhY2Ugd2hlcmUgaXQgaXMgKG9yIHdpbGwgYmUpIHNwZWNpZmllZC4gKE90 aGVyd2lzZSwgdGhlcmUgaXMgbm8gaW50ZXJvcGVyYWJpbGl0eS4pIEFsc28sIEknbSBub3QgZXZl biBzdXJlIGlmIE9IIGJ5dGVzIGluIGEgImRhdGEgYmVhcmluZyBsaW5rIiBjYW4gYmUgdXNlZCwg c2luY2UgdGhlIE9YQyBjb3VsZCBiZSB0cmFuc3BhcmVudCAodGhlIG1haW4gY2FuZGlkYXRlIGNh c2UgZm9yIE9MSSkuDSAgICANICAgVGhlIGNvbnRyb2wgY2hhbm5lbCBtYW5hZ2VtZW50IGZvciBP WEMtV0RNIGxpbmtzIGlzIHRoZSBzYW1lIGFzIGZvciANICAgT1hDLU9YQyBsaW5rcywgYXMgZGVz Y3JpYmVkIGluIFtMTVBdLiAgVGhlIExNUCBDYXBhYmlsaXR5IFRMViANICAgaW5jbHVkZXMgYSBm bGFnIGluZGljYXRpbmcgc3VwcG9ydCBvZiBhbiBPWEMtV0RNIExNUCBzZXNzaW9uIGFzIA0gICBk ZXNjcmliZWQgaW4gdGhpcyAgZHJhZnQuICBGdXJ0aGVybW9yZSwgYSBmbGFnIGhhcyBiZWVuIGFk ZGVkIHRvIHRoZSANICAgTE1QIENvbW1vbiBIZWFkZXIgdG8gaWRlbnRpZnkgdGhlIHRyYW5zbWl0 dGluZyBub2RlIGFzIGEgRFdETSANICAgc3lzdGVtLiANDVRoaXMgZGVzY3JpcHRpb24gbmVlZHMg dG8gYmUgZXhwYW5kZWQuIFNwZWNpZmljYWxseSwgDXdoYXQgZG9lcyB0aGUgTE1QLVdETSBjb21t b24gaGVhZGVyIGxvb2sgbGlrZT8gSW4gcGFydGljdWxhciwgd2hhdCdzIHRoZSBzZW1hbnRpY3Mg b2YgdGhlICJMb2NhbCBDQ0lEL1RFIExpbmsgSUQiIGZpZWxkPyBGb3IgTE1QLVdETSwgdGhlIGNv bmNlcHQgb2YgYSAiVEUgbGluayIgc2VlbXMgdW5uY2Vzc2FyeS4gUGVyaGFwcyB0aGlzIGNvdWxk IGJlIGNhbGxlZCAicGh5c2ljYWwgbGluayIuIFN1Y2ggZGV0YWlscyBhcmUgbWlzc2luZyBoZXJl Lg1XaGF0IGlzIHRoZSByZXF1aXJlbWVudCBvbiBOb2RlIElkcz8gU2hvdWxkIHRoZXkgYmUgdW5p cXVlIGFjcm9zcyBhIHN5c3RlbSBvZiBPWENzIGFuZCBXRE0/IE9yLCBzaG91bGQgdGhleSBiZSBv bmx5IHVuaXF1ZSBiZXR3ZWVuIHBhaXJzIG9mIGNvbW11bmljYXRpbmcgT1hDIGFuZCBXRE1zPyAo Tm90ZSB0aGF0IE9YQ3MgYW5kIFdETXMgbWF5IGJlIGFkbWluaXN0ZXJlZCBieSBkaWZmZXJlbnQg ZW50aXRpZXMuIEhvdyB0byB5b3UgZW5zdXJlIHN5c3RlbS13aWRlIHVuaXF1ZSBOb2RlIElkcz8p DVdoYXQgYXJlIHRoZSBuZWdvdGlhYmxlIGFuZCBub24tbmVnb3RpYWJsZSBUTFZzIGluIHRoZSBj b25maWcgbWVzc2FnZT8NV2h5IGNhbid0IHdlIGFsd2F5cyBsZXQgdGhlIE9YQ3MgY2hvb3NlIGFs bCB2YWx1ZXMgKGUuZy4sIEhlbGxvIHBhcmFtZXRlcnMpIGFuZCB0aGUgV0RNIHN5c3RlbXMgdG8g anVzdCBhY2NlcHQgdGhlc2U/IEkuZS4sIHRoZSBjb25maWcgcHJvY2VkdXJlIGNvdWxkIGJlIHNw ZWNpZmllZCBzdWNoIHRoYXQgb25seSBhbiBPWEMgbWF5IGluaXRpYXRlIGl0IChyYXRoZXIgdGhh biBXRE0pLiBPdGhlciB0aGFuIHRoZSBub3RpZmljYXRpb24gcHJvY2VzcywgdGhlIE9YQyBtb3N0 bHkgY29udHJvbHMgYWxsIHRyYW5zYWN0aW9ucywgc28gd2h5IGNhbid0IGl0IGRpY3RhdGUgdGhl IHBhcmFtZXRlcnMgYWxzbz8NICAgIA0yLjIuIExpbmsgVmVyaWZpY2F0aW9uIA0gICAgDSAgIFRo ZSBUZXN0IHByb2NlZHVyZSB1c2VkIHdpdGggV0RNIHRyYW5zbWlzc2lvbiBzeXN0ZW1zIGlzIHRo ZSBzYW1lIGFzIA0gICBkZXNjcmliZWQgaW4gW0xNUF0uICBUaGUgVmVyaWZ5VHJhbnNwb3J0TWVj aGFuaXNtIChpbmNsdWRlZCBpbiB0aGUgDSAgIEJlZ2luVmVyaWZ5IGFuZCBCZWdpblZlcmlmeUFj ayBtZXNzYWdlcykgaXMgdXNlZCB0byBhbGxvdyBub2RlcyB0byANICAgbmVnb3RpYXRlIGEgbGlu ayB2ZXJpZmljYXRpb24gbWV0aG9kIGFuZCBpcyBlc3NlbnRpYWwgZm9yIA0gICB0cmFuc21pc3Np b24gc3lzdGVtcyB3aGljaCBoYXZlIGFjY2VzcyB0byBvdmVyaGVhZCBieXRlcyByYXRoZXIgdGhh biANICAgdGhlIHBheWxvYWQuICBUaGUgVmVyaWZ5SWQgKHByb3ZpZGVkIGJ5IHRoZSByZW1vdGUg bm9kZSBpbiB0aGUgDSAgIEJlZ2luVmVyaWZ5QWNrIG1lc3NhZ2UsIGFuZCB1c2VkIGluIGFsbCBz dWJzZXF1ZW50IFRlc3QgbWVzc2FnZXMpIGlzIA0gICB1c2VkIHRvIGRpZmZlcmVudGlhdGUgVGVz dCBtZXNzYWdlcyBmcm9tIGRpZmZlcmVudCBMTVAgc2Vzc2lvbnMuIA0NTGluayB2ZXJpZmljYXRp b24gdW5kZXIgTE1QIG5lZWRzIHNvbWUgY2xlYW4gdXAuIFNwZWNpZmljYWxseSwNVGhlIHdheSBp dCBpcyBzcGVjaWZpZWQgY3VycmVudGx5LCB5b3UgaGF2ZSB0byBjb25maWd1cmUgd2hpY2ggbGlu a3MgZ28gdG8gd2hpY2ggbmVpZ2hib3IgYW5kIHdoaWNoIGNvbnRyb2wgY2hhbm5lbCBpcyBhc3Nv Y2lhdGVkIHdpdGggd2hpY2ggc2V0cyBvZiBsaW5rcy4gSWYgeW91IGRvIHRoaXMgbXVjaCwgeW91 IG1pZ2h0IGFzIHdlbGwgY29uZmlndXJlIHRoZSBwb3J0IElkcy4gSWYgeW91IGRvbid0IGRvIHRo aXMsIHRoZSBwcm90b2NvbCBjb21wbGV4aXR5IGluY3JlYXNlcy4gDVRoZSBoYXJkd2FyZSBzdXBw b3J0IG5lZWRlZCBmb3IgdGhpcyBoYXMgdG8gYmUgY2xlYXJseSBzdGF0ZWQsIGFzIGluIHRoZSBO VElQIGRvY3VtZW50Lg1BcmUgYWxsIHRoZSBjb25jZXB0cyB1c2VkIGluIExNUCBuZWNlc3Nhcnkg aGVyZSBpbiBMTVAtV0RNPyBTcGVjaWZpY2FsbHksIHRoZSBjb25jZXB0IG9mIFRFIGxpbmtzIGlz IHVzZWQgaW4gTE1QIHZlcmlmaWNhdGlvbiB3aGljaCBJIGJlbGlldmUgaXMgdW5uZWNlc3Nhcnkg aW4gTE1QLVdETS4gKEkgaGF2ZSBhIHNpbWlsYXIgY29tbWVudCBmb3IgTE1QIGFsc28pLg00LiBU aGUgY2hvaWNlcyBmb3Igc2VuZGluZyBpbi1iYW5kIG1lc3NhZ2VzIG5lZWQgbm90IGJlIGFzIHdp ZGUgYXMgaW4gTE1QLiBJbiBwYXJ0aWN1bGFyLCBjb25zaWRlciB0aGUgZmFjdCB0aGF0IGEgVGVz dCBzZXQgaGFzIHRvIGJlIHVzZWQgdG8gZ2VuZXJhdGUvdGVybWluYXRlIG1lc3NhZ2VzIGJldHdl ZW4gT1hDIGFuZCBXRE0uIEluIHRoaXMgY2FzZSwgd2h5IG5vdCB1c2UgdGhlIHBheWxvYWQgZm9y IHNlbmRpbmcgbWVzc2FnZXM/IE9yLCBpZiB0aGVyZSBpcyBzb21lIGFkdmFudGFnZSB3aXRoIHVz aW5nIHNlY3Rpb24gT0gsIHVzZSB0aGF0LiBOZWVkIGFuIGFuYWx5c2lzIG9mIHRoaXMgYXNwZWN0 Lg1GcmFua2x5LCBJJ20gbm90IHN1cmUgaWYgaXQncyB3b3J0aCB0aGUgdHJvdWJsZSBvZiBkb2lu ZyB2ZXJpZmljYXRpb24sIGdpdmVuIHRoZSBuZWVkIGZvciB0aGUgaGFyZHdhcmUgYW5kIHRoZSBt aW5pbWFsIGZ1bmN0aW9uYWxpdHkgdGhlIHByb3RvY29sIHByb3ZpZGVzLg0NDSAgICANMi4zLiBM aW5rIFN1bW1hcml6YXRpb24gDSAgICANICAgQXMgaW4gW0xNUF0sIHRoZSBMaW5rU3VtbWFyeSBt ZXNzYWdlIGlzIHVzZWQgdG8gc3luY2hyb25pemUgdGhlIA0gICBJbnRlcmZhY2UgSWRzIGFuZCBj b3JyZWxhdGUgdGhlIHByb3BlcnRpZXMgb2YgdGhlIFRFIGxpbmsuICANICAgQWRkaXRpb25hbCB0 eXBlLWxlbmd0aCB2YWx1ZXMgKFRMVnMpIGFyZSBkZWZpbmVkIHRvIGV4dGVuZCB0aGUgDSAgIExp bmtTdW1tYXJ5IG1lc3NhZ2UgdG8gaW5jbHVkZSBsaW5rIGNoYXJhY3RlcmlzdGljcy4gIFRoZSBU TFZzIA0gICBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzdWJzZWN0aW9ucyBhcmUgdHJhbnNt aXR0ZWQgYXMgRGF0YSBMaW5rIA0gICBTdWItVExWcyBpbiB0aGUgRGF0YSBMaW5rIFRMViAoc2Vl IFtMTVBdKS4gIFRoZSBsaW5rIA0gICBjaGFyYWN0ZXJpc3RpY3MsIGluIGdlbmVyYWwsIGFyZSB0 aG9zZSBjaGFyYWN0ZXJpc3RpY3MgbmVlZGVkIGJ5IHRoZSANICAgY29udHJvbCBwbGFuZSBmb3Ig Y29uc3RyYWludC1iYXNlZCByb3V0aW5nIGFuZCBjb25uZWN0aW9uIA0gICBlc3RhYmxpc2htZW50 LiAgDSAgIFRoZSBmb3JtYXQgb2YgdGhlIERhdGEgTGluayBTdWItVExWcyBmb2xsb3dzIHRoZSBM TVAgVExWIGZvcm1hdCANICAgZ2l2ZW4gSW4gU2VjdGlvbiA4LjMgb2YgW0xNUF0gYW5kIHNob3du IGJlbG93OiAgDSAgICANICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMgDSAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDSAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0gICAgICB8TnwgICAgICAgICAgVHlwZSAgICAgICAgICAgICAgIHwgICAgICAgICAgICBMZW5n dGggICAgICAgICAgICAgfCANICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0gICAgICAv LyAgICAgICAgICAgICAgICAgICAgICAgICAoVExWIE9iamVjdCkgICAgICAgICAgICAgICAgICAg ICAgICAvLyANICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICAgDSAgICAgLiAgTjog MSBiaXQgDSAgICAgICAgIA0gICAgICAgIFRoZSBOIGZsYWcgaW5kaWNhdGVzIGlmIHRoZSBvYmpl Y3QgaXMgYSBuZWdvdGlhYmxlIHBhcmFtZXRlciANICAgICAgICAoTj0xKSBvciBhIG5vbi1uZWdv dGlhYmxlIHBhcmFtZXRlciAoTj0wKS4gDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0MDUludGVybmV0IERyYWZ0 ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkgMjAwMSAN IA0gICAgICAgICANICAgICAgICBOb3RlOiBub25lIG9mIHRoZSBEYXRhIExpbmsgVExWcyB0aGF0 IGFyZSBkZWZpbmVkIGluIExNUC1XRE0gDSAgICAgICAgYXJlIG5lZ290aWFibGUgYW5kIHRoZSBO IGJpdCBzaG91bGQgYmUgc2V0IHRvIE49MC4gDSAgICANICAgICAuICBUeXBlOiAxNSBiaXRzIA0g ICAgICAgICANICAgICAgICBUaGUgVHlwZSBmaWVsZCBpbmRpY2F0ZXMgdGhlIFRMViB0eXBlLiAN ICAgIA0gICAgIC4gIExlbmd0aDogMTYgYml0cyANICAgICAgICAgDSAgICAgICAgVGhlIExlbmd0 aCBmaWVsZCBpbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVExWIG9iamVjdCBpbiANICAgICAg ICBieXRlcy4gDSAgICANICAgVGhlIGZvbGxvd2luZyBMaW5rIENoYXJhY3RlcmlzdGljcyBhcmUg YWR2ZXJ0aXNlZCBvbiBhIHBlciBjb21wb25lbnQgDSAgIGxpbmsgKG9yIHBvcnQpIGJhc2lzLiAg IA0gICAgDTIuMy4xLiBMaW5rIEdyb3VwIElEIA0gICAgDSAgIEEgbG9jYWwgSUQgYXNzaWduZWQg dG8gYSBncm91cCBvZiBjb21wb25lbnQgbGlua3MuICBUaGlzIElEIGNhbiBiZSANICAgdXNlZCB0 byByZWR1Y2UgdGhlIGNvbnRyb2wgdHJhZmZpYyBpbiB0aGUgY2FzZSBvZiBhIGZhaWx1cmUgYnkg DSAgIGVuYWJsaW5nIHRoZSBzeXN0ZW1zIHRvIHNlbmQgYSBzaW5nbGUgbWVzc2FnZSBmb3IgYSBn cm91cCBpbnN0ZWFkIG9mIA0gICBpbmRpdmlkdWFsIG1lc3NhZ2VzIGZvciBlYWNoIG1lbWJlciBv ZiB0aGUgZ3JvdXAuICBBIGxpbmsgbWF5IGJlIGEgDSAgIG1lbWJlciBvZiBtdWx0aXBsZSBncm91 cHMuICBGb3IgZXhhbXBsZSwgdGhlcmUgbWF5IGJlIGEgZ3JvdXAgDSAgIGNvcnJlc3BvbmRpbmcg dG8gYSBwYXJ0aWN1bGFyIHdhdmVsZW5ndGggYW5kIGFub3RoZXIgZ3JvdXAgYXNzaWduZWQgDSAg IHRvIGEgcGh5c2ljYWwgZmliZXIuIA0NSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIHRoaXMuIElz bid0IGl0IHRoZSBjYXNlIHRoYXQgYSBXRE0gc3lzdGVtIGFsd2F5cyBtdWx0aXBsZXhlcyBhbGwg aW5jb21pbmcgd2F2ZWxlbmd0aHMgb250byBhIHNpbmdsZSBmaWJlcj8gVGhlbiwgZWl0aGVyIGEg ZmFpbHVyZSBhZmZlY3RzIHRoZSB3aG9sZSBzZXQgb2Ygd2F2ZWxlbmd0aHMgKGUuZy4sIGZpYmVy IGN1dCkgb3IgYSByYW5kb20gc2V0IG9mIHdhdmVsZW5ndGhzLiBTbywgaXQgc2VlbXMgbGlrZSBl aXRoZXIgYWxsIHRoZSBsaW5rcyBjb25uZWN0aW5nIHRvIHRoZSBXRE0gaXMgYSBncm91cCwgb3Ig ZWFjaCBsaW5rIGlzIGEgZ3JvdXAgYnkgaXRzZWxmIChpLmUuLCBubyBncm91cHMgaW4gZWZmZWN0 KS4gT24gd2hhdCBiYXNpcyBjYW4geW91IGZvcm0gYW55IG90aGVyIHR5cGUgb2YgbGluayBncm91 cD8NICAgIA0gICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIg ICAgICAgICAgICAgICAgICAgMyAgDSAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgIA0gICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDSAg ICAgIHwwfCAgICAgICAgIFR5cGUgPSBUQkQgICAgICAgICAgfCAgICAgICAgICBMZW5ndGggPSA0 ICAgICAgICAgICB8ICANICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgR3JvdXAgSUQgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgDSAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rICANICAgIA0gICAgDSAgICAgLiAgVHlwZTogMTUgYml0cyA9IFRCRCANICAgIA0gICAg IC4gIExlbmd0aDogMTYgYml0cyA9IDQgDSAgICANICAgICAuICBHcm91cCBJRDogMzIgYml0cyAN ICAgICAgICAgDSAgICAgICAgR3JvdXAgSUQgMHhGRkZGRkZGRiBpcyByZXNlcnZlZCBhbmQgaW5k aWNhdGVzIGFsbCBjb21wb25lbnQgDSAgICAgICAgbGlua3MgaW4gYSBURSBsaW5rLiAgQWxsIGNv bXBvbmVudCBsaW5rcyBhcmUgbWVtYmVycyBvZiBMaW5rIA0gICAgICAgIEdyb3VwIDB4RkZGRkZG RkYgYnkgZGVmYXVsdC4gDSAgICANICAgVGhlIExpbmsgR3JvdXAgSUQgZmVhdHVyZSBhbGxvd3Mg TGluayBHcm91cHMgdG8gYmUgYXNzaWduZWQgYmFzZWQgDSAgIHVwb24gdGhlIHR5cGVzIG9mIGZh dWx0IGNvcnJlbGF0aW9uIGFuZCBhZ2dyZWdhdGlvbiBzdXBwb3J0ZWQgYnkgYSANICAgZ2l2ZW4g T0xTLiAgIA0gICAgDSAgIEZvciBleGFtcGxlLCBhIExpbmsgR3JvdXAgY291bGQgYmUgY3JlYXRl ZCBmb3IgZWFjaCBXRE0gbGFzZXIuICBUaGlzIA0gICBncm91cCBjb3VsZCB0aGVuIGJlIGFzc29j aWF0ZWQgd2l0aCB1c2VyIHBvcnRzIGR1cmluZyANDSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQwNSW50ZXJuZXQg RHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAgICAgICAgSnVseSAy MDAxIA0gDSAgIGRpc2NvdmVyeS9pbml0aWFsaXphdGlvbiB0aW1lLiAgTXVsdGlwbGUgdXNlciBw b3J0cyBtaWdodCBldmVuIGJlIA0gICBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgZ3JvdXAgKGRl cGVuZGluZyBvbiB0aGUga2luZCBvZiANICAgbXVsdGlwbGV4aW5nIHN1cHBvcnRlZCBpbiB0aGUg c3lzdGVtKS4gIElmIGEgbGFzZXIgZmFpbHMsIHRoZSBXRE0gDSAgIHN5c3RlbSBjYW4gcmVwb3J0 IGEgZmFpbHVyZSBvbiB0aGUgZ3JvdXAuICBJbiB0aGUgT1hDIHRoaXMgDSAgIHRyYW5zbGF0ZXMg aW50byB0aGUgZmFpbHVyZSBvZiB0aGUgYXNzb2NpYXRlZCBsaW5rIG9yIGxpbmtzLiAgDQ1BZ2Fp biwgSSdtIGxvc3QuIEVhY2ggT1hDLVdETSBwaHlzaWNhbCBsaW5rLCB3aGljaCBpcyB3aGF0IE9M SSBpcyBjb250cm9sbGluZywgaGFzIGEgb25lLXRvLW9uZSBtYXBwaW5nIHdpdGggYSBsYXNlci4g SG93IGNhbiBtdWx0aXBsZSBsaW5rcyBiZSBhc3NvY2lhdGVkIHdpdGggYSBsYXNlcj8NDSAgIEFu b3RoZXIgZ3JvdXAgY291bGQgYmUgYXNzaWduZWQgZm9yIGEgZmliZXIgdG8gcmVwb3J0IGFsbCBw b3J0cyBkb3duIA0gICB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhhdCBmaWJlciBpZiBMT1Mg aXMgZGV0ZWN0ZWQgYXQgdGhlIGZpYmVyIA0gICBsZXZlbC4gIERlcGVuZGluZyBvbiB0aGUgcGh5 c2ljYWwgV0RNIGltcGxlbWVudGF0aW9uLCBpdCBtYXkgbWFrZSANICAgc2Vuc2UgdG8gYWxsb2Nh dGVkIG90aGVyIGdyb3Vwcywgc3VjaCBhcyBhbGwgcG9ydHMgb24gYSBwYXJ0aWN1bGFyIA0gICBj aXJjdWl0IHBhY2suICBXaXRoIHRoaXMgbWV0aG9kLCB0aGUgT1hDIG9ubHkgbmVlZHMgdG8ga25v dyBhYm91dCANICAgdGhlIGV4dGVybmFsbHkgdmlzaWJsZSBwb3J0cy4gIFRoZSBXRE0gc3lzdGVt IGNhbiBhc3NvY2lhdGUgdGhlIA0gICBwb3J0cyB3aXRoIGxvZ2ljYWwgZ3JvdXBzIGFuZCB0aGUg T1hDIGRvZXNuJ3QgbmVlZCB0byBrbm93IGFueXRoaW5nIA0gICBhYm91dCB0aGUgcGh5c2ljYWwg V0RNIGltcGxlbWVudGF0aW9uIG9yIGhvdyBwb3J0cyBhcmUgbXVsdGlwbGV4ZWQgDSAgIGVsZWN0 cmljYWxseSBvciBvcHRpY2FsbHkgd2l0aGluIHRoZSBzeXN0ZW0uIA0NT24gdGhlIHdob2xlLCB0 aGlzIGNvbmNlcHQgc2VlbXMgbWFyZ2luYWwgaW4gdmFsdWUuDSAgICANMi4zLjIuIExpbmsgRGVz Y3JpcHRvciANICAgIA0gICBUaGUgTGluayBEZXNjcmlwdG9yIFRMViByZXByZXNlbnRzIHRoZSBj aGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGxpbmsgDSAgIGNvbXByaXNpbmcgdGhlIGVuY29kaW5nIHR5 cGUgYW5kIGJhbmR3aWR0aCBjaGFyYWN0ZXJpc3RpY3MuICBUaGlzIA0gICBpbmZvcm1hdGlvbiBp cyBuZWVkZWQgZm9yIGNvbnN0cnVjdGluZyBhIGNpcmN1aXQuICBUaGUgT1hDIG11c3QgDSAgIG1h dGNoIHRoZSBsaW5rIGluZm9ybWF0aW9uIGJldHdlZW4gaW5jb21pbmcgYW5kIG91dGdvaW5nIGlu dGVyZmFjZXMgDSAgIGZvciBhIGdpdmVuIHBhdGguIA0gICAgDSAgIE5vdGU6IFRoaXMgaW5mb3Jt YXRpb24gbWF5IGJlIGEgcHJlcmVxdWlzaXRlIGZvciBydW5uaW5nIHRoZSB2ZXJpZnkgDSAgIHBy b3RvY29sLCB0aHVzIGl0IG1heSBiZSByZWR1bmRhbnQgd2hlbiB2ZXJpZnkgaXMgYmVpbmcgdXNl ZC4gDQ1QcmVjaXNlbHkuIElmIHZlcmlmeSBpcyBub3QgdXNlZCwgdGhlbiB0aGlzIGluZm9ybWF0 aW9uIHNob3VsZCBiZSBjb25maWd1cmVkLiBGdXJ0aGVybW9yZSwgc3R1ZmYgbGlrZSBsaW5rIGVu Y29kaW5nIHR5cGUsIHJlc2VydmFibGUgYncsIGV0YywgaGF2ZSBtZWFuaW5nIG9ubHkgYXQgdGhl IE9YQyBsYXllciAoaWUuLCBvbiBPWEMtdG8tT1hDIGxpbmtzKS4gSXQgc2VlbXMgcXVpdGUgdW5u YXR1cmFsIHRoYXQgYSBXRE0gc3lzdGVtIChhbmQgaXRzIGFkbWluaXN0cmF0b3JzKSB3b3VsZCBl dmVuIGNhcmUgYWJvdXQgdGhpcyBzdHVmZi4gQWxzbywgaG93IGRvZXMgdGhlIFdETSBzeXN0ZW0g ZXZlbiBrbm93IGFib3V0IGxpbmsgZW5jb2RpbmcgdHlwZT8gDSAgICANICAgVGhlIGRldGFpbHMg Zm9yIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIFRMViBhcmUgdGhlIHNhbWUgYXMgdGhvc2UgDSAg IGZvciB0aGUgbGluayBkZXNjcmlwdG9yIHN1Yi1UTFYgZGVmaW5lZCBpbiBbS1JCMDBhXS4gDSAg ICANICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDMgIA0gICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICANICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICAgICB8 MHwgICAgICAgICBUeXBlID0gVEJEICAgICAgICAgIHwgICAgICAgICAgTGVuZ3RoID0gMTIgICAg ICAgICAgfCAgDSAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg TGluayBFbmNvZGluZyBUeXBlICAgICAgICAgICAgICAgICAgICAgIHwgIA0gICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyAgDSAgICAgIHwgICAgICAgICAgICAgICAgICBNaW5pbXVtIFJlc2VydmFibGUgQmFuZHdpZHRo ICAgICAgICAgICAgICAgICB8ICANICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICAgICB8ICAgICAgICAgICAg ICAgICAgTWF4aW11bSBSZXNlcnZhYmxlIEJhbmR3aWR0aCAgICAgICAgICAgICAgICAgfCAgDSAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rICANICAgIA0gICAgDSAgICAgLiAgVHlwZTogMTUgYml0cyA9IFRCRCANICAg IA0gICAgIC4gIExlbmd0aDogMTYgYml0cyA9IDEyIA0gICAgDQ0NDQ0NDSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0g DQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAg ICAgICAgSnVseSAyMDAxIA0gDSAgICAgLiAgTGluayBFbmNvZGluZyBUeXBlOiAzMiBiaXRzIA0g ICAgDSAgICAgICAgIFZhbHVlICAgICAgICBMaW5rIEVuY29kaW5nIFR5cGUgDSAgICAgICAgIC0t LS0tICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0gDSAgICAgICAgICAgICAxICAgICAgICBTdGFu ZGFyZCBTT05FVCANICAgICAgICAgICAgIDIgICAgICAgIEFyYml0cmFyeSBTT05FVCANICAgICAg ICAgICAgIDMgICAgICAgIFN0YW5kYXJkIFNESCANICAgICAgICAgICAgIDQgICAgICAgIEFyYml0 cmFyeSBTREggDSAgICAgICAgICAgICA1ICAgICAgICBDbGVhciANICAgICAgICAgICAgIDYgICAg ICAgIEdpZ0UgDSAgICAgICAgICAgICA3ICAgICAgICAxMEdpZ0UgDSAgICANICAgIA0gICAgIC4g IE1pbmltdW0gUmVzZXJ2YWJsZSBCYW5kd2lkdGg6IDMyIGJpdHMgDSAgICAgICAgIA0gICAgICAg IEJ5dGVzIHBlciBTZWNvbmQgcmVwcmVzZW50ZWQgaW4gSUVFRSBmbG9hdGluZyBwb2ludCBmb3Jt YXQuIA0gICAgDSAgICAgLiAgTWF4aW11bSBSZXNlcnZhYmxlIEJhbmR3aWR0aDogMzIgYml0cyAN ICAgICAgICAgDSAgICAgICAgQnl0ZXMgcGVyIFNlY29uZCByZXByZXNlbnRlZCBpbiBJRUVFIGZs b2F0aW5nIHBvaW50IGZvcm1hdC4gDSAgICAgICAgIA0gICAgICAgIElmIHRoZSBpbnRlcmZhY2Ug b25seSBzdXBwb3J0cyBhIGZpeGVkIHJhdGUsIHRoZSBtaW5pbXVtIGFuZCANICAgICAgICBtYXhp bXVtIGJhbmR3aWR0aCBmaWVsZHMgYXJlIHNldCB0byB0aGUgc2FtZSB2YWx1ZS4gDSAgICAgICAg IA0gICAgICAgIEJhbmR3aWR0aCBWYWx1ZXMgYW5kIHRoZWlyIElFRUUgcmVwcmVzZW50YXRpb24g Zm9yIGNvbW1vbiANICAgICAgICBpbnRlcmZhY2VzIGFyZSBwcm92aWRlZCBpbiB0aGUgZm9sbG93 aW5nIHRhYmxlLiANICAgIA0gICAgICAgIFNpZ25hbCBUeXBlICAgKEJpdC1yYXRlKSAgICAgICAg ICAgICAgVmFsdWUgKEJ5dGVzL1NlYykgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKElFRUUgRmxvYXRpbmcgcG9pbnQpIA0gICAgICAgICAtLS0tLS0tLS0tLSAg IC0tLS0tLS0tLS0tICAgICAgICAgICAgIC0tLS0tLS0tLS0tLSANICAgICAgICAgICAgICAgIERT MCAgKDAuMDY0IE1icHMpICAgICAgICAgICAgICAweDQ1RkEwMDAwIA0gICAgICAgICAgICAgICAg RFMxICAoMS41NDQgTWJwcykgICAgICAgICAgICAgIDB4NDgzQzdBMDAgDSAgICAgICAgICAgICAg ICAgRTEgICgyLjA0OCBNYnBzKSAgICAgICAgICAgICAgMHg0ODdBMDAwMCANICAgICAgICAgICAg ICAgIERTMiAgKDYuMzEyIE1icHMpICAgICAgICAgICAgICAweDQ5NDBBMDgwIA0gICAgICAgICAg ICAgICAgIEUyICAoOC40NDggTWJwcykgICAgICAgICAgICAgIDB4NDk4MEU4MDAgDSAgICAgICAg ICAgRXRoZXJuZXQgICgxMC4wMCBNYnBzKSAgICAgICAgICAgICAgMHg0OTk4OTY4MCANICAgICAg ICAgICAgICAgICBFMyAgKDM0LjM2OCBNYnBzKSAgICAgICAgICAgICAweDRBODMxQTgwIA0gICAg ICAgICAgICAgICAgRFMzICAoNDQuNzM2IE1icHMpICAgICAgICAgICAgIDB4NEFBQUE3ODAgDSAg ICAgICAgICAgICAgU1RTLTEgICg1MS44NCBNYnBzKSAgICAgICAgICAgICAgMHg0QUM1QzEwMCAN ICAgICAgRmFzdCBFdGhlcm5ldCAgKDEwMC4wMCBNYnBzKSAgICAgICAgICAgICAweDRCM0VCQzIw IA0gICAgICAgICAgICAgICAgIEU0ICAoMTM5LjI2NCBNYnBzKSAgICAgICAgICAgIDB4NEI4NEQw MDAgDSAgICAgICAgIE9DLTMvU1RNLTEgICgxNTUuNTIgTWJwcykgICAgICAgICAgICAgMHg0Qjk0 NTBDMCANICAgICAgICBPQy0xMi9TVE0tNCAgKDYyMi4wOCBNYnBzKSAgICAgICAgICAgICAweDRD OTQ1MEMwIA0gICAgICAgICAgICAgICBHaWdFICAoMTAwMC4wMCBNYnBzKSAgICAgICAgICAgIDB4 NENFRTZCMjggDSAgICAgICAgICAgICAgT0MtNDggICgyNDg4LjMyIE1icHMpICAgICAgICAgICAg MHg0RDk0NTBDMCANICAgICAgICAgICAgIE9DLTE5MiAgKDk5NTMuMjggTWJwcykgICAgICAgICAg ICAweDRFOTQ1MEMwIA0gICAgICAgICAxMEdpZ0UtTEFOICAoMTAwMDAuMDAgTWJwcykgICAgICAg ICAgIDB4NEU5NTAyRjkgDSAgICANICAgIA0NDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0MDUludGVybmV0IERy YWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkgMjAw MSANIA0yLjMuMy4gU2hhcmVkIFJpc2sgTGluayBHcm91cCBJZGVudGlmaWVyIChTUkxHKTogDSAg ICANICAgU1JMR3MgdG8gd2hpY2ggdGhlIGxpbmsgaXMgYSBtZW1iZXIuICBUaGlzIGluZm9ybWF0 aW9uIGlzIG1hbnVhbGx5IA0gICBjb25maWd1cmVkIG9uIHRoZSBEV0RNIHN5c3RlbXMgYnkgdGhl IHNlcnZpY2UgcHJvdmlkZXJzLiBVc2VkIGZvciANICAgZGl2ZXJzZSBwYXRoIGNvbXB1dGF0aW9u LiANDUl0J3MgcXVpdGUgZWFzeSB0byBzZWUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhpcyB0 eXBlIG9mIGluZm9ybWF0aW9uICh3aGljaCByZWxhdGVzIHRvIHBoeXNpY2FsIGZhY2lsaXRpZXMs IGFuZCBoZW5jZSBuYXRpdmUgdG8gdGhlIFdETSBkb21haW4pIHZlcnN1cyBzdHVmZiBsaWtlIGVu Y29kaW5nIHR5cGUuIEkgdGhpbmsgdGhlIG90aGVyIHN0dWZmIHNob3VsZCBiZSByZW1vdmVkLg0g ICAgDSAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzIA0gICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIA0gICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgICAgfDB8 ICAgICAgICAgVHlwZSA9IFRCRCAgICAgICAgICB8ICAgNCAqIE5vLiBvZiBTUkxHcyBpbiBsaW5r ICAgIHwgDSAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rIA0gICAgICB8ICAgICAgICAgICAgICAgICAgU2hhcmVkIFJp c2sgTGluayBHcm91cCBWYWx1ZSAgICAgICAgICAgICAgICAgfCANICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLi4gICAgICAgICAgICAgICAg ICAgICAgICAgICB8IA0gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgICAgfCAgICAgICAgICAgICAgICAgIFNo YXJlZCBSaXNrIExpbmsgR3JvdXAgVmFsdWUgICAgICAgICAgICAgICAgIHwgDSAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rIA0gICAgDSAgICANICAgICAuICBUeXBlOiAxNSBiaXRzID0gVEJEIA0gICAgDSAgICAgLiAg TGVuZ3RoOiAxNiBiaXRzID0gNCAqIE5vLiBvZiBTUkxHcyBpbiBsaW5rIA0gICAgDSAgICAgLiAg U2hhcmVkIFJpc2sgTGluayBHcm91cCBWYWx1ZTogMzIgYml0cyANICAgIA0gICBMaXN0IGFzIG1h bnkgU1JMR3MgYXMgYXBwbHkuIA0gICAgDSAgICANMi4zLjQuIFdhdmVsZW5ndGggDSAgICANICAg VGhlIHdhdmVsZW5ndGggYmVpbmcgdXNlZCBieSB0aGUgV0RNIHN5c3RlbSB0byB0cmFuc3BvcnQg dGhlIA0gICBjb21wb25lbnQgbGluay4gIE5vdGU6IHRoaXMgaXMgbmVlZGVkIGZvciBhIHRyYW5z cGFyZW50IHN5c3RlbSwgYnV0IA0gICBvZiBxdWVzdGlvbmFibGUgdXNlIGZvciBhbiBvcGFxdWUg c3lzdGVtLiANDVdoYXQncyB0aGUgZGVmaW5pdGlvbiBvZiBhIHRyYW5zcGFyZW50IGFuZCBvcGFx dWUgc3lzdGVtIGhlcmU/DSAgICANICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgIA0gICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICANICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgIA0gICAgICB8MHwgICAgICAgICBUeXBlID0gVEJEICAgICAgICAgIHwgICAgICAg ICAgTGVuZ3RoID0gNCAgICAgICAgICAgfCAgDSAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgV2F2ZWxlbmd0aCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgIA0gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyAgDSAgICANICAgIA0gICAgIC4gIFR5cGU6IDE1IGJpdHMgPSBU QkQgDSAgICANICAgICAuICBMZW5ndGg6IDE2IGJpdHMgPSA0IA0gICAgDSAgICAgLiAgV2F2ZWxl bmd0aDogMzIgYml0cyANICAgICAgICAgDSAgICAgICAgTG9jYWwgaWRlbnRpZmllciBmb3Igd2F2 ZWxlbmd0aCBvbiB3aGljaCB0aGUgV0RNIHN5c3RlbSB3aWxsIA0gICAgICAgIHRyYW5zbWl0IHRo ZSBzaWduYWwgZnJvbSB0aGUgbGluay4gDQ1XaGF0IHByZWNpc2VseSBpcyB0aGUgdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24/IA0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXSANDA1JbnRlcm5ldCBEcmFmdCAgICAgICBk cmFmdC1tYW55LW9saS1yZXF0cy0wMC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANICAgIA0g ICAgDTIuMy41LiBCaXQgRXJyb3IgUmF0ZSAoQkVSKSBFc3RpbWF0ZSANICAgIA0gICBUaGlzIFRM ViBwcm92aWRlcyBhbiBlc3RpbWF0ZSBvZiB0aGUgQkVSIGZvciB0aGUgY29tcG9uZW50IGxpbmsu IA0gICAgDSAgIFRoZSBiaXQgZXJyb3IgcmF0ZSAoQkVSKSBpcyB0aGUgcGVyY2VudGFnZSBvZiBi aXRzIHRoYXQgaGF2ZSBlcnJvcnMgDSAgIHJlbGF0aXZlIHRvIHRoZSB0b3RhbCBudW1iZXIgb2Yg Yml0cyByZWNlaXZlZCBpbiBhIHRyYW5zbWlzc2lvbiwgDSAgIHVzdWFsbHkgZXhwcmVzc2VkIGFz IHRlbiB0byBhIG5lZ2F0aXZlIHBvd2VyLiBGb3IgZXhhbXBsZSwgYSANICAgdHJhbnNtaXNzaW9u IG1pZ2h0IGhhdmUgYSBCRVIgb2YgMTAgdG8gdGhlIG1pbnVzIDYsIG1lYW5pbmcgdGhhdCwgDSAg IG91dCBvZiAxLDAwMCwwMDAgYml0cyB0cmFuc21pdHRlZCwgb25lIGJpdCB3YXMgaW4gZXJyb3Iu IFRoZSBCRVIgaXMgDSAgIGFuIGluZGljYXRpb24gb2Ygb3ZlcmFsbCBsaW5rIHF1YWxpdHkuIA0g ICAgDSAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzICANICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAgDSAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAgICAg fDB8ICAgICAgICAgVHlwZSA9IFRCRCAgICAgICAgICB8ICAgICAgICAgIExlbmd0aCA9IDQgICAg ICAgICAgIHwgIA0gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDSAgICAgIHwgICAgICAgICAgICAgICAgICAgUmVz ZXJ2ZWQgICAgICAgICAgICAgICAgICAgIHwgICAgIEJFUiAgICAgICB8ICANICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgIA0gICAgDSAgICANICAgICAuICBUeXBlOiAxNSBiaXRzID0gVEJEIA0gICAgDSAgICAgLiAg TGVuZ3RoOiAxNiBiaXRzID0gNCANICAgIA0gICAgIC4gIFJlc2VydmVkOiAyNCBiaXRzIA0gICAg ICAgICANICAgICAgICBNdXN0IGJlIHNldCB0byB6ZXJvIG9uIHRyYW5zbWl0IGFuZCBpZ25vcmVk IG9uIHJlY2VpdmUuIA0gICAgDSAgICAgLiAgQkVSOiA4IGJpdHMgDSAgICAgICAgIA0gICAgICAg IFRoZSBleHBvbmVudCBmcm9tIHRoZSBCRVIgcmVwcmVzZW50YXRpb24gZGVzY3JpYmVkIGFib3Zl LiAgRm9yIA0gICAgICAgIGV4YW1wbGUsIGlmIHRoZSBCRVIgaXMgMTAgdG8gdGhlIG1pbnVzIFgs IHRoZSBCRVIgZmllbGQgaXMgc2V0IA0gICAgICAgIHRvIFguIA0gICAgDUhvdyBpcyB0aGUgQkVS IGNhbGN1bGF0ZWQ/IEFsc28sIGl0IHNlZW1zIHNvbWUgb2YgdGhlc2UgcGFyYW1ldGVycyBhcmUg cmVsYXRpdmVseSBzdGF0aWMgKGUuZy4sIFNSTEcpIHdoaWxlIHNvbWUgYXJlIGhpZ2hseSBkeW5h bWljIChCRVIpLiBTaG91bGRuJ3QgdGhlIGR5bmFtaWMgcGFyYW1ldGVycyBiZSBpbmRpY2F0ZWQg dXNpbmcgYW4gYXN5bmNocm9ub3VzIG5vdGlmeSBtZWNoYW5pc20gZnJvbSB0aGUgV0RNIHRvIHRo ZSBPWEM/DSAgICANMi4zLjYuIE9wdGljYWwgUHJvdGVjdGlvbiANICAgIA0gICBXaGV0aGVyIHRo ZSBXRE0gc3lzdGVtIHByb3RlY3RzIHRoZSBsaW5rIGludGVybmFsbHkuICBUaGlzIA0gICBpbmZv cm1hdGlvbiBjYW4gYmUgdXNlZCBhcyBhIG1lYXN1cmUgb2YgcXVhbGl0eSBvZiB0aGUgbGluay4g IEl0IG1heSANICAgYmUgYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGFuZCB1c2VkIGJ5IHNpZ25hbGlu ZyBhcyBhIHNlbGVjdGlvbiANICAgY3JpdGVyaW9uIGFzIGRlc2NyaWJlZCBpbiBbR01QTFNdLiAN DUknbSBjdXJpb3VzLCBpcyB0aGlzIHJlYWxseSBhIGZlYXR1cmUgaW4gYW55IGV4aXN0aW5nIFdE TSBzeXN0ZW0/IEFsc28sIGlmIHRoaXMgZmVhdHVyZSBleGlzdHMsIHNob3VsZCBpdCBiZSB2aXNp YmxlIHRvIE9YQ3MsIHNpbmNlIHRoZXkgbWF5IGFueXdheSBkbyAxKzEsIGV0YyBhdCB0aGVpciBs YXllcj8NICAgIA0gICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMyAgDSAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgIA0gICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAg DSAgICAgIHwwfCAgICAgICAgIFR5cGUgPSBUQkQgICAgICAgICAgfCAgICAgICAgICBMZW5ndGgg PSA0ICAgICAgICAgICB8ICANICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICAgICB8ICAgICAgICAgICAgICAg ICAgIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgfCBMaW5rIEZsYWdzfCAgDSAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rICANDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQt bWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAgICAgICAgSnVseSAyMDAxIA0gDSAgICANICAgIA0g ICAgIC4gIFR5cGU6IDE1IGJpdHMgPSBUQkQgDSAgICANICAgICAuICBMZW5ndGg6IDE2IGJpdHMg PSA0IA0gICAgDSAgICAgLiAgUmVzZXJ2ZWQ6IDI0IGJpdHMgDSAgICAgICAgIA0gICAgICAgIE11 c3QgYmUgc2V0IHRvIHplcm8gb24gdHJhbnNtaXQgYW5kIGlnbm9yZWQgb24gcmVjZWl2ZS4gDSAg ICANICAgICAuICBMaW5rIEZsYWdzOiAgNiBiaXRzICANICAgICAgICAgDSAgICAgICAgSW5kaWNh dGVzIHN1cHBvcnRlZCBsaW5rIHByb3RlY3Rpb24gdHlwZS4gIFRoZXNlIGxpbmsgZmxhZ3MgYXJl IA0gICAgICAgIGludGVuZGVkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aG9zZSBkZWZpbmVkIGlu IFtHTVBMU10uIA0gICAgICAgICANICAgICAgICBUaGUgZm9sbG93aW5nIGZsYWdzIGFyZSBkZWZp bmVkOiANICAgIA0gICAgICAgIC4gIDB4MjAgIEVuaGFuY2VkIA0gICAgICAgICAgIA0gICAgICAg ICAgSW5kaWNhdGVzIHRoYXQgYSBwcm90ZWN0aW9uIHNjaGVtZSB0aGF0IGlzIG1vcmUgcmVsaWFi bGUgdGhhbiANICAgICAgICAgIERlZGljYXRlZCAxKzEgc2hvdWxkIGJlIHVzZWQsIGUuZy4sIDQg ZmliZXIgQkxTUi9NUy1TUFJJTkcuIA0gICAgICANICAgICAgICAuICAweDEwICBEZWRpY2F0ZWQg MSsxIA0gICAgICAgICAgIA0gICAgICAgICAgSW5kaWNhdGVzIHRoYXQgYSBkZWRpY2F0ZWQgbGlu ayBsYXllciBwcm90ZWN0aW9uIHNjaGVtZSwgDSAgICAgICAgICBpLmUuLCAxKzEgcHJvdGVjdGlv biwgc2hvdWxkIGJlIHVzZWQgdG8gc3VwcG9ydCB0aGUgTFNQLiANICAgICAgDSAgICAgICAgLiAg MHgwOCAgRGVkaWNhdGVkIDE6MSANICAgICAgICAgICANICAgICAgICAgIEluZGljYXRlcyB0aGF0 IGEgZGVkaWNhdGVkIGxpbmsgbGF5ZXIgcHJvdGVjdGlvbiBzY2hlbWUsIA0gICAgICAgICAgaS5l LiwgMToxIHByb3RlY3Rpb24sIHNob3VsZCBiZSB1c2VkIHRvIHN1cHBvcnQgdGhlIExTUC4gDSAg ICAgIA0gICAgICAgIC4gIDB4MDQgIFNoYXJlZCANICAgICAgICAgICANICAgICAgICAgIEluZGlj YXRlcyB0aGF0IGEgc2hhcmVkIGxpbmsgbGF5ZXIgcHJvdGVjdGlvbiBzY2hlbWUsIHN1Y2ggYXMg DSAgICAgICAgICAxOk4gcHJvdGVjdGlvbiwgc2hvdWxkIGJlIHVzZWQgdG8gc3VwcG9ydCB0aGUg TFNQLiANICAgICAgDSAgICAgICAgLiAgMHgwMiAgVW5wcm90ZWN0ZWQgDSAgICAgICAgICAgDSAg ICAgICAgICBJbmRpY2F0ZXMgdGhhdCB0aGUgTFNQIHNob3VsZCBub3QgdXNlIGFueSBsaW5rIGxh eWVyIA0gICAgICAgICAgcHJvdGVjdGlvbi4gDSAgICAgIA0gICAgICAgIC4gIDB4MDEgIEV4dHJh IFRyYWZmaWMgDSAgICAgICAgICAgDSAgICAgICAgICBJbmRpY2F0ZXMgdGhhdCB0aGUgTFNQIHNo b3VsZCB1c2UgbGlua3MgdGhhdCBhcmUgcHJvdGVjdGluZyANICAgICAgICAgIG90aGVyIChwcmlt YXJ5KSB0cmFmZmljLiAgU3VjaCBMU1BzIG1heSBiZSBwcmVlbXB0ZWQgd2hlbiB0aGUgDSAgICAg ICAgICBsaW5rcyBjYXJyeWluZyB0aGUgKHByaW1hcnkpIHRyYWZmaWMgYmVpbmcgcHJvdGVjdGVk IGZhaWwuIA0gICAgDSAgICANDQ0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXSANDA1JbnRlcm5ldCBEcmFmdCAgICAg ICBkcmFmdC1tYW55LW9saS1yZXF0cy0wMC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANMi4z LjcuIFNwYW4gTGVuZ3RoOiANICAgIA0gICBEaXN0YW5jZSBvZiBmaWJlciBpbiBXRE0gc3lzdGVt LiAgTWF5IGJlIHVzZWQgYXMgYSByb3V0aW5nIG1ldHJpYyBvciANICAgdG8gZXN0aW1hdGUgZGVs YXkuIA0gICAgDSAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzICANICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAgDSAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAN ICAgICAgfDB8ICAgICAgICAgVHlwZSA9IFRCRCAgICAgICAgICB8ICAgICAgICAgIExlbmd0aCA9 IDQgICAgICAgICAgIHwgIA0gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDSAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgU3BhbiBMZW5ndGggICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgIA0gICAgDSAgICANICAgICAuICBUeXBlOiAxNSBiaXRzID0gVEJEIA0gICAgDSAg ICAgLiAgTGVuZ3RoOiAxNiBiaXRzID0gNCANICAgIA0gICAgIC4gIFNwYW4gTGVuZ3RoOiAzMiBi aXRzIA0gICAgICAgICANICAgICAgICBMZW5ndGggb2YgV0RNIHNwYW4gaW4gbWV0ZXJzLiANICAg IA0gICAgDTIuMy44LiBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoQ29sb3IpIA0gICAgDSAgIFRoZSBh ZG1pbmlzdHJhdGl2ZSBncm91cCAob3IgQ29sb3IpIHRvIHdoaWNoIHRoZSBjb21wb25lbnQgbGlu ayANICAgYmVsb25ncy4gDSAgICANICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgIA0gICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICANICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgIA0gICAgICB8MHwgICAgICAgICBUeXBlID0gVEJEICAgICAgICAgIHwgICAgICAg ICAgTGVuZ3RoID0gNCAgICAgICAgICAgfCAgDSAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIEFkbWluaXN0cmF0aXZlIEdyb3VwICAgICAgICAgICAgICAgICAgICAg IHwgIA0gICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyAgDSAgICANVGhpcyBpcyBhbm90aGVyIHBhcmFtZXRlciB0aGF0 IHNob3VsZG4ndCBiZSBpbiBhIFdETSBzeXN0ZW0uIEl0IHNpbXBseSBkb2Vzbid0IGJlbG9uZyB0 aGVyZSBiZWNhdXNlIGFkbWluIGdyb3VwIGhhcyBubyByZWxldmFuY2UgdG8gdGhlIHBoeXNpY2Fs IGxpbmsgdGhhdCB0aGUgV0RNIHRlcm1pbmF0ZXMuIEl0IGFwcGxpZXMgb25seSB0byBhbiBPWEMt dG8tT1hDIGxpbmsuIEZvciBleGFtcGxlLCBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBPWEMxIGlz IGNvbm5lY3RlZCB0byBXRE0xLCBidXQgdW5rbm93biB0byB0aGUgV0RNIHN5c3RlbSwgT1hDMSBp cyByZXBsYWNlZCBieSBhbm90aGVyIE9YQyBjb25uZWN0aW5nIHRvIGl0LiBUaGUgYWRtaW4gZ3Jv dXAgY2FuIGNoYW5nZSBmb3IgdGhlIE9YQy10by1PWEMgbGlua3MgdXNpbmcgV0RNMS4gU2hvdWxk IHRoZSBXRE0gYWRtaW5pc3RyYXRvciB3b3JyeSBhYm91dCBzdWNoIGNoYW5nZXM/IEl0IGFsc28g aW50cm9kdWNlcyBhIGNvbXBsZXggc2l0dWF0aW9uIHdoZXJlIHRoZSBhZG1pbiBncm91cCBpbmZv IGlzIGNvbnZleWVkIGJ5IHRoZSBPWEMgYWRtaW5pc3RyYXRvcnMgdG8gdGhlIFdETSBhZG1pbmlz dHJhdG9ycyBvbmx5IHRvIGJlIHNlbnQgYmFjayB1c2luZyBPTEkgdG8gdGhlIE9YQ3MuIA0gICAg DSAgICAgLiAgVHlwZTogMTUgYml0cyA9IFRCRCANICAgIA0gICAgIC4gIExlbmd0aDogMTYgYml0 cyA9IDQgDSAgICANICAgICAuICBBZG1pbmlzdHJhdGl2ZSBHcm91cDogMzIgYml0cyANICAgICAg ICAgDSAgICAgICAgQSAzMiBiaXQgdmFsdWUuIA0gICAgDSAgICANMi40LiBGYXVsdCBNYW5hZ2Vt ZW50IA0gICAgDSAgIEZhdWx0IG1hbmFnZW1lbnQgY29uc2lzdHMgb2YgdGhyZWUgbWFqb3IgZnVu Y3Rpb25zOiANICAgIA0gICAgIDEuIEZhdWx0IERldGVjdGlvbiANDSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10gDQwN SW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAgICAg ICAgSnVseSAyMDAxIA0gDSAgICAgMi4gRmF1bHQgTG9jYWxpemF0aW9uIA0gICAgIDMuIEZhdWx0 IE5vdGlmaWNhdGlvbiANICAgIA0gICBUaGUgYWN0dWFsIEZhdWx0IERldGVjdGlvbiBtZWNoYW5p c21zIGFyZSB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIA0gICBpbmRpdmlkdWFsIG5vZGVzIGFu ZCBhcmUgbm90IHNwZWNpZmllZCBhcyBwYXJ0IG9mIHRoaXMgcHJvdG9jb2wuICANICAgRmF1bHQg ZGV0ZWN0aW9uIG1lY2hhbmlzbXMgbWF5IGluY2x1ZGUgc3VjaCB0aGluZ3MgYXMgYml0IGVycm9y IHJhdGUgDSAgIChCRVIpIGV4Y2VlZGluZyBhIHRocmVzaG9sZCwgbG9zcyBvZiBzaWduYWwgKExP UykgYW5kIGNlcnRhaW4gU09ORVQtDSAgIGxldmVsIGVycm9ycy4gDSAgICANICAgVGhlIGZhdWx0 IG5vdGlmaWNhdGlvbiBhbmQgbG9jYWxpemF0aW9uIHByb2NlZHVyZSBpcyBlc3NlbnRpYWxseSB0 aGUgDSAgIHNhbWUgYXMgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBMTVAsIGhvd2V2ZXIsIGl0 IGlzIGV4ZWN1dGVkIGF0IA0gICB0d28gbGV2ZWxzIGluIHRoZSBleHRlbmRlZCBPWEMtV0RNIExN UC4gIA0NSSBjYW4gc2VlIGZhdWx0IG5vdGlmaWNhdGlvbiAoYmV0d2VlbiBXRE0gYW5kIE9YQykg YXMgYSBmdW5jdGlvbiwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IGZhdWx0IGxv Y2FsaXphdGlvbiBoZXJlLiBBcmUgdHdvIFdETSBzeXN0ZW1zIHRhbGtpbmcgdG8gZWFjaCBvdGhl ciB0byBsb2NhbGl6ZSBhIGZhdWx0PyAoc2luY2UgeW91J3JlIHNheWluZyB0aGlzIGlzIHNpbWls YXIgdG8gTE1QIGZhdWx0IGxvY2FsaXphdGlvbikuDSAgICANICAgT1hDcyBjb250aW51ZSB0byBl eGVjdXRlIHRoZSBPWEMtdG8tT1hDIGZhdWx0IGxvY2FsaXphdGlvbiBhcyANICAgY3VycmVudGx5 IHNwZWNpZmllZC4gIFRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgV0RNIHN5c3RlbSBt YXkgDSAgIGluaXRpYXRlIHRoZSBwcm9jZXNzIChib3RoIGRvd25zdHJlYW0gYW5kIHVwc3RyZWFt KS4gIEl0IGlzIA0gICBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBPTFMgZG9lcyBub3QgcGFy dGljaXBhdGUgaW4gZW5kLXRvLWVuZCANICAgZmF1bHQgbG9jYWxpemF0aW9uIGFzIGRlc2NyaWJl ZCBpbiBbTE1QXS4gDQ1UaGVyZSBpcyBubyBuZWVkIGhlcmUgZXZlbiB0byByZWZlciB0byBMTVAg ZmF1bHQgbG9jYWxpemF0aW9uIHByb2NlZHVyZXMuIEl0J3Mgb25seSBjb25mdXNpbmcgYW5kIGRv ZXNuJ3QgY29udHJpYnV0ZSB0byB0aGlzIGRpc2N1c3Npb24uIEluZGVlZCwgTE1QIG1heSBub3Qg ZXZlbiBiZSBydW5uaW5nLg0gICAgDSAgIFRoZSBXRE0gc3lzdGVtIG1heSBhbHNvIGV4ZWN1dGUg aXRzIG93biBmYXVsdCBsb2NhbGl6YXRpb24gcHJvY2VzcyANICAgdGhhdCBtYXkgYWxsb3cgaXQg dG8gZGV0ZXJtaW5lIHRoZSBsb2NhdGlvbiBvZiB0aGUgZmF1bHQgbXVjaCBtb3JlIA0gICBzcGVj aWZpY2FsbHkgdGhhbiB0aGUgT1hDcyBjYW4uICBGb3IgZXhhbXBsZSwgdGhlIFdETSB0cmFuc21p c3Npb24gDSAgIHN5c3RlbSBtYXkgYmUgYWJsZSB0byBwaW5wb2ludCB0aGUgZmF1bHQgdG8gYSBw YXJ0aWN1bGFyIGFtcGxpZmllciANICAgYWxvbmcgYSBzZXQgb2YgZmliZXJzIHRoYXQgY2FuIHNw YW4gMTAwMCdzIG9mIGtpbG9tZXRlcnMuIA0gICAgDSAgIFRvIHJlcG9ydCBpbmRpdmlkdWFsIGxp bmsgZmFpbHVyZSBhbmQgcmVjb3ZlcnkgY29uZGl0aW9ucywgTE1QLVdETSANICAgdXNlcyBhIG5l dyBtZXNzYWdlIGNhbGxlZCB0aGUgQ2hhbm5lbFN0YXR1cyBNZXNzYWdlLiBUaGUgDSAgIENoYW5u ZWxTdGF0dXMgTWVzc2FnZSBpcyBkZXNjcmliZWQgYmVsb3cuIA0gICAgDTIuNC4xLiBDaGFubmVs U3RhdHVzIE1lc3NhZ2UgKE1zZ1R5cGUgPSBUQkQpIA0gICAgDSAgIFRoZSBDaGFubmVsU3RhdHVz IG1lc3NhZ2UgaXMgc2VudCBvdmVyIHRoZSBjb250cm9sIGNoYW5uZWwgYW5kIGlzIA0gICB1c2Vk IHRvIHJlcG9ydCB0aGUgb3BlcmF0aW9uYWwgc3RhdHVzIG9mIGEgZGF0YSBsaW5rIChwb3J0IG9y IA0gICBjb21wb25lbnQgbGluaykuICBBIENoYW5uZWxTdGF0dXMgTWVzc2FnZSBtdXN0IGJlIHNl bnQgYWZ0ZXIgDSAgIHJlY2VpdmluZyBhIENoYW5uZWxBY3RpdmUgbWVzc2FnZS4gIFdoaWxlIGNo YW5uZWxzIGFyZSBhY3RpdmUsIGEgDSAgIENoYW5uZWxTdGF0dXMgTWVzc2FnZSBtdXN0IGFsc28g YmUgc2VudCBldmVyeSB0aW1lIHRoYXQgdGhlIHN0YXR1cyANICAgY2hhbmdlcy4gIEEgY2hhbm5l bCBzdGF0dXMgbWVzc2FnZSBtdXN0IGFsc28gYmUgc2VudCBpZiBhICANICAgQ2hhbm5lbFN0YXR1 c1JlcSBNZXNzYWdlIGlzIHJlY2VpdmVkLiANICAgIA0gICAgDSAgIEEgbmVpZ2hib3Jpbmcgbm9k ZSB0aGF0IHJlY2VpdmVzIGEgQ2hhbm5lbFN0YXR1cyBtZXNzYWdlIE1VU1QgDSAgIHJlc3BvbmQg d2l0aCBhIENoYW5uZWxTdGF0dXNBY2sgbWVzc2FnZS4gIFRoZSBmb3JtYXQgaXMgYXMgZm9sbG93 czogDQ1DYW4ndCB0aGlzIGRlc2NyaXB0aW9uIGJlIG1vcmUgZXhwbGljaXQsIGkuZS4sIHRoZSBT dGF0dXMgbWVzc2FnZSBpcyBhbHdheXMgc2VudCBieSB0aGUgV0RNLiBUaGUgYWNrIGlzIGFsd2F5 cyBzZW50IGJ5IHRoZSBPWEMuDSAgICANICAgPENoYW5uZWxTdGF0dXMgTWVzc2FnZT4gOjo9IDxD b21tb24gSGVhZGVyPiA8Q2hhbm5lbFN0YXR1cz4gDSAgICANICAgVGhlIGZvcm1hdCBvZiB0aGUg Q2hhbm5lbFN0YXR1cyBvYmplY3QgaXMgYXMgZm9sbG93czogDSAgICANDQ0NDQ0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTRdIA0MDUludGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAg ICAgICAgICAgIEp1bHkgMjAwMSANIA0gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsg DSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlSWQgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgIC8vICAgICAgICAgICAg ICAgICAgICAgICAgKFN0YXR1cyBUTFZzKSAgICAgICAgICAgICAgICAgICAgICAgLy8gDSAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyANICAgIA0gICBNZXNzYWdlSWQ6ICAzMiBiaXRzIA0gICAgDSAg ICAgICAgV2hlbiBjb21iaW5lZCB3aXRoIHRoZSBMb2NhbCBURSBMaW5rIElkIGluIHRoZSBjb21t b24gaGVhZGVyIG9mIA0gICAgICAgIHRoZSByZWNlaXZlZCBwYWNrZXQsIHRoZSBNZXNzYWdlSWQg ZmllbGQgdW5pcXVlbHkgaWRlbnRpZmllcyBhIA0gICAgICAgIG1lc3NhZ2UuICBUaGlzIHZhbHVl IGlzIGluY3JlbWVudGVkIGFuZCBvbmx5IGRlY3JlYXNlcyB3aGVuIHRoZSANICAgICAgICB2YWx1 ZSB3cmFwcy4gIFRoaXMgaXMgdXNlZCBmb3IgbWVzc2FnZSBhY2tub3dsZWRnZW1lbnQgaW4gdGhl IA0gICAgICAgIENoYW5uZWxTdGF0dXNBY2sgbWVzc2FnZS4gDSANICAgVGhlIENoYW5uZWxTdGF0 dXMgbWVzc2FnZSBtdXN0IGluY2x1ZGUgYXQgbGVhc3Qgb25lIFN0YXR1cyBUTFYuICBUbyANICAg c3BlY2lmeSBhIHN0YXR1cyBmb3IgdGhlIHdob2xlIFRFIExpbmssIHVzZSB0aGUgZ3JvdXAgc3Rh dHVzIFRMViBhbmQgDSAgIGxpbmsgZ3JvdXAgMHhGRkZGRkZGRi4gIA0NVEUgbGluaz8gDSAgICAN Mi40LjEuMS4gQ2hhbm5lbCBTdGF0dXMgVExWIA0gICAgDSAgICAwICAgICAgICAgICAgICAgICAg IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzIA0gICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIA0g ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyANICAgfDB8ICAgICAgICAgICBUQkQgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgIExlbmd0aCAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICB8ICAgICAgICAgICAgICAg ICAgICAgTG9jYWwgSW50ZXJmYWNlIElkICAgICAgICAgICAgICAgICAgICAgICAgfCANICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsgDSAgIHwgICBDb25kaXRpb24gICB8ICAgICAgICAgICAgICAgICAgKFJlc2VydmVkKSAg ICAgICAgICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgIA0gICBUaGUgQ2hhbm5lbCBTdGF0 dXMgVExWIGlzIG5vbi1uZWdvdGlhYmxlLiANICAgIA0gICBMZW5ndGg6ICAxNiBiaXRzIA0gICAg DSAgICAgICAgVGhlIExlbmd0aCBpcyBpbiBieXRlcyAoc2VlIExNUCBUTFYgZm9ybWF0KS4gDSAg ICANICAgTG9jYWwgSW50ZXJmYWNlIElkOiAgMzIgYml0cyANICAgIA0gICAgICAgIFRoaXMgaXMg dGhlIGxvY2FsIEludGVyZmFjZSBJZCAoZWl0aGVyIFBvcnQgSWQgb3IgQ29tcG9uZW50IA0gICAg ICAgIEludGVyZmFjZSBJZCkgb2YgdGhlIGRhdGEgbGluayB0aGF0IGhhcyBmYWlsZWQuICBUaGlz IGlzIHdpdGhpbiANICAgICAgICB0aGUgc2NvcGUgb2YgdGhlIFRFIExpbmsgSWQuICAgDSAgICAN UGxlYXNlIGdldCByaWQgb2YgdGhlIFRFIGxpbmsgbm90aW9uLiBJdCdzIGNvbmZ1c2luZy4NDQ0N DQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMTVdIA0MDUludGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJl cXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkgMjAwMSANIA0gICBDb25kaXRpb246ICA4IGJpdHMg DSAgICANICAgICAgICBTdGF0dXMgQ29uZGl0aW9uOiANICAgICAgICAgDSAgICAgICAgVmFsdWUg ICAgQ29uZGl0aW9uICAgICAgICAgICAgICAgICAgIERlc2NyaXB0aW9uIA0gICAgICAgIC0tLS0t ICAgIC0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSANICAgICAgICAgIDEg ICAgIFNpZ25hbCBPa2F5ICAgUG9ydCBpcyBvcGVyYXRpb25hbC4gDSAgICAgICAgICAgICAgICAg ICAgKE9LKSANICAgICAgICAgIDIgICAgU2lnbmFsIERlZ3JhZGUgIEEgc29mdCBmYWlsdXJlIGNh dXNlZCBieSBhIEJFUiANICAgICAgICAgICAgICAgICAgICAoU0QpICAgICAgIGV4Y2VlZGluZyBh IHByZXNlbGVjdGVkIHRocmVzaG9sZC4gIFRoZSANICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzcGVjaWZpYyBCRVIgdXNlZCB0byBkZWZpbmUgdGhlIA0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRocmVzaG9sZCBpcyBtYXkgYmUgY29uZmlndXJlZCwgYnV0IGlzIA0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGljYWxseSBpbiB0aGUgcmFuZ2Ugb2YgMTAt NSB0byAxMC05LiANDVdoeSBzaG91bGQgdGhlIHRocmVzaG9sZCBiZSBjb25maWd1cmVkIGluIHRo ZSBXRE0/IFdoeSBjYW4ndCB0aGUgQkVSIGJlIHNpbXBseSByZXBvcnRlZCBhbmQgdGhlIE9YQyBk ZWNpZGUgd2hldGhlciBpdCdzIHdpdGhpbiBhIHRocmVzaG9sZCBvciBub3Q/IFRoaXMgaXMgYW5v dGhlciBpbnN0YW5jZSB3aGVyZSBzZW1hbnRpY3MgYXQgdGhlIE9YQyBsYXllciBhcmUgaW1wb3J0 ZWQgaW50byBXRE0gYW5kIHRoZW4gZXhwb3J0ZWQgYmFjay4NDSAgICAgICAgICAzICAgICBTaWdu YWwgRmFpbCAgIEEgaGFyZCBzaWduYWwgZmFpbHVyZSBpbmNsdWRpbmcgKGJ1dCANICAgICAgICAg ICAgICAgICAgICAoU0YpICAgICAgIG5vdCBsaW1pdGVkIHRvKSBsb3NzIG9mIHNpZ25hbCAoTE9T KSwgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9zcyBvZiBmcmFtZSAoTE9GKSwg TGluZSBBSVMsIG9yIGEgQkVSIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChCSVAt OCBtZWFzdXJlIHRocm91Z2ggQjEvQjIpIGV4Y2VlZGluZyANICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhIHNwZWNpZmllZCB2YWx1ZS4gDSAgICANICAgIA0yLjQuMS4yLiBHcm91cCBT dGF0dXMgVExWIA0gICAgDSAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzIA0gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIA0gICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfDB8 ICAgICAgICAgICBUQkQgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAg ICAgIHwgDSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rIA0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgTGluayBHcm91 cCBJZCAgICAgICAgICAgICAgICAgICAgICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgIHwgICBDb25k aXRpb24gICB8ICAgICAgICAgICAgICAgKFJlc2VydmVkKSAgICAgICAgICAgICAgICAgICAgICB8 IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyANICAgIA0gICBUaGUgR3JvdXAgU3RhdHVzIFRMViBpcyBub24tbmVnb3Rp YWJsZS4gDSAgICANICAgTGVuZ3RoOiAgMTYgYml0cyANICAgIA0gICAgICAgIFRoZSBMZW5ndGgg aXMgaW4gYnl0ZXMgKHNlZSBMTVAgVExWIGZvcm1hdCkuIA0gICAgDSAgIExpbmsgR3JvdXAgSWQ6 ICAzMiBiaXRzIA0gICAgDSAgICAgICAgVGhpcyBpcyB0aGUgTGluayBHcm91cCBJRC4gICANICAg IA0NDQ0NDQ0NDQ0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDE2XSANDA1JbnRlcm5ldCBEcmFmdCAgICAgICBkcmFmdC1t YW55LW9saS1yZXF0cy0wMC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANICAgQ29uZGl0aW9u OiAgOCBiaXRzIA0gICAgDSAgICAgICAgU3RhdHVzIENvbmRpdGlvbjogDSAgICAgICAgIA0gICAg ICAgIFZhbHVlICAgIENvbmRpdGlvbiAgICAgICAgICAgICAgICAgICBEZXNjcmlwdGlvbiANICAg ICAgICAtLS0tLSAgICAtLS0tLS0tLS0gICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gDSAg ICAgICAgICAxICAgICBTaWduYWwgT2theSAgIFBvcnQgaXMgb3BlcmF0aW9uYWwuIA0gICAgICAg ICAgICAgICAgICAgIChPSykgDSAgICAgICAgICAyICAgIFNpZ25hbCBEZWdyYWRlICBBIHNvZnQg ZmFpbHVyZSBjYXVzZWQgYnkgYSBCRVIgDSAgICAgICAgICAgICAgICAgICAgKFNEKSAgICAgICBl eGNlZWRpbmcgYSBwcmVzZWxlY3RlZCB0aHJlc2hvbGQuICBUaGUgDSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3BlY2lmaWMgQkVSIHVzZWQgdG8gZGVmaW5lIHRoZSANICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0aHJlc2hvbGQgaXMgbWF5IGJlIGNvbmZpZ3VyZWQsIGJ1 dCBpcyANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBpY2FsbHkgaW4gdGhlIHJh bmdlIG9mIDEwLTUgdG8gMTAtOS4gDSAgICAgICAgICAzICAgICBTaWduYWwgRmFpbCAgIEEgaGFy ZCBzaWduYWwgZmFpbHVyZSBpbmNsdWRpbmcgKGJ1dCANICAgICAgICAgICAgICAgICAgICAoU0Yp ICAgICAgIG5vdCBsaW1pdGVkIHRvKSBsb3NzIG9mIHNpZ25hbCAoTE9TKSwgDSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9zcyBvZiBmcmFtZSAoTE9GKSwgTGluZSBBSVMsIA0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVxdWlwbWVudCBmYWlsdXJlLCBvciBhIEJFUiAo QklQLTggDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVhc3VyZSB0aHJvdWdoIEIx L0IyKSBleGNlZWRpbmcgYSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZp ZWQgdmFsdWUuIA0gICAgU2VlIGNvbW1lbnRzIG9uIGxpbmsgZ3JvdXAuDSAgICANICAgIA0yLjQu Mi4gQ2hhbm5lbFN0YXR1c0FjayBNZXNzYWdlIChNc2dUeXBlID0gVEJEKSANICAgIA0gICBUaGUg Q2hhbm5lbFN0YXR1c0FjayBtZXNzYWdlIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBhbGwgb2Yg dGhlIA0gICBzdGF0dXMgVExWcyBpbiB0aGUgQ2hhbm5lbFN0YXR1cyBtZXNzYWdlIGhhdmUgYmVl biByZWNlaXZlZCB3aXRob3V0IA0gICBlcnJvci4gDSAgICANICAgVGhlIGZvcm1hdCBpcyBhcyBm b2xsb3dzOiAgICAgICAgICAgDSAgIDxDaGFubmVsU3RhdHVzQWNrIE1lc3NhZ2U+IDo6PSA8Q29t bW9uIEhlYWRlcj4gPENoYW5uZWxTdGF0dXNBY2s+ICANICAgIA0gICBUaGUgQ2hhbm5lbFN0YXR1 c0FjayBvYmplY3QgaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OiAgDSAgICANICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgIA0g ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxICANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBN ZXNzYWdlSWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgDSAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAg fCAgICAgICAgICAgICAgICAgICAgICBSZW1vdGUgVEUgTGluayBJZCAgICAgICAgICAgICAgICAg ICAgICAgIHwgIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyAgDSAgICANICAgTWVzc2FnZUlkOiAgMzIgYml0cyAgDSAg ICANICAgICAgICBUaGlzIGlzIGNvcGllZCBmcm9tIHRoZSBDaGFubmVsU3RhdHVzIG1lc3NhZ2Ug YmVpbmcgDSAgICAgICAgYWNrbm93bGVkZ2VkLiAgDSAgICANICAgUmVtb3RlIFRFIExpbmsgSWQ6 IDMyIGJpdHMgDSAgICANICAgICAgICBUaGlzIGlzIGNvcGllZCBmcm9tIHRoZSBDb21tb24gSGVh ZGVyIG9mIHRoZSBDaGFubmVsU3RhdHVzIA0gICAgICAgIG1lc3NhZ2UgYmVpbmcgYWNrbm93bGVk Z2VkLiANICAgIA1BZ2FpbiwgSSdtIG5vdCBzdXJlIHdoYXQgdGhlIFRFIGxpbmsgSUQgbWVhbnMg aGVyZS4gSXMgdGhpcyBpbmRpdmlkdWFsIGxpbmsgSUQgb3IgYSBncm91cCBJRD8gQ2FsbCBpdCBw aHlzaWNhbCBsaW5rIElEIGlmIGl0IHJlZmVycyB0byBhbiBpbmRpdmlkdWFsIGxpbmsuIA0NICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE3XSANDA1JbnRlcm5ldCBEcmFmdCAgICAgICBkcmFmdC1tYW55LW9saS1yZXF0cy0w MC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANICAgIA0yLjQuMy4gQ2hhbm5lbFN0YXR1c1Jl cSBNZXNzYWdlIChNc2dUeXBlID0gVEJEKSANICAgIA0gICBUaGUgQ2hhbm5lbFN0YXR1c1JlcSBt ZXNzYWdlIGlzIHNlbnQgb3ZlciB0aGUgY29udHJvbCBjaGFubmVsIGFuZCBpcyANICAgdXNlZCB0 byByZXF1ZXN0IHRoZSBzdGF0dXMgb2Ygb25lIG9yIG1vcmUgZGF0YSBsaW5rKHMpIChwb3J0IG9y IA0gICBjb21wb25lbnQgbGluaykuICAgDSAgICANICAgQSBuZWlnaGJvcmluZyBub2RlIHRoYXQg cmVjZWl2ZXMgYSAgIENoYW5uZWxTdGF0dXNSZXEgbWVzc2FnZSBNVVNUIA0gICByZXNwb25kIHdp dGggYSAgQ2hhbm5lbFN0YXR1cyBtZXNzYWdlLiAgVGhlIGZvcm1hdCBpcyBhcyBmb2xsb3dzOiAN ICAgIA0gICA8IENoYW5uZWxTdGF0dXNSZXEgTWVzc2FnZT4gOjo9ICANICAgICAgICA8Q29tbW9u IEhlYWRlcj4gPCBDaGFubmVsU3RhdHVzUmVxPiANICAgIA0gICBUaGUgZm9ybWF0IG9mIHRoZSAg IENoYW5uZWxTdGF0dXNSZXEgb2JqZWN0IGlzIGFzIGZvbGxvd3M6IA0gICAgDSAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzIA0g ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIE1l c3NhZ2VJZCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCANICAgLy8gICAgICAgICAgICAgICAgICAgICAgICAoRW50aXR5IFRMVnMpICAgICAgICAg ICAgICAgICAgICAgICAgLy8gDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgIA0gICBNZXNz YWdlSWQ6ICAzMiBiaXRzIA0gICAgDSAgICAgICAgV2hlbiBjb21iaW5lZCB3aXRoIHRoZSBMb2Nh bCBURSBMaW5rIElkIGluIHRoZSBjb21tb24gaGVhZGVyIG9mIA0gICAgICAgIHRoZSByZWNlaXZl ZCBwYWNrZXQsIHRoZSBNZXNzYWdlSWQgZmllbGQgdW5pcXVlbHkgaWRlbnRpZmllcyBhIA0gICAg ICAgIG1lc3NhZ2UuICBUaGlzIHZhbHVlIGlzIGluY3JlbWVudGVkIGFuZCBvbmx5IGRlY3JlYXNl cyB3aGVuIHRoZSANICAgICAgICB2YWx1ZSB3cmFwcy4gIFRoaXMgaXMgdXNlZCBmb3IgbWVzc2Fn ZSBhY2tub3dsZWRnZW1lbnQgaW4gdGhlICAgDSAgICAgICAgQ2hhbm5lbFN0YXR1c1JlcUFjayBt ZXNzYWdlLiANIA1BICBDaGFubmVsU3RhdHVzUmVxIE1lc3NhZ2UgbWF5IGluY2x1ZGUgemVybyBv ciBtb3JlIEVudGl0eSBUTFZzLiAgSWYgDW5vIEVudGl0eSBUTFZzIGFyZSBpbmNsdWRlZCwgdGhl IHJlY2VpdmluZyBub2RlIG11c3QgcmVwb3J0IG9uIGFsbCANY29tcG9uZW50IGxpbmtzIHdpdGhp biB0aGUgVEUgbGluay4gDSAgICANMi40LjMuMS4gQ2hhbm5lbCBFbnRpdHkgVExWIA0gICAgDSAg ICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzIA0gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfDB8ICAgICAgICAgICBUQkQgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwgDSAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0gICB8ICAgICAgICAgICAgICAgICAgICAgTG9jYWwgSW50ZXJmYWNlIElkICAgICAgICAgICAg ICAgICAgICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgICANICAgVGhlIENoYW5uZWwgU3RhdHVzIFRM ViBpcyBub24tbmVnb3RpYWJsZS4gDSAgICANICAgTGVuZ3RoOiAgMTYgYml0cyANICAgIA0NICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE4XSANDA1JbnRlcm5ldCBEcmFmdCAgICAgICBkcmFmdC1tYW55LW9saS1yZXF0cy0w MC50eHQgICAgICAgICAgICBKdWx5IDIwMDEgDSANICAgICAgICBUaGUgTGVuZ3RoIGlzIGluIGJ5 dGVzIChzZWUgTE1QIFRMViBmb3JtYXQpLiANICAgIA0gICBMb2NhbCBJbnRlcmZhY2UgSWQ6ICAz MiBiaXRzIA0gICAgDSAgICAgICAgVGhpcyBpcyB0aGUgbG9jYWwgSW50ZXJmYWNlIElkIChlaXRo ZXIgUG9ydCBJZCBvciBDb21wb25lbnQgDSAgICAgICAgSW50ZXJmYWNlIElkKSBvZiB0aGUgZGF0 YSBsaW5rIGZvciB3aGljaCBzdGF0dXMgaXMgcmVxdWVzdGVkLiAgDSAgICAgICAgVGhpcyBpcyB3 aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBURSBMaW5rIElkLiAgIA0gICAgDSAgICANMi40LjMuMi4g R3JvdXAgRW50aXR5IFRMViANICAgIA0gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsg DSAgIHwwfCAgICAgICAgICAgVEJEICAgICAgICAgICAgICAgfCAgICAgICAgICAgICBMZW5ndGgg ICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExp bmsgR3JvdXAgSWQgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICAg DSAgIFRoZSBHcm91cCBTdGF0dXMgVExWIGlzIG5vbi1uZWdvdGlhYmxlLiANICAgIA0gICBMZW5n dGg6ICAxNiBiaXRzIA0gICAgDSAgICAgICAgVGhlIExlbmd0aCBpcyBpbiBieXRlcyAoc2VlIExN UCBUTFYgZm9ybWF0KS4gDSAgICANICAgTGluayBHcm91cCBJZDogIDMyIGJpdHMgDSAgICANICAg ICAgICBUaGUgTGluayBHcm91cCBJRCBmb3Igd2hpY2ggc3RhdHVzIGlzIHJlcXVlc3RlZC4gIFRo aXMgaXMgDSAgICAgICAgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgVEUgTGluayBJZC4gICANICAg IA0gICAgDVNvLCBob3cgZG9lcyBmYXVsdCBub3RpZmljYXRpb24gd29yaz8NDTIuNS4gVHJhY2Ug TW9uaXRvcmluZyANIA0gICBUaGUgdHJhY2UgbW9uaXRvcmluZyBmZWF0dXJlcyBkZXNjcmliZWQg aW4gdGhpcyBzZWN0aW9uLCBhbGxvdyB0aGUgDSAgIFBYQyB0byBkbyBiYXNpYyB0cmFjZSBtb25p dG9yaW5nIG9uIGNpcmN1aXRzIGJ5IHVzaW5nIHRoZSANICAgY2FwYWJpbGl0aWVzIG9uIHRoZSBh dHRhY2hlZCBPTFNzIA0gICAgDSAgICAgLiBBbiBPTFMgQ2xpZW50IHRvIHJlcXVlc3RzIHRoZSBP TFMgdG8gbW9uaXRvciBhIGxpbmsgZm9yIGEgDSAgICAgICAgc3BlY2lmaWMgcGF0dGVybiBpbiB0 aGUgb3ZlcmhlYWQgdXNpbmcgdGhlIFRyYWNlTW9uaXRvclJlcSANICAgICAgICBNZXNzYWdlLiAg QW4gZXhhbXBsZSBvZiB0aGlzIG92ZXJoZWFkIGlzIHRoZSBTT05FVCBTZWN0aW9uIA0gICAgICAg IFRyYWNlIG1lc3NhZ2UgdHJhbnNtaXR0ZWQgaW4gdGhlIEowIGJ5dGUuICBJZiB0aGUgYWN0dWFs IHRyYWNlIA0gICAgICAgIG1lc3NhZ2UgZG9lcyBub3QgbWF0Y2ggdGhlIGV4cGVjdGVkIHRyYWNl IG1lc3NhZ2UsIHRoZSBPTFMgbXVzdCANICAgICAgICByZXBvcnQgdGhlIG1pc21hdGNoIGNvbmRp dGlvbi4gDSAgICANICAgICAuIEFuIE9MUyBjbGllbnQgbWF5IHJlcXVlc3QgdGhlIHZhbHVlIG9m IHRoZSBjdXJyZW50IHRyYWNlIA0gICAgICAgIG1lc3NhZ2Ugb24gYSBnaXZlbiBwb3J0IHVzaW5n IHRoZSBUcmFjZVJlcSBNZXNzYWdlLiANICAgICAgDSANMi41LjEuIFRyYWNlTW9uaXRvciBNZXNz YWdlIChNc2dUeXBlID0gVEJEKSANICAgIA0NDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxOV0gDQwNSW50ZXJuZXQgRHJh ZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAgICAgICAgSnVseSAyMDAx IA0gDSAgIFRoZSBUcmFjZU1vbml0b3IgbWVzc2FnZSBpcyBzZW50IG92ZXIgdGhlIGNvbnRyb2wg Y2hhbm5lbCBhbmQgaXMgDSAgIHVzZWQgdG8gcmVxdWVzdCBhbiBPTFMgdG8gbW9uaXRvciBhIG9u ZSBvciBtb3JlIGNvbXBvbmVudCBsaW5rcyBmb3IgDSAgIGEgc3BlY2lmaWMgdHJhY2UgdmFsdWUu ICBBbiBPTFMgbXVzdCByZXNwb25kIHRvIGEgVHJhY2VNb25pdG9yIA0gICBtZXNzYWdlIHdpdGgg ZWl0aGVyIGEgVHJhY2VNb25pdG9yQWNrIG9yIFRyYWNlTW9uaXRvck5hY2sgTWVzc2FnZS4gDSAg ICANICAgIA0gICA8VHJhY2VNb25pdG9yIE1lc3NhZ2U+IDo6PSA8Q29tbW9uIEhlYWRlcj4gPFRy YWNlTW9uaXRvcj4gDSAgICANICAgVGhlIGZvcm1hdCBvZiB0aGUgVHJhY2VNb25pdG9yIG9iamVj dCBpcyBhcyBmb2xsb3dzOiANICAgIA0gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsg DSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlSWQgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgIC8vICAgICAgICAgICAg ICAgICAgICAgICAgIChUcmFjZSBUTFZzKSAgICAgICAgICAgICAgICAgICAgICAgIC8vIA0gICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDSAgICANICAgTWVzc2FnZUlkOiAgMzIgYml0cyANICAgIA0g ICAgICAgIFdoZW4gY29tYmluZWQgd2l0aCB0aGUgTG9jYWwgVEUgTGluayBJZCBpbiB0aGUgY29t bW9uIGhlYWRlciBvZiANICAgICAgICB0aGUgcmVjZWl2ZWQgcGFja2V0LCB0aGUgTWVzc2FnZUlk IGZpZWxkIHVuaXF1ZWx5IGlkZW50aWZpZXMgYSANICAgICAgICBtZXNzYWdlLiAgVGhpcyB2YWx1 ZSBpcyBpbmNyZW1lbnRlZCBhbmQgb25seSBkZWNyZWFzZXMgd2hlbiB0aGUgDSAgICAgICAgdmFs dWUgd3JhcHMuICBUaGlzIGlzIHVzZWQgZm9yIG1lc3NhZ2UgYWNrbm93bGVkZ2VtZW50IGluIHRo ZSANICAgICAgICBDaGFubmVsU3RhdHVzQWNrIG1lc3NhZ2UuIA0gDSAgIFRoZSBDaGFubmVsU3Rh dHVzIG1lc3NhZ2UgbXVzdCBpbmNsdWRlIGF0IGxlYXN0IG9uZSBTdGF0dXMgVExWLiAgVG8gDSAg IHNwZWNpZnkgYSBzdGF0dXMgZm9yIHRoZSB3aG9sZSBURSBMaW5rLCB1c2UgdGhlIGdyb3VwIHN0 YXR1cyBUTFYgYW5kIA0gICBsaW5rIGdyb3VwIDB4RkZGRkZGRkYuICANICAgIA0yLjUuMS4xLiBT T05FVCBTZWN0aW9uIFRyYWNlIFRMViANICAgIA0gICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsgDSAgIHwwfCAgICAgICAgICAgVEJEICAgICAgICAgICAgICAgfCAgICAgICAgICAgICBM ZW5ndGggICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAg IExvY2FsIEludGVyZmFjZSBJZCAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBUcmFjZSBNZXNzYWdlICAgICAgICAgICAg ICAgICAgICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgICANICAgVGhlIENoYW5uZWwgU3RhdHVzIFRM ViBpcyBub24tbmVnb3RpYWJsZS4gDSAgICANICAgTGVuZ3RoOiAgMTYgYml0cyANICAgIA0gICAg ICAgIFRoZSBMZW5ndGggaXMgaW4gYnl0ZXMgKHNlZSBMTVAgVExWIGZvcm1hdCkuIA0gICAgDSAg IExvY2FsIEludGVyZmFjZSBJZDogIDMyIGJpdHMgDQ0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdIA0MDUludGVybmV0 IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkg MjAwMSANIA0gICAgDSAgICAgICAgVGhpcyBpcyB0aGUgbG9jYWwgSW50ZXJmYWNlIElkIChlaXRo ZXIgUG9ydCBJZCBvciBDb21wb25lbnQgDSAgICAgICAgSW50ZXJmYWNlIElkKSBvZiB0aGUgZGF0 YSBsaW5rIGZvciB3aGljaCB0aGUgdHJhY2UgbW9uaXRvcmluZyANICAgICAgICBpcyByZXF1ZXN0 ZWQuICBUaGlzIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIFRFIExpbmsgSWQuICAgDSAgICAN ICAgVHJhY2UgTWVzc2FnZTogIDMyIGJpdHMgDSAgICANICAgICAgICAzMiBiaXQgU09ORVQgc2Vj dGlvbiB0cmFjZSB2YWx1ZS4gDSAgICANMi41LjEuMi4gVHJhY2UgVExWIA0gICAgDSAgICAwICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz IA0gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfDB8ICAgICAgICAgICBUQkQgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICB8 ICAgICAgICAgICAgICAgICAgICAgTG9jYWwgSW50ZXJmYWNlIElkICAgICAgICAgICAgICAgICAg ICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDSAgIHwgICAgICAgICAgIFRyYWNlIFR5cGUgICAgICAgICAg fCAgICAgICAgICBUcmFjZSBMZW5ndGggICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgDSAgIC8vICAgICAgICAgICAgICAgICAgICAgICAgIFRyYWNlIE1lc3NhZ2UgICAgICAgICAg ICAgICAgICAgICAgIC8vIA0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgICANICAgVGhlIENo YW5uZWwgU3RhdHVzIFRMViBpcyBub24tbmVnb3RpYWJsZS4gDSAgICANICAgTGVuZ3RoOiAgMTYg Yml0cyANICAgIA0gICAgICAgIFRoZSBMZW5ndGggaXMgaW4gYnl0ZXMgKHNlZSBMTVAgVExWIGZv cm1hdCkuIA0gICAgDSAgIExvY2FsIEludGVyZmFjZSBJZDogIDMyIGJpdHMgDSAgICANICAgICAg ICBUaGlzIGlzIHRoZSBsb2NhbCBJbnRlcmZhY2UgSWQgKGVpdGhlciBQb3J0IElkIG9yIENvbXBv bmVudCANICAgICAgICBJbnRlcmZhY2UgSWQpIG9mIHRoZSBkYXRhIGxpbmsgZm9yIHdoaWNoIHRo ZSB0cmFjZSBtb25pdG9yaW5nIA0gICAgICAgIGlzIHJlcXVlc3RlZC4gIFRoaXMgaXMgd2l0aGlu IHRoZSBzY29wZSBvZiB0aGUgVEUgTGluayBJZC4gICANICAgIA0gICBUcmFjZSBUeXBlOiAxNiBi aXRzIA0gICAgDSAgICAgICAgVGhlIHR5cGUgb2YgdGhlIHRyYWNlIG1lc3NhZ2U6IA0gICAgICAg ICANICAgICAgICAxIJYgU09ORVQgU2VjdGlvbiBUcmFjZSAoSjAgQnl0ZSkgDSAgICAgICAgMiCW IFNPTkVUIFBhdGggVHJhY2UgKEoxIEJ5dGUpIA0gICAgICAgIDMgliBTREggU2VjdGlvbiBUcmFj ZSAoSjAgQnl0ZSkgDSAgICAgICAgNCCWIFNESCBQYXRoIFRyYWNlIChKMSBCeXRlKSANDVdoeSB3 b3VsZCB0aGUgV0RNIHN5c3RlbSBsb29rIGF0IHRoZSBwYXRoIHRyYWNlPyBUaGUgaWRlYSBvZiBw YXRoIHRyYWNlIGlzIHRvIHRyYWNlIGFuIGVudGlyZSBwYXRoLg0gICAgICAgICANICAgICAgICBP dGhlciB0eXBlcyBUQkQuIA0gICAgDSAgIFRyYWNlIExlbmd0aDogIDE2IGJpdHMgDSAgICANICAg ICAgICBUaGUgTGVuZ3RoIGluIGJ5dGVzIG9mIHRoZSB0cmFjZSBtZXNzYWdlIHByb3ZpZGVkLiAN DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAyMV0gDQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVx dHMtMDAudHh0ICAgICAgICAgICAgSnVseSAyMDAxIA0gDSAgICANICAgVHJhY2UgTWVzc2FnZTog DSAgICANICAgICAgICBFeHBlY3RlZCBtZXNzYWdlLiAgVGhlIHZhbGlkIGxlbmd0aCBhbmQgdmFs dWUgYXJlIGRldGVybWluZWQgYnkgDSAgICAgICAgdGhlIHNwZWNpZmljIHRlY2hub2xvZ3kgKGUu Zy4sIFNPTkVUIG9yIFNESCkgYW5kIGFyZSBiZXlvbmQgdGhlIA0gICAgICAgIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuICBUaGUgbWVzc2FnZSBtdXN0IGJlIHBhZGRlZCB3aXRoIHplcm9zIA0gICAg ICAgIHRvIGEgMzItYml0IGJvdW5kYXJ5LCBpZiBuZWNlc3NhcnkuIA0gICAgDTIuNS4yLiBUcmFj ZU1vbml0b3JBY2sgTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCkgDSAgICANICAgVGhlIFRyYWNlTW9u aXRvckFjayBtZXNzYWdlIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBhbGwgb2YgdGhlIA0gICBU cmFjZSBUTFZzIGluIHRoZSBUcmFjZU1vbml0b3IgbWVzc2FnZSBoYXZlIGJlZW4gcmVjZWl2ZWQg YW5kIA0gICBwcm9jZXNzZWQgY29ycmVjdGx5LiANICAgIA0gICBUaGUgZm9ybWF0IGlzIGFzIGZv bGxvd3M6ICAgICAgICAgICANICAgPFRyYWNlTW9uaXRvckFjayBNZXNzYWdlPiA6Oj0gPENvbW1v biBIZWFkZXI+IDxUcmFjZU1vbml0b3JBY2s+ICANICAgIA0gICBUaGUgVHJhY2VNb25pdG9yQWNr IG9iamVjdCBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6ICANICAgIA0gICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyAgDSAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyAgDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3Nh Z2VJZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICB8ICAg ICAgICAgICAgICAgICAgICAgIFJlbW90ZSBURSBMaW5rIElkICAgICAgICAgICAgICAgICAgICAg ICAgfCAgDSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rICANICAgIA0gICBNZXNzYWdlSWQ6ICAzMiBiaXRzICANICAgIA0g ICAgICAgIFRoaXMgaXMgY29waWVkIGZyb20gdGhlIENoYW5uZWxTdGF0dXMgbWVzc2FnZSBiZWlu ZyANICAgICAgICBhY2tub3dsZWRnZWQuICANICAgIA0gICBSZW1vdGUgVEUgTGluayBJZDogMzIg Yml0cyANICAgIA0gICAgICAgIFRoaXMgaXMgY29waWVkIGZyb20gdGhlIENvbW1vbiBIZWFkZXIg b2YgdGhlIENoYW5uZWxTdGF0dXMgDSAgICAgICAgbWVzc2FnZSBiZWluZyBhY2tub3dsZWRnZWQu IA0gICAgDTIuNS4zLiBUcmFjZU1vbml0b3JOYWNrIE1lc3NhZ2UgKE1zZ1R5cGUgPSBUQkQpIA0g ICAgDSAgIFRoZSBUcmFjZU1vbml0b3JOYWNrIG1lc3NhZ2UgaXMgdXNlZCB0byBpbmRpY2F0ZSB0 aGF0IG9uZSBvciBtb3JlIG9mIA0gICB0aGUgVHJhY2UgVExWcyBpbiB0aGUgVHJhY2VNb25pdG9y IG1lc3NhZ2Ugd2FzIG5vdCBwcm9jZXNzZWQgDSAgIGNvcnJlY3RseS4gIFRoaXMgY291bGQgYmUg YmVjYXVzZSB0aGUgdHJhY2UgbW9uaXRvcmluZyByZXF1ZXN0ZWQgaXMgDSAgIG5vdCBzdXBwb3J0 ZWQgb3IgdGhlcmUgd2FzIGFuIGVycm9yIGluIG9uZSBvZiB0aGUgdmFsdWVzLiANDVdoYXQgZXJy b3I/IEEgdHJhY2UgaXMganVzdCBhIGNvbGxlY3Rpb24gb2YgYml0cyBhcyBkZWZpbmVkIGhlcmUu IFdoYXQgZG9lcyBpdCBtZWFuIGJ5IGFuIGVycm9yIGluIHRoaXMgY2FzZT8NICAgIA0gICBUaGUg Zm9ybWF0IGlzIGFzIGZvbGxvd3M6ICAgICAgICAgICANICAgPFRyYWNlTW9uaXRvck5hY2sgTWVz c2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiA8VHJhY2VNb25pdG9yTmFjaz4gIA0gICAgDSAgIFRo ZSBUcmFjZU1vbml0b3JOYWNrIG9iamVjdCBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6ICANICAg IA0NDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMjJdIA0MDUludGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xp LXJlcXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkgMjAwMSANIA0gICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyAgDSAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyAgDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VJ ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0gICB8ICAgICAg ICAgICAgICAgICAgICAgIFJlbW90ZSBURSBMaW5rIElkICAgICAgICAgICAgICAgICAgICAgICAg fCAgDSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rICANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgIC8vICAgICAgICAgICAgICAgICAgIChS ZWplY3RlZCBUcmFjZSBUTFZzKSAgICAgICAgICAgICAgICAgICAgIC8vIA0gICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAN ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsgDSAgICANICAgTWVzc2FnZUlkOiAgMzIgYml0cyAgDSAgICANICAgICAgICBU aGlzIGlzIGNvcGllZCBmcm9tIHRoZSBDaGFubmVsU3RhdHVzIG1lc3NhZ2UgYmVpbmcgDSAgICAg ICAgYWNrbm93bGVkZ2VkLiAgDSAgICANICAgUmVtb3RlIFRFIExpbmsgSWQ6IDMyIGJpdHMgDSAg ICANICAgICAgICBUaGlzIGlzIGNvcGllZCBmcm9tIHRoZSBDb21tb24gSGVhZGVyIG9mIHRoZSBD aGFubmVsU3RhdHVzIA0gICAgICAgIG1lc3NhZ2UgYmVpbmcgYWNrbm93bGVkZ2VkLiANICAgIA0g ICBSZWplY3RlZCBUcmFjZSBUTFZzOiAzMiBiaXRzIA0gICAgDSAgICAgICAgVHJhY2UgVExWcyB0 aGF0IHdlcmUgbm90IGFjY2VwdGVkLiAgQ29waWVkIGZyb20gVHJhY2VNb25pdG9yIA0gICAgICAg IG1lc3NhZ2UuICBJZiBub25lIGFyZSBpbmNsdWRlZCwgaXQgbWVhbnMgdGhhdCBhbGwgVHJhY2Ug VExWcyANICAgICAgICBhcmUgcmVqZWN0ZWQuIA0gICAgDSAgICANMi41LjQuIFRyYWNlTWlzbWF0 Y2ggTWVzc2FnZSAoTXNnVHlwZSA9IFRCRCkgDSAgICANICAgVGhlIFRyYWNlTWlzbWF0Y2ggbWVz c2FnZSBpcyBzZW50IG92ZXIgdGhlIGNvbnRyb2wgY2hhbm5lbCBhbmQgaXMgDSAgIHVzZWQgdG8g cmVwb3J0IGEgdHJhY2UgbWlzbWF0Y2ggb24gYSBjb21wb25lbnQgbGluayBmb3Igd2hpY2ggdHJh Y2UgDSAgIG1vbml0b3Jpbmcgd2FzIHJlcXVlc3RlZC4gDSAgICANICAgQSBuZWlnaGJvcmluZyBu b2RlIHRoYXQgcmVjZWl2ZXMgYSBUcmFjZU1pc21hdGNoIG1lc3NhZ2UgTVVTVCANICAgcmVzcG9u ZCB3aXRoIGEgVHJhY2VNaXNtYXRjaEFjayBtZXNzYWdlLiAgVGhlIGZvcm1hdCBpcyBhcyBmb2xs b3dzOiANDUkgdGhpbmsgaW4gYWxsIHRoZXNlIGRlc2NyaXB0aW9ucywgeW91IGNhbiBiZSBleHBs aWNpdCBhYm91dCB3aGljaCBub2RlIChPWEMgb3IgV0RNKSBzZW5kcyB3aGF0IG1lc3NhZ2UsIHNp bmNlIHRoZSByb2xlcyBhcmUgZml4ZWQuIA0gICAgDSAgIDxUcmFjZU1pc21hdGNoIE1lc3NhZ2U+ IDo6PSA8Q29tbW9uIEhlYWRlcj4gPFRyYWNlTWlzbWF0Y2g+IA0gICAgDSAgIFRoZSBmb3JtYXQg b2YgdGhlIFRyYWNlTWlzbWF0Y2ggb2JqZWN0IGlzIGFzIGZvbGxvd3M6IA0gICAgDQ0NDQ0NDQ0N DQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMjNdIA0MDUludGVybmV0IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJl cXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkgMjAwMSANIA0gICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAN ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsgDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlSWQgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgIC8v ICAgICAgICAgICAgICAgICAgICAgTG9jYWwgSW50ZXJmYWNlIElkcyAgICAgICAgICAgICAgICAg ICAgIC8vIA0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDSAgICANICAgTWVzc2FnZUlkOiAgMzIg Yml0cyANICAgIA0gICAgICAgIFdoZW4gY29tYmluZWQgd2l0aCB0aGUgTG9jYWwgVEUgTGluayBJ ZCBpbiB0aGUgY29tbW9uIGhlYWRlciBvZiANICAgICAgICB0aGUgcmVjZWl2ZWQgcGFja2V0LCB0 aGUgTWVzc2FnZUlkIGZpZWxkIHVuaXF1ZWx5IGlkZW50aWZpZXMgYSANICAgICAgICBtZXNzYWdl LiAgVGhpcyB2YWx1ZSBpcyBpbmNyZW1lbnRlZCBhbmQgb25seSBkZWNyZWFzZXMgd2hlbiB0aGUg DSAgICAgICAgdmFsdWUgd3JhcHMuICBUaGlzIGlzIHVzZWQgZm9yIG1lc3NhZ2UgYWNrbm93bGVk Z2VtZW50IGluIHRoZSANICAgICAgICBDaGFubmVsU3RhdHVzQWNrIG1lc3NhZ2UuIA0gICAgDSAg IExvY2FsIEludGVyZmFjZSBJZDogIDMyIGJpdHMgcGVyIElkICANICAgIA0gICAgICAgIFRoaXMg aXMgdGhlIGxvY2FsIEludGVyZmFjZSBJZCAoZWl0aGVyIFBvcnQgSWQgb3IgQ29tcG9uZW50IA0g ICAgICAgIEludGVyZmFjZSBJZCkgb2YgdGhlIGRhdGEgbGluayB0aGF0IGhhcyBhIHRyYWNlIG1p c21hdGNoLiAgVGhpcyANICAgICAgICBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBURSBMaW5r IElkLiAgTXVsdGlwbGUgTG9jYWwgDSAgICAgICAgSW50ZXJmYWNlIElkcyBtYXkgYmUgcmVwb3J0 ZWQgaW4gdGhlIHNhbWUgbWVzc2FnZS4gDSAgICANMi41LjUuIFRyYWNlTWlzbWF0Y2hBY2sgTWVz c2FnZSAoTXNnVHlwZSA9IFRCRCkgDSAgICANICAgVGhlIFRyYWNlTWlzbWF0Y2hBY2sgbWVzc2Fn ZSBpcyB1c2VkIHRvIGFja25vd2xlZGdlIHJlY2VpcHQgb2YgYSANICAgVHJhY2VNaXNtYXRjaCBt ZXNzYWdlLiANICAgIA0gICBUaGUgZm9ybWF0IGlzIGFzIGZvbGxvd3M6ICANICAgPFRyYWNlTWlz bWF0Y2hBY2sgTWVzc2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiA8VHJhY2VNaXNtYXRjaEFjaz4g IA0gICAgDSAgIFRoZSBUcmFjZU1pc21hdGNoQWNrIG9iamVjdCBoYXMgdGhlIGZvbGxvd2luZyBm b3JtYXQ6ICANICAgIA0gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMyAgDSAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgIA0gICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDSAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VJZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICANICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgIA0gICB8ICAgICAgICAgICAgICAgICAgICAgIFJlbW90ZSBU RSBMaW5rIElkICAgICAgICAgICAgICAgICAgICAgICAgfCAgDSAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANICAgIA0g ICBNZXNzYWdlSWQ6ICAzMiBiaXRzICANICAgIA0gICAgICAgIFRoaXMgaXMgY29waWVkIGZyb20g dGhlIENoYW5uZWxTdGF0dXMgbWVzc2FnZSBiZWluZyANICAgICAgICBhY2tub3dsZWRnZWQuICAN ICAgIA0gICBSZW1vdGUgVEUgTGluayBJZDogMzIgYml0cyANICAgIA0NDSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNF0g DQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMtMDAudHh0ICAgICAg ICAgICAgSnVseSAyMDAxIA0gDSAgICAgICAgVGhpcyBpcyBjb3BpZWQgZnJvbSB0aGUgQ29tbW9u IEhlYWRlciBvZiB0aGUgQ2hhbm5lbFN0YXR1cyANICAgICAgICBtZXNzYWdlIGJlaW5nIGFja25v d2xlZGdlZC4gDSAgICANICAgIA0yLjUuNi4gVHJhY2VSZXEgTWVzc2FnZSAoTXNnVHlwZSA9IFRC RCkgDSAgICANICAgVGhlIFRyYWNlUmVxIG1lc3NhZ2UgaXMgc2VudCBvdmVyIHRoZSBjb250cm9s IGNoYW5uZWwgYW5kIGlzIHVzZWQgdG8gDSAgIHJlcXVlc3QgdGhlIGN1cnJlbnQgdHJhY2UgdmFs dWUgb2YgaW5kaWNhdGVkIGNvbXBvbmVudCBsaW5rcy4gDSAgICANICAgQSBub2RlIHRoYXQgcmVj ZWl2ZXMgYSBUcmFjZVJlcSBtZXNzYWdlIE1VU1QgcmVzcG9uZCB3aXRoIGEgDSAgIFRyYWNlUmVw b3J0IG1lc3NhZ2UuICBUaGUgZm9ybWF0IGlzIGFzIGZvbGxvd3M6IA0gICAgDSAgIDxUcmFjZVJl cSBNZXNzYWdlPiA6Oj0gPENvbW1vbiBIZWFkZXI+IDxUcmFjZVJlcT4gDSAgICANICAgVGhlIGZv cm1hdCBvZiB0aGUgVHJhY2VSZXEgb2JqZWN0IGlzIGFzIGZvbGxvd3M6IA0gICAgDSAgICAwICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz IA0gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IE1lc3NhZ2VJZCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCANICAgLy8gICAgICAgICAgICAgICAgICAgICAgICAoRW50aXR5IFRMVnMpICAgICAg ICAgICAgICAgICAgICAgICAgLy8gDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgIA0gICBN ZXNzYWdlSWQ6ICAzMiBiaXRzIA0gICAgDSAgICAgICAgV2hlbiBjb21iaW5lZCB3aXRoIHRoZSBM b2NhbCBURSBMaW5rIElkIGluIHRoZSBjb21tb24gaGVhZGVyIG9mIA0gICAgICAgIHRoZSByZWNl aXZlZCBwYWNrZXQsIHRoZSBNZXNzYWdlSWQgZmllbGQgdW5pcXVlbHkgaWRlbnRpZmllcyBhIA0g ICAgICAgIG1lc3NhZ2UuICBUaGlzIHZhbHVlIGlzIGluY3JlbWVudGVkIGFuZCBvbmx5IGRlY3Jl YXNlcyB3aGVuIHRoZSANICAgICAgICB2YWx1ZSB3cmFwcy4gIFRoaXMgaXMgdXNlZCBmb3IgbWVz c2FnZSBhY2tub3dsZWRnZW1lbnQgaW4gdGhlICAgDSAgICAgICAgVHJhY2VSZXBvcnQgbWVzc2Fn ZS4gDSANICAgQSAgVHJhY2VSZXEgTWVzc2FnZSBtYXkgaW5jbHVkZSB6ZXJvIG9yIG1vcmUgRW50 aXR5IFRMVnMgKGFzIA0gICBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQuMykuICBJZiBubyBFbnRp dHkgVExWcyBhcmUgaW5jbHVkZWQsIHRoZSANICAgcmVjZWl2aW5nIG5vZGUgbXVzdCByZXBvcnQg b24gYWxsIGNvbXBvbmVudCBsaW5rcyB3aXRoaW4gdGhlIFRFIA0gICBsaW5rLiANICAgIA0gICAg DTIuNS43LiBUcmFjZVJlcG9ydCBNZXNzYWdlIChNc2dUeXBlID0gVEJEKSANICAgIA0gICBUaGUg VHJhY2VSZXBvcnQgbWVzc2FnZSBpcyBzZW50IG92ZXIgdGhlIGNvbnRyb2wgY2hhbm5lbCBhZnRl ciANICAgcmVjZWl2aW5nIGEgVHJhY2VSZXEgbWVzc2FnZS4gDSAgICANICAgIA0gICA8VHJhY2VS ZXBvcnQgTWVzc2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiA8VHJhY2VSZXBvcnQ+IA0gICAgDSAg IFRoZSBmb3JtYXQgb2YgdGhlIFRyYWNlUmVwb3J0IG9iamVjdCBpcyBhcyBmb2xsb3dzOiANICAg IA0NDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAyNV0gDQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGkt cmVxdHMtMDAudHh0ICAgICAgICAgICAgSnVseSAyMDAxIA0gDSAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzIA0gICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyANICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VJZCAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgDSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0gICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANICAg Ly8gICAgICAgICAgICAgICAgICAgICAgICAgKFRyYWNlIFRMVnMpICAgICAgICAgICAgICAgICAg ICAgICAgLy8gDSAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IA0gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANICAgIA0gICBNZXNzYWdlSWQ6ICAz MiBiaXRzIA0gICAgDSAgICAgICAgVGhpcyBpcyBjb3BpZWQgZnJvbSB0aGUgVHJhY2VSZXEgbWVz c2FnZSBiZWluZyBhY2tub3dsZWRnZWQuICANIA0gICBUaGUgVHJhY2VSZXBvcnQgbWVzc2FnZSBt dXN0IGluY2x1ZGUgYSBUcmFjZSBUTFYgKGFzIGRlc2NyaWJlZCBpbiANICAgU2VjdGlvbiAyLjUu MSkgZm9yIGVhY2ggbGluayByZXF1ZXN0ZWQuIA0gICAgDSAgICANMy4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgDSAgICANICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFyZSB0aGUgc2Ft ZSBhcyBpbiBbTE1QXS4gDSAgICANICAgIA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAyNl0gDQwNSW50ZXJuZXQgRHJhZnQgICAgICAgZHJhZnQtbWFueS1vbGktcmVxdHMt MDAudHh0ICAgICAgICAgICAgSnVseSAyMDAxIA0gDSAgICANNC4gUmVmZXJlbmNlcyANICAgIA0g ICBbR01QTFNdICAgICAgIEJlcmdlciwgTC4sIEFzaHdvb2QtU21pdGgsIFBldGVyLCBlZGl0b3Jz LCANICAgICAgICAgICAgICAgICAiR2VuZXJhbGl6ZWQgTVBMUyAtIFNpZ25hbGluZyBGdW5jdGlv bmFsIERlc2NyaXB0aW9uIiwgDSAgICAgICAgICAgICAgICAgSW50ZXJuZXQgRHJhZnQsIGRyYWZ0 LWlldGYtbXBscy1nZW5lcmFsaXplZC1zaWduYWxpbmctDSAgICAgICAgICAgICAgICAgMDIudHh0 LCAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMDEuIA0gICAgDSAgIFtCcmE5Nl0gICAgICAg QnJhZG5lciwgUy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0gDSAgICAgICAg ICAgICAgICAgUmV2aXNpb24gMywiIEJDUCA5LCBSRkMgMjAyNiwgT2N0b2JlciAxOTk2LiAgDSAg ICANICAgIFtEQkMwMF0gICAgICBEcmFrZSwgSi4sIEJsdW1lbnRoYWwsIEQuLCBDZXVwcGVucywg TC4sIGV0IGFsLiwgDSAgICAgICAgICAgICAgICAgIkludGVyd29ya2luZyBiZXR3ZWVuIFBob3Rv bmljIChPcHRpY2FsKSBTd2l0Y2hlcyBhbmQgDSAgICAgICAgICAgICAgICAgVHJhbnNtaXNzaW9u IFN5c3RlbXMgb3ZlciBPcHRpY2FsIExpbmsgSW50ZXJmYWNlIChPTEkpIA0gICAgICAgICAgICAg ICAgIHVzaW5nIEV4dGVuc2lvbnMgdG8gTE1QIiwgT0lGIENvbnRyaWJ1dGlvbiANICAgICAgICAg ICAgICAgICBvaWYyMDAwLjI1NCwgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDAwLiAN ICAgIA0gICBbS1JCMDBdICAgICAgIEtvbXBlbGxhLCBLLiwgUmVraHRlciwgWS4sIEJlcmdlciwg TC4sICJMaW5rIEJ1bmRsaW5nIA0gICAgICAgICAgICAgICAgIGluIE1QTFMgVHJhZmZpYyBFbmdp bmVlcmluZywiIEludGVybmV0IERyYWZ0LCBkcmFmdC0NICAgICAgICAgICAgICAgICBrb21wZWxs YS1tcGxzLWJ1bmRsZS0wMi50eHQsICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSANICAgICAgICAg ICAgICAgICAyMDAwLiAgDSAgICANICAgW0tSQjAwYV0gICAgICBLb21wZWxsYSwgSy4sIFJla2h0 ZXIsIFkuLCBCYW5lcmplZSwgQS4sIGV0IGFsLCAiT1NQRiANICAgICAgICAgICAgICAgICBFeHRl bnNpb25zIGluIFN1cHBvcnQgb2YgR2VuZXJhbGl6ZWQgTVBMUywiIEludGVybmV0IA0gICAgICAg ICAgICAgICAgIERyYWZ0LCBkcmFmdC1rb21wZWxsYS1vc3BmLWV4dGVuc2lvbnMtMDAudHh0LCAo d29yayBpbiANICAgICAgICAgICAgICAgICBwcm9ncmVzcyksIEp1bHkgMjAwMC4gIA0gICAgDSAg IFtMTVBdICAgICAgICAgTGFuZywgSi4sIE1pdHJhLCBLLiwgRHJha2UsIEouLCBLb21wZWxsYSwg Sy4sIFJla2h0ZXIsIA0gICAgICAgICAgICAgICAgIFkuLCBCZXJnZXIsIEwuLCBTYWhhLCBELiwg QmFzYWssIEQuLCBTYW5kaWNrLCBILiwgDSAgICAgICAgICAgICAgICAgWmluaW4sIEEuLCAiTGlu ayBNYW5hZ2VtZW50IFByb3RvY29sIChMTVApIiwgSW50ZXJuZXQgDSAgICAgICAgICAgICAgICAg RHJhZnQsIGRyYWZ0LWlldGYtbXBscy1sbXAtMDEudHh0LCAod29yayBpbiBwcm9ncmVzcyksIA0g ICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDAuIA0gICAgDSAgIFtPTEldICAgICAgICAgRnJl ZGV0dGUsIEEuLCBFZGl0b3IsICJPcHRpY2FsIExpbmsgSW50ZXJmYWNlIA0gICAgICAgICAgICAg ICAgIFJlcXVpcmVtZW50cyIsIEludGVybmV0IERyYWZ0LCBkcmFmdC1tYW55LW9saS1yZXF0cy0N ICAgICAgICAgICAgICAgICAwMC50eHQsICh3b3JrIGluIHByb2dyZXNzKSwgSnVuZSAyMDAxLiAN ICAgIA0gICBbU0RIXSAgICAgICAgIElUVS1UIEcuNzA3LCAiTmV0d29yayBub2RlIGludGVyZmFj ZSBmb3IgdGhlIA0gICAgICAgICAgICAgICAgIHN5bmNocm9ub3VzIGRpZ2l0YWwgaGllcmFyY2h5 IChTREgpIiwgMTk5Ni4gDSAgICANICAgW1NPTkVUXSAgICAgICBHUi0yNTMtQ09SRSwgIlN5bmNo cm9ub3VzIE9wdGljYWwgTmV0d29yayAoU09ORVQpIA0gICAgICAgICAgICAgICAgIFRyYW5zcG9y dCBTeXN0ZW1zOiBDb21tb24gR2VuZXJpYyBDcml0ZXJpYSIsIFRlbGNvcmRpYSANICAgICAgICAg ICAgICAgICBUZWNobm9sb2dpZXMsIElzc3VlIDMsIFNlcHRlbWJlciAyMDAwIA0gICAgDSAgIFtU LjUwXSAgICAgICAgSVRVLVQgVC41MCwgIkludGVybmF0aW9uYWwgUmVmZXJlbmNlIEFscGhhYmV0 IChJUkEpIA0gICAgICAgICAgICAgICAgIChmb3JtZXJseSBJbnRlcm5hdGlvbmFsIEFscGhhYmV0 IE5vLiA1IG9yIElBNSkgDSAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb24gdGVjaG5vbG9neSA3 LWJpdCBjb2RlZCBjaGFyYWN0ZXIgc2V0IGZvciANICAgICAgICAgICAgICAgICBpbmZvcm1hdGlv biBpbnRlcmNoYW5nZS4iLCAxOTkyLiANICAgIA0NDQ0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjddIA0MDUludGVybmV0 IERyYWZ0ICAgICAgIGRyYWZ0LW1hbnktb2xpLXJlcXRzLTAwLnR4dCAgICAgICAgICAgIEp1bHkg MjAwMSANIA01LiBBdXRob3IncyBBZGRyZXNzZXMgDSAgICANICAgIEFuZHJlIEZyZWRldHRlICAg ICAgICAgICAgICAgICAgICAgICAgICBFZCBTbnlkZXIgIA0gICAgUGhvdG9uRXggQ29ycG9yYXRp b24gICAgICAgICAgICAgICAgICAgIFBob3RvbkV4IENvcnBvcmF0aW9uICANICAgIDhDIFByZXN0 b24gQ291cnQgICAgICAgICAgICAgICAgICAgICAgICA4QyBQcmVzdG9uIENvdXJ0ICANICAgIEJl ZGZvcmQsIE1BICAwMTczMCAgICAgICAgICAgICAgICAgICAgICBCZWRmb3JkLCBNQSAgMDE3MzAg DSAgICBlbWFpbDogZnJlZGV0dGVAcGhvdG9uZXguY29tICAgICAgICAgICAgZW1haWw6IGVzbnlk ZXJAcGhvdG9uZXguY29tICANICAgIA0gICAgSmFnYW4gU2hhbnRpZ3JhbSAgICAgICAgICAgICAg ICAgICAgICAgIEpvbmF0aGFuIFAuIExhbmcgIA0gICAgUGhvdG9uRXggQ29ycG9yYXRpb24gICAg ICAgICAgICAgICAgICAgIENhbGllbnQgTmV0d29ya3MgIA0gICAgOEMgUHJlc3RvbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIENvdXJ0MjUgQ2FzdGlsaWFuIERyaXZlICANICAgIEJlZGZv cmQsIE1BICAwMTczMCAgICAgICAgICAgICAgICAgICAgICBHb2xldGEsIENBIDkzMTE3IA0gICAg ZW1haWw6IGphZ2FuQHBob3RvbmV4LmNvbSAgICAgICAgICAgICAgIGVtYWlsOiBqcGxhbmdAY2Fs aWVudC5uZXQgIA0gICAgDSAgICBKb2huIERyYWtlICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR29wYWxhIFR1bXVsdXJpIA0gICAgQ2FsaWVudCBOZXR3b3JrcyAgICAgICAgICAgICAgICAg ICAgICAgIENhbGllbnQgTmV0d29ya3MgIA0gICAgNTg1MyBSdWUgRmVycmFyaSAgICAgICAgICAg ICAgICAgICAgICAgIDU4NTMgUnVlIEZlcnJhcmkgIA0gICAgU2FuIEpvc2UsIENBIDk1MTM4ICAg ICAgICAgICAgICAgICAgICAgIFNhbiBKb3NlLCBDQSA5NTEzOCAgDSAgICBlbWFpbDogamRyYWtl QGNhbGllbnQubmV0ICAgICAgICAgICAgICAgZW1haWw6IGtyaXNobmFAY2FsaWVudC5uZXQgIA0g ICAgDSAgICBSb2hpdCBHb3lhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3R1YXJ0IEJy b3Jzb24gIA0gICAgQXhpb3dhdmUgTmV0d29ya3MgICAgICAgICAgICAgICAgICAgICAgIEF4aW93 YXZlIE5ldHdvcmtzICANICAgIDEwMCBOaWNrZXJzb24gUm9hZCAgICAgICAgICAgICAgICAgICAg ICAxMDAgTmlja2Vyc29uIFJvYWQgIA0gICAgTWFybGJvcm91Z2gsIE1BIDAxNzUyICAgICAgICAg ICAgICAgICAgIE1hcmxib3JvdWdoLCBNQSAwMTc1MiANICAgIGVtYWlsOiByZ295YWxAYXhpb3dh dmUuY29tICAgICAgICAgICAgICBlbWFpbDogc2RiQGF4aW93YXZlLmNvbSAgDSAgICANICAgIFJh bSBLcmlzaG5hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBMLiBFZHdhcmRzIA0gICAg QXhpb3dhdmUgTmV0d29ya3MgICAgICAgICAgICAgICAgICAgICAgIGlMYW1iZGEgTmV0d29ya3Mg IA0gICAgMTAwIE5pY2tlcnNvbiBSb2FkICAgICAgICAgICAgICAgICAgICAgIEFzcGVuLCBDTyAg DSAgICBNYXJsYm9yb3VnaCwgTUEgMDE3NTIgICAgICAgICAgICAgICAgICAgZW1haWw6IHRleGFz QGlsYW1iZGEuY29tICANICAgIGVtYWlsOiByYW1AYXhpb3dhdmUuY29tIA0gICAgDSAgICBZb25n IFh1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBZdSANICAgIFVVTkVUL1dv cmxkQ29tICAgICAgICAgICAgICAgICAgICAgICAgICBaYWZmaXJlLCBJbmMgDSAgICAyMjAwMSBM b3Vkb3VuIENvdW50eSBQYXJrd2F5ICAgICAgICAgICAgMjYzMCBPcmNoYXJkIFBhcmt3YXkgDSAg ICBBc2hidXJuLCBWQSAyMDE0OCAgICAgICAgICAgICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1 MTM0IA0gICAgZW1haWw6IHl4dWVAdXUubmV0ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBq enl1QHphZmZpcmUuY29tIA0gICAgDSAgICBTdWRoZWVyIERoYXJhbmlrb3RhIA0gICAgTmF5bmEg TmV0d29ya3MsIEluYy4gDSAgICAxNTcgVG9wYXogRHJpdmUsIA0gICAgTWlscGl0YXMsIENBIDk1 MDM1IA0gICAgZW1haWw6IHN1ZGhlZXJAbmF5bmEuY29tIA0gDSANICAgIA0NDQ0NDQ0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMjhdIA0MDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABNLwAA5i8AABYwAAAEMQAA1DMAAAA0AAAGNAAANjQA AEc0AABJNAAAUTQAAFQ0AABcNAAAZjQAAHc0AAB6NAAAgDQAAIw0AACfNAAARDYAAL42AADUNgAA 3TYAAOM2AAD2NgAAeTcAAI05AACPOQAAwUEAACJCAADKQgAAy0IAAM5CAAD0QgAA9UIAAIRDAADu RAAA8EQAAIBFAACYRQAAxkUAAAD27fYA7eTt5Nvk2+Tb5Nvk2+QA5NLkydLJAMAAt66lrqWckwCK gXhvAAAAAAAAAAAAAAAAABEBCIEESAEABWim7FcGB0gAABEBCIEESAEABWil7FcGB0gAABEBCIEE SAEABWik7FcGB0gAABEBCIEESAEABWij7FcGB0gAABEBCIEESAEABWgF7VcGB0gAABEBCIEESAEA BWiu7FcGB0gAABEBCIEESAEABWid7FcGB0gAABEBCIEESAEABWic7FcGB0gAABEBCIEESAEABWib 7FcGB0gAABEBCIEESAEABWhZ7FcGB0gAABEBCIEESAEABWhh7FcGB0gAABEBCIEESAEABWhi7FcG B0gAABEBCIEESAEABWhi7VcGB0gAABEBCIEESAEABWhf7FcGB0gAABEBCIEESAEABWhe7FcGB0gA ABEBCIEESAEABWhd7FcGB0gAAAApAAQAAAEEAAACBAAASwQAAJQEAADdBAAAJgUAAG8FAAC4BQAA AQYAAEoGAACTBgAA3AYAACUHAABuBwAAtwcAAOEHAAAqCAAAcwgAALwIAAAFCQAACgkAAE8JAAB2 CQAArAkAANMJAADYCQAA7QkAAPIJAAA5CgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQ8AAB0ABAAAAQQAAAIEAABLBAAAlAQAAN0EAAAmBQAAbwUAALgFAAAB BgAASgYAAJMGAADcBgAAJQcAAG4HAAC3BwAA4QcAACoIAABzCAAAvAgAAAUJAAAKCQAATwkAAHYJ AACsCQAA0wkAANgJAADtCQAA8gkAADkKAABwCgAAdQoAALsKAAD/CgAAQgsAAE4LAABTCwAAlgsA AN8LAAAfDAAAaAwAAG0MAACoDAAA1wwAANwMAAAhDQAARg0AAEcNAABIDQAASQ0AAEoNAABLDQAA TA0AAE0NAABODQAAlg0AAJgNAADfDQAA4Q0AAOsNAAAsDgAAaQ4AALEOAAD0DgAAOA8AAIAPAADH DwAADhAAAFMQAACaEAAA3BAAACMRAABsEQAAkhEAAJQRAACeEQAA5xEAADASAAB5EgAAwhIAAAsT AABUEwAAnRMAAOYTAAAvFAAAeBQAAMEUAAAKFQAAUxUAAJwVAADlFQAALhYAAHcWAADAFgAACRcA AFIXAACbFwAA5BcAAC0YAAB2GAAAvxgAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v4AAAAAAgEBZDkKAABwCgAAdQoAALsKAAD/CgAAQgsAAE4LAABTCwAAlgsAAN8L AAAfDAAAaAwAAG0MAACoDAAA1wwAANwMAAAhDQAARg0AAEcNAABIDQAASQ0AAEoNAABLDQAATA0A AE0NAABODQAAlg0AAJgNAADfDQAA4Q0AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEPAAAd4Q0AAOsNAAAsDgAAaQ4AALEOAAD0DgAAOA8AAIAPAADHDwAADhAA AFMQAACaEAAA3BAAACMRAABsEQAAkhEAAJQRAACeEQAA5xEAADASAAB5EgAAwhIAAAsTAABUEwAA nRMAAOYTAAAvFAAAeBQAAMEUAAAKFQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQ8AAB0KFQAAUxUAAJwVAADlFQAALhYAAHcWAADAFgAACRcAAFIXAACbFwAA 5BcAAC0YAAB2GAAAvxgAAAgZAABRGQAAmhkAAOMZAAAsGgAAdRoAAL4aAAAHGwAAUBsAAFEbAACZ GwAAmxsAAOIbAADkGwAA6RsAAO4bAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAHb8YAAAIGQAAURkAAJoZAADjGQAALBoAAHUaAAC+GgAABxsAAFAbAABR GwAAmRsAAJsbAADiGwAA5BsAAOkbAADuGwAA/xsAAAQcAABKHAAAkhwAANscAAAfHQAAZh0AAKcd AADtHQAAMB4AAHQeAAC2HgAA/B4AAEIfAACLHwAAzx8AABIgAABaIAAAhSAAAIogAACPIAAA0iAA ABUhAABYIQAAmyEAAN4hAAAiIgAAZiIAAKgiAACtIgAA4iIAAOciAADsIgAAMyMAAHojAAC9IwAA AyQAAEkkAACSJAAA2iQAAB0lAABiJQAAqiUAAPMlAAA3JgAARSYAAEYmAABHJgAASCYAAEkmAACR JgAAkyYAANomAADcJgAA4SYAAOYmAAApJwAAbCcAAK8nAADyJwAANSgAAHkoAAC9KAAA/igAAEIp AACEKQAAiSkAAL8pAADEKQAAySkAABAqAABZKgAAoioAAOUqAAApKwAAcSsAALorAAADLAAAQywA AIosAADSLAAA+ywAAAAtAABILQAA/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/gAAAAACAQFk7hsAAP8bAAAEHAAAShwAAJIcAADbHAAAHx0AAGYdAACnHQAA7R0AADAe AAB0HgAAth4AAPweAABCHwAAix8AAM8fAAASIAAAWiAAAIUgAACKIAAAjyAAANIgAAAVIQAAWCEA AJshAADeIQAAIiIAAGYiAACoIgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQ8AAB2oIgAArSIAAOIiAADnIgAA7CIAADMjAAB6IwAAvSMAAAMkAABJJAAAkiQA ANokAAAdJQAAYiUAAKolAADzJQAANyYAAEUmAABGJgAARyYAAEgmAABJJgAAkSYAAJMmAADaJgAA 3CYAAOEmAADmJgAAKScAAGwnAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAA AAAAAAAAAAABDwAAHWwnAACvJwAA8icAADUoAAB5KAAAvSgAAP4oAABCKQAAhCkAAIkpAAC/KQAA xCkAAMkpAAAQKgAAWSoAAKIqAADlKgAAKSsAAHErAAC6KwAAAywAAEMsAACKLAAA0iwAAPssAAAA LQAASC0AAJAtAADXLQAAHS4AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAdSC0AAJAtAADXLQAAHS4AAFwuAACkLgAA5S4AACwvAABJLwAATi8AAAQxAAAF MQAATjEAAI0xAADQMQAAEzIAAFkyAACgMgAA6DIAADEzAAB5MwAAvTMAANUzAADWMwAAoDQAAKU0 AACmNAAA7jQAAPA0AAA3NQAAOTUAAIA1AADFNQAACzYAAEU2AABGNgAAejcAAH83AADBNwAABjgA AE84AACYOAAA4TgAACY5AAArOQAAbDkAAI45AACPOQAAkDkAAJU5AADCOQAAxzkAAAo6AAAPOgAA MzoAAE46AABqOgAAhjoAAIs6AACQOgAA1zoAAB07AABgOwAApjsAAO07AAA0PAAAeTwAAMA8AAAI PQAATj0AAJY9AADdPQAAJD4AACk+AABpPgAAsT4AAPU+AAA2PwAAfD8AAIE/AADJPwAA9D8AAPk/ AAAaQAAAH0AAACBAAAAhQAAAaUAAAGtAAACyQAAAtEAAAPdAAAA/QQAAh0EAAMJBAADDQQAAhUMA AIpDAADSQwAAFEQAAFhEAAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+AAAAAAIBAWQdLgAAXC4AAKQuAADlLgAALC8AAEkvAABOLwAABDEAAAUxAABOMQAAjTEAANAx AAATMgAAWTIAAKAyAADoMgAAMTMAAHkzAAC9MwAA1TMAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEDwBDJAFFxoAAAAEAXexXBgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABDwAAE9UzAADWMwAAoDQAAKU0AACmNAAA7jQAAPA0AAA3NQAAOTUAAIA1AADFNQAACzYA AEU2AABGNgAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAA AAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4 AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAcwAAAAAA AAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQBf7FcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAABEDwBDJAFFxoAAAAEAXuxX BgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAANRjYAAHo3AAB/NwAAwTcAAAY4AABPOAAAmDgAAOE4AAAmOQAAKzkAAGw5AACOOQAA jzkAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4 AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAA AAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAARA8AQyQBRcaAAAABAFnsVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAEQPAEMkAUXGgAAAAQBf7FcG AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAyPOQAAkDkAAJU5AADCOQAAxzkAAAo6AAAPOgAAMzoAAE46AABqOgAAhjoAAIs6AACQ OgAA1zoAAB07AABgOwAApjsAAO07AAA0PAAAeTwAAMA8AAAIPQAAugAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAARA8AQyQBRcaAAAABAFvsVwYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFQg9AABOPQAAlj0AAN09AAAkPgAAKT4AAGk+AACxPgAA9T4AADY/AAB8PwAAgT8AAMk/ AAD0PwAA+T8AABpAAAAfQAAAIEAAACFAAABpQAAAa0AAALJAAAC0QAAA90AAAD9BAACHQQAAwkEA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw8AQyQB AAEPAAAawkEAAMNBAACFQwAAikMAANJDAAAURAAAWEQAAKFEAADjRAAA70QAAPBEAAAmRQAAugAA AAAAAAAAAAAAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAA AAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA cwAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAARA8AQyQBRcaAAAABAKPsVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAEQPAEMkAUXGgAAAAQCb7FcGAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAtYRAAAoUQAAONEAADvRAAA8EQAACZFAAAmRgAAQkcAAIlHAADiSAAA50gAAP9IAAAESQAA TUkAAJRJAADbSQAAGUoAAGJKAAClSgAA7koAADNLAAA0SwAAc0sAAIhMAADgTAAAsk0AAA5PAACq TwAArE8AALFPAADKTwAAz08AABNQAABTUAAAllAAANlQAAAhUQAAWlEAAKNRAADhUQAA9VEAADlS AABtUgAAclIAALhSAAAAUwAASVMAAJJTAADbUwAAJFQAAG1UAAC2VAAA/1QAAARVAAAWVQAAIFUA AGZVAACaVQAAm1UAAONVAADlVQAALFYAAC5WAAA4VgAAflYAALpWAAC/VgAA1lYAAOBWAAAQVwAA FVcAAC5XAAA4VwAAfFcAAIxXAACRVwAA2lcAAPZXAAD7VwAAEVgAABZYAABdWAAAoFgAAOlYAAAw WQAAclkAALpZAADTWQAA1FkAAIdbAACMWwAA01sAABxcAABmXAAAsFwAAPpcAABEXQAAjl0AAJNd AACYXQAAtV0AAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAA AgEBZCZFAAAmRgAAQkcAAIlHAADiSAAAtwAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAABvAAAAAAAA AAAAAAAAJwAAAAAAAAAAAAAAAAAAAAAAAEgPAAomAAtGAQBDJAFFxoAAAAEAruxXBgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgP AAomAAtGAQBDJAFFxoAAAAEArOxXBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgPAAomAAtGAQBDJAFFxoAAAAEAp+xXBgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAExkUAACZGAADNRgAAQUcAAEZHAACJRwAAvEcAANVHAADbRwAA8UcAAPdHAABdSAAAZUgAAOFI AAAySwAAc0sAAE1MAACHTAAAiEwAAFFNAABeTQAAYE0AAG5NAABxTQAAiU0AALFNAAC1TQAAv00A AMBNAADeTQAAA08AAA1PAAAOTwAAqk8AAKtPAACsTwAA0lkAAPbt5O3b5NLkydLJwNIAt66lnJOK k4GKgYp4gXiBeG9mnF1mAAAAEQEIgQRIAQAFaA3tVwYHSAAAEQAIgWNIAQBkaArtVwZnSAAAEQEI gQRIAQAFaAztVwYHSAAAEQEIgQRIAQAFaArtVwYHSAAAEQEIgQRIAQAFaAntVwYHSAAAEQEIgQRI AQAFaBDtVwYHSAAAEQEIgQRIAQAFaAjtVwYHSAAAEQEIgQRIAQAFaA/tVwYHSAAAEQEIgQRIAQAF aA7tVwYHSAAAEQEIgQRIAQAFaAftVwYHSAAAEQEIgQRIAQAFaAbtVwYHSAAAEQEIgQRIAQAFaLLs VwYHSAAAEQEIgQRIAQAFaLHsVwYHSAAAEQEIgQRIAQAFaLPsVwYHSAAAEQEIgQRIAQAFaK7sVwYH SAAAEQEIgQRIAQAFaK/sVwYHSAAAEQEIgQRIAQAFaKzsVwYHSAAAEQEIgQRIAQAFaKfsVwYHSAAA ACTiSAAA50gAAP9IAAAESQAATUkAAJRJAADbSQAAGUoAAGJKAAClSgAA7koAADNLAAA0SwAAc0sA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEDwBDJAFFxoAAAAEABu1XBgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAA DXNLAACITAAA4EwAALJNAAAOTwAAtwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAAC3AAAAAAAAAAAA AAAAJwAAAAAAAAAAAAAAAAAAAAAAAEgPAAomAAtGAgBDJAFFxoAAAAEACu1XBgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgPAAom AAtGAgBDJAFFxoAAAAEAD+1XBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgPAAomAAtGAgBDJAFFxoAAAAEACO1XBgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE Dk8AAKpPAACsTwAAsU8AAMpPAADPTwAAE1AAAFNQAACWUAAA2VAAACFRAABaUQAAo1EAAOFRAAD1 UQAAOVIAAG1SAAByUgAAuFIAAABTAABJUwAA+gAAAAAAAAAAAAAAALUAAAAAAAAAAAAAAACzAAAA AAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAswAAAAAAAAAA AAAAALMAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAAAAAAAACz AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAswAAAAAA AAAAAAAAALMAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABDwAARA8AQyQBRcaAAAABAA3tVwYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFDwAKJgALRgIAABRJ UwAAklMAANtTAAAkVAAAbVQAALZUAAD/VAAABFUAABZVAAAgVQAAZlUAAJpVAACbVQAA41UAAOVV AAAsVgAALlYAADhWAAB+VgAAulYAAL9WAADWVgAA4FYAABBXAAAVVwAALlcAADhXAAB8VwAAjFcA AJFXAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHZFX AADaVwAA9lcAAPtXAAARWAAAFlgAAF1YAACgWAAA6VgAADBZAAByWQAAulkAANNZAADUWQAAh1sA AIxbAADTWwAAHFwAAGZcAACwXAAA+lwAAERdAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQAU7VcGAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAV0lkA ABZbAACGWwAAumEAAGViAADNZAAAAmUAAOJmAAAcZwAAImcAADJnAAA9ZwAAF2gAAFloAACwdgAA XHcAAJB3AABHfAAAh3wAAHV/AACmfwAAp38AAMOFAADehQAAvIYAANKHAACDiAAAg5cAAFqYAAC5 mAAA2ZgAADKZAAD27QDkANsA0snSwLeuAKWcAJMAioEAk3gAbwBmXVRdAAAAAAAAAAAAEQEIgQRI AQAFaC7tVwYHSAAAEQEIgQRIAQAFaCvtVwYHSAAAEQEIgQRIAQAFaCntVwYHSAAAEQEIgQRIAQAF aCftVwYHSAAAEQEIgQRIAQAFaCXtVwYHSAAAEQAIgWNIAQBkaCTtVwZnSAAAEQEIgQRIAQAFaCLt VwYHSAAAEQEIgQRIAQAFaCTtVwYHSAAAEQEIgQRIAQAFaCHtVwYHSAAAEQEIgQRIAQAFaCDtVwYH SAAAEQEIgQRIAQAFaDDtVwYHSAAAEQEIgQRIAQAFaBvtVwYHSAAAEQEIgQRIAQAFaB/tVwYHSAAA EQEIgQRIAQAFaB7tVwYHSAAAEQEIgQRIAQAFaBrtVwYHSAAAEQEIgQRIAQAFaBntVwYHSAAAEQEI gQRIAQAFaBftVwYHSAAAEQEIgQRIAQAFaBbtVwYHSAAAEQEIgQRIAQAFaBTtVwYHSAAAAB9EXQAA jl0AAJNdAACYXQAAtV0AALpdAADXXQAA3F0AAPddAAABXgAARl4AAIxeAACyXgAAt14AAP1eAABE XwAAVV8AAFpfAACjXwAA3V8AAN5fAAAmYAAAKGAAAG9gAABxYAAAt2AAAPRgAAA6YQAAeWEAALth AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHbVdAAC6 XQAA110AANxdAAD3XQAAAV4AAEZeAACMXgAAsl4AALdeAAD9XgAARF8AAFVfAABaXwAAo18AAN1f AADeXwAAJmAAAChgAABvYAAAcWAAALdgAAD0YAAAOmEAAHlhAAC7YQAAvGEAAGViAABmYgAAr2IA APdiAAA9YwAAhGMAAMpjAAAOZAAAVmQAAJ1kAADOZAAAz2QAAANlAAAIZQAAIGUAACVlAABsZQAA smUAAPZlAAA+ZgAAVGYAAFlmAAChZgAA42YAAORmAABaaAAAX2gAAKVoAADeaAAA42gAACppAABz aQAAvWkAAAdqAABRagAAm2oAAOVqAAAvawAAeWsAAMNrAAANbAAAEmwAABdsAAA0bAAAOWwAAFds AABcbAAAXWwAAF5sAABfbAAAYGwAAGFsAABibAAAqmwAAKxsAADzbAAA9WwAABptAAAfbQAASW0A AHNtAACZbQAAwG0AAORtAAAJbgAAJm4AAEJuAABgbgAAZW4AAGpuAACZbgAAo24AAOhuAADtbgAA /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAACAQFku2EAALxh AABlYgAAZmIAAK9iAAD3YgAAPWMAAIRjAADKYwAADmQAAFZkAACdZAAAzmQAALoAAAAAAAAAAAAA AAC6AAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAA AAAAAAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAHMAAAAAAAAA AAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8A AEQPAEMkAUXGgAAAAQAY7VcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQAX7VcGAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzOZAAAz2QA AANlAAAIZQAAIGUAACVlAABsZQAAsmUAAPZlAAA+ZgAAVGYAAFlmAAChZgAA42YAALoAAAAAAAAA AAAAAAC6AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA uAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAARA8AQyQBRcaAAAABABntVwYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADeNmAADkZgAA WmgAAF9oAAClaAAA3mgAAONoAAAqaQAAc2kAAL1pAAAHagAAUWoAAJtqAADlagAAugAAAAAAAAAA AAAAAHUAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABz AAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAA AAAAAAAAAHMAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAAAAAAAAAAEPAABE DwBDJAFFxoAAAAEAHe1XBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEDwBDJAFFxoAAAAEAGu1XBgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN5WoAAC9rAAB5 awAAw2sAAA1sAAASbAAAF2wAADRsAAA5bAAAV2wAAFxsAABdbAAAXmwAAF9sAABgbAAAYWwAAGJs AACqbAAArGwAAPNsAAD1bAAAGm0AAB9tAABJbQAAc20AAJltAADAbQAA5G0AAAluAAAmbgAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB0mbgAAQm4AAGBu AABlbgAAam4AAJluAACjbgAA6G4AAO1uAAAcbwAAJm8AAGtvAAB1bwAAu28AAPhvAAACcAAARXAA AH5wAACDcAAAxHAAAAdxAABEcQAAf3EAALpxAAD1cQAAMHIAAGtyAACmcgAA4XIAABxzAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHe1uAAAcbwAAJm8A AGtvAAB1bwAAu28AAPhvAAACcAAARXAAAH5wAACDcAAAxHAAAAdxAABEcQAAf3EAALpxAAD1cQAA MHIAAGtyAACmcgAA4XIAABxzAABXcwAAknMAAM1zAAAIdAAAQ3QAAH50AAC5dAAA9HQAAC91AAA0 dQAAOXUAADp1AAA7dQAAPHUAAIR1AACGdQAAzXUAAM91AAABdgAABnYAAE12AACTdgAAsXYAALJ2 AACRdwAAlncAANx3AAAkeAAAbXgAALZ4AAD/eAAASHkAAJF5AADaeQAAI3oAAGx6AAC1egAAunoA AL96AADcegAA4XoAABV7AAAaewAASXsAAE57AABvewAAdHsAAHl7AACMewAAkXsAANJ7AAAafAAA SHwAAEl8AACIfAAAjXwAANR8AAAdfQAAZ30AALF9AAD7fQAARX4AAI9+AACUfgAAmX4AALZ+AAC7 fgAA2H4AAN1+AAD6fgAABH8AAEp/AAB2fwAAd38AAKd/AACofwAA8H8AAPJ/AAA5gAAA/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAACAQFkHHMAAFdzAACScwAA zXMAAAh0AABDdAAAfnQAALl0AAD0dAAAL3UAADR1AAA5dQAAOnUAADt1AAA8dQAAhHUAAIZ1AADN dQAAz3UAAAF2AAAGdgAATXYAAJN2AACxdgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABexdgAAsnYAAJF3AACW dwAA3HcAACR4AABteAAAtngAAP94AABIeQAAkXkAANp5AAAjegAAbHoAALV6AAC6egAAv3oAANx6 AADhegAAFXsAABp7AABJewAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA uAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA AAAAAAAAAAAAAAAAAAABDwAARA8AQyQBRcaAAAABACDtVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFUl7AABOewAAb3sAAHR7 AAB5ewAAjHsAAJF7AADSewAAGnwAAEh8AABJfAAAiHwAAI18AADUfAAAHX0AAGd9AACxfQAA+30A AEV+AACPfgAAlH4AAJl+AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQAk7VcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAVmX4AALZ+AAC7fgAA2H4A AN1+AAD6fgAABH8AAEp/AAB2fwAAd38AAKd/AACofwAA8H8AAPJ/AAA5gAAAO4AAAECAAABFgAAA a4AAAHCAAAC1gAAAuoAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAAAAAAAAAAAARA8AQyQBRcaAAAABACLtVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABU5gAAAO4AAAECAAABFgAAA a4AAAHCAAAC1gAAAuoAAAAKBAABHgQAAiIEAAM6BAAAWggAAQYIAAEaCAACNggAA1oIAACCDAABq gwAAtIMAAP6DAABIhAAATYQAAFKEAABvhAAAdIQAAJGEAACWhAAAsYQAALuEAAD8hAAAAYUAABaF AAAghQAAaIUAALCFAAC/hQAAxIUAAL2GAADChgAA3YYAAOKGAAAhhwAAaocAAKyHAADThwAA1IcA AISIAACJiAAA0IgAABmJAABjiQAArYkAAPeJAABBigAAi4oAAIyKAADUigAA1ooAAB2LAAAfiwAA JIsAACmLAABGiwAAS4sAAGiLAABtiwAAiIsAAJKLAADTiwAA2IsAAPaLAAAAjAAASYwAAIuMAACV jAAAv4wAAMSMAADfjAAA64wAADSNAAB7jQAAgo0AAKKNAACujQAA8o0AADaOAAA9jgAAXY4AAGmO AACtjgAA8Y4AAPiOAAARjwAAHY8AAGaPAACkjwAAq48AAMmPAADVjwAAFZAAAP7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZLqAAAACgQAAR4EAAIiBAADO gQAAFoIAAEGCAABGggAAjYIAANaCAAAggwAAaoMAALSDAAD+gwAASIQAAE2EAABShAAAb4QAAHSE AACRhAAAloQAALGEAAC7hAAA/IQAAAGFAAAWhQAAIIUAAGiFAACwhQAAv4UAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdv4UAAMSFAAC9hgAAwoYAAN2G AADihgAAIYcAAGqHAACshwAA04cAANSHAACEiAAAiYgAANCIAAD9AAAAAAAAAAAAAAAAuAAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAARA8AQyQBRcaAAAABACft VwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAARA8AQyQBRcaAAAABACTtVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAA3QiAAAGYkAAGOJAACtiQAA94kA AEGKAACLigAAjIoAANSKAADWigAAHYsAAB+LAAAkiwAAKYsAAEaLAABLiwAAaIsAAG2LAACIiwAA kosAANOLAADYiwAA9osAAACMAABJjAAAi4wAAJWMAAC/jAAAxIwAAN+MAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHd+MAADrjAAANI0AAHuNAACCjQAA oo0AAK6NAADyjQAANo4AAD2OAABdjgAAaY4AAK2OAADxjgAA+I4AABGPAAAdjwAAZo8AAKSPAACr jwAAyY8AANWPAAAVkAAALJAAADOQAABTkAAAX5AAAKaQAADvkAAANZEAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdFZAAACyQAAAzkAAAU5AAAF+QAACm kAAA75AAADWRAAA6kQAAP5EAAECRAABBkQAAQpEAAIqRAACMkQAA05EAANWRAADqkQAA75EAADiS AABPkgAAVJIAAJuSAADkkgAALpMAAHiTAADCkwAADJQAAFaUAABblAAAYJQAAH2UAACClAAAn5QA AKSUAADClAAAzJQAAPOUAAD4lAAA/ZQAACKVAAAnlQAAa5UAAHiVAAB9lQAAxJUAAA2WAABXlgAA oZYAAOuWAAA1lwAAf5cAAISXAAARmgAAFpoAADOaAAA4mgAAVZoAAFqaAACBmgAAi5oAAKSaAACp mgAArpoAAMWaAADKmgAAApsAAAebAAAgmwAAIZsAAGmbAABrmwAAspsAALSbAADQmwAA7JsAAPGb AAA5nAAAf5wAAMicAAAQnQAAIp0AACedAABwnQAAtp0AAOOdAADknQAA4Z4AAOaeAAAonwAAcZ8A ALGfAAD3nwAAJaAAACagAADUoAAA2aAAACChAABnoQAArqEAAPWhAAD+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+AAAAAAIBAWQ1kQAAOpEAAD+RAABAkQAAQZEAAEKR AACKkQAAjJEAANORAADVkQAA6pEAAO+RAAA4kgAAT5IAAFSSAACbkgAA5JIAAC6TAAB4kwAAwpMA AAyUAABWlAAAW5QAAGCUAAB9lAAAgpQAAJ+UAACklAAAwpQAAMyUAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHcyUAADzlAAA+JQAAP2UAAAilQAAJ5UA AGuVAAB4lQAAfZUAAMSVAAANlgAAV5YAAKGWAADrlgAANZcAAH+XAACElwAAEZoAABaaAAAzmgAA OJoAAFWaAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAEQPAEMkAUXGgAAAAQAp7VcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAVMpkAAGGZAAB3mQAAf5kAABCaAADinQAA ZZ4AAOCeAAAkoAAAjqAAANOgAABzpQAAgKUAAIylAAD0pQAAm6sAAKarAACurwAA468AANeyAABr swAA07MAANSzAAAZvQAANL0AAPe9AAD4vQAAwcEAAB/CAABdwgAA4dAAAAjRAAD75QAAYOYAAG7u AADd7gAAgfYAAPbt5O0A29IAycAAt663AK4ApQCck5wAigCKAIqBAHgAbwBmAAAAAAAAAAAAAAAA AAAAAAAAAAAAEQEIgQRIAQAFaErtVwYHSAAAEQEIgQRIAQAFaEntVwYHSAAAEQEIgQRIAQAFaDvt VwYHSAAAEQEIgQRIAQAFaDrtVwYHSAAAEQEIgQRIAQAFaDntVwYHSAAAEQEIgQRIAQAFaDjtVwYH SAAAEQEIgQRIAQAFaDftVwYHSAAAEQEIgQRIAQAFaDbtVwYHSAAAEQEIgQRIAQAFaDXtVwYHSAAA EQEIgQRIAQAFaDTtVwYHSAAAEQEIgQRIAQAFaDPtVwYHSAAAEQEIgQRIAQAFaDLtVwYHSAAAEQEI gQRIAQAFaEHtVwYHSAAAEQEIgQRIAQAFaEDtVwYHSAAAEQEIgQRIAQAFaDDtVwYHSAAAEQEIgQRI AQAFaC/tVwYHSAAAEQEIgQRIAQAFaCztVwYHSAAAACRVmgAAWpoAAIGaAACLmgAApJoAAKmaAACu mgAAxZoAAMqaAAACmwAAB5sAACCbAAAhmwAAaZsAAGubAACymwAAtJsAANCbAADsmwAA8ZsAADmc AAB/nAAAyJwAABCdAAAinQAAJ50AAHCdAAC2nQAA450AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHOOdAADknQAA4Z4AAOaeAAAonwAAcZ8AALGf AAD3nwAAJaAAACagAADUoAAA2aAAACChAABnoQAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC4 AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAA AAAAAAAAALgAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAALgAAAAAAAAAAAAA AAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQAy7VcGAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAABEDwBDJAFFxoAAAAEAQO1XBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANZ6EAAK6hAAD1oQAAM6IAADiiAAB/ogAAvKIA AOqiAADvogAAHaMAACKjAABoowAAqqMAAOujAAAwpAAAd6QAALakAADgpAAA5aQAAOqkAAAspQAA dKUAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABX1oQAAM6IAADiiAAB/ogAAvKIAAOqiAADvogAA HaMAACKjAABoowAAqqMAAOujAAAwpAAAd6QAALakAADgpAAA5aQAAOqkAAAspQAAdKUAAHWlAAD1 pQAA+qUAADqmAAA/pgAAeaYAAH6mAAB/pgAAgKYAAIGmAACCpgAAg6YAAMumAADNpgAAFKcAABan AABZpwAAnqcAAOSnAAAqqAAAcKgAALaoAAD7qAAAQakAAIepAACMqQAApKkAAKmpAADyqQAAOqoA AIOqAADKqgAA7aoAAO+qAAA3qwAAgKsAAJyrAACdqwAAp6sAAKyrAADJqwAAzqsAABGsAABWrAAA nKwAAOKsAAAorQAAbq0AALStAAD6rQAAQK4AAEWuAABzrgAAeK4AAI2uAACSrgAAyK4AAM2uAADu rgAA864AADivAACBrwAAqa8AAK6vAADkrwAA5a8AAOavAADnrwAA6K8AAOmvAAAxsAAAM7AAAHqw AAB8sAAAk7AAAJiwAACzsAAAvbAAAPewAAAxsQAAZbEAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZHSlAAB1pQAA9aUAAPqlAAA6pgAAP6YAAHmmAAB+ pgAAf6YAAICmAACBpgAAgqYAAIOmAADLpgAAzaYAABSnAAAWpwAAWacAAJ6nAADkpwAAKqgAAHCo AAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAA AAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAA AAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA uAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAEP AABEDwBDJAFFxoAAAAEANO1XBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVcKgAALaoAAD7qAAAQakAAIepAACMqQAApKkAAKmp AADyqQAAOqoAAIOqAADKqgAA7aoAAO+qAAA3qwAAgKsAAJyrAACdqwAAp6sAAKyrAADJqwAAzqsA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAARA8A QyQBRcaAAAABADXtVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABXOqwAAEawAAFasAACcrAAA4qwAACitAABurQAAtK0A APqtAABArgAARa4AAHOuAAB4rgAAja4AAJKuAADIrgAAza4AAO6uAADzrgAAOK8AAIGvAACprwAA rq8AAOSvAADlrwAA5q8AAOevAADorwAA6a8AADGwAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHTGwAAAzsAAAerAAAHywAACTsAAAmLAAALOwAAC9sAAA 97AAADGxAABlsQAAf7EAAL6xAAAGsgAAR7IAAI+yAADYsgAA2bIAANSzAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMk AUXGgAAAAQA37VcGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEPAAASZbEAAH+xAAC+sQAABrIAAEeyAACPsgAA2LIAANmyAADU swAA1bMAABm0AABftAAAqLQAAPG0AAAltQAAKrUAAC+1AABKtQAAT7UAAJK1AADXtQAAHbYAAGO2 AACptgAA77YAADW3AAB7twAAwbcAAMa3AADytwAA97cAAAy4AAARuAAAR7gAAEy4AABouAAAbbgA AJO4AACYuAAAmbgAAJq4AACbuAAAnLgAAJ24AACeuAAAn7gAAKC4AAChuAAAorgAAOq4AADsuAAA M7kAADW5AABMuQAAUbkAAGy5AAB2uQAAsLkAAOq5AAAeugAAOLoAAHe6AAC/ugAAALsAAEi7AACR uwAA1bsAABu8AABbvAAAn7wAAOO8AAAVvQAANb0AADq9AAA/vQAAcL0AAHW9AAC6vQAAAr4AAA2+ AAASvgAAOr4AAIG+AACGvgAAwb4AAMa+AAAKvwAAUL8AAJe/AADevwAAJcAAAGzAAACzwAAAuMAA ANHAAADWwAAAE8EAACvBAAAwwQAAT8EAAFTBAAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+AAAAAAIBAWTUswAA1bMAABm0AABftAAAqLQAAPG0AAAltQAAKrUAAC+1 AABKtQAAT7UAAJK1AADXtQAAHbYAAGO2AACptgAA77YAADW3AAB7twAAwbcAAMa3AADytwAAugAA AAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAA AAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA uAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAARA8A QyQBRcaAAAABADjtVwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFfK3AAD3twAADLgAABG4AABHuAAATLgAAGi4AABtuAAAk7gA AJi4AACZuAAAmrgAAJu4AACcuAAAnbgAAJ64AACfuAAAoLgAAKG4AACiuAAA6rgAAOy4AAAzuQAA NbkAAEy5AABRuQAAbLkAAHa5AACwuQAA6rkAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEPAAAd6rkAAB66AAA4ugAAd7oAAL+6AAAAuwAASLsAAJG7AADVuwAA G7wAAFu8AACfvAAA47wAABW9AAA1vQAAOr0AAD+9AABwvQAAdb0AALq9AAACvgAADb4AABK+AAA6 vgAAgb4AAIa+AADBvgAAxr4AAAq/AABQvwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQ8AAB1QvwAAl78AAN6/AAAlwAAAbMAAALPAAAC4wAAA0cAAANbAAAAT wQAAK8EAADDBAABPwQAAVMEAAJjBAAC9wQAAwsEAAF7CAABfwgAAp8IAAKnCAADwwgAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAABEDwBDJAFFxoAA AAEAOe1XBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABDwAAFVTBAACYwQAAvcEAAMLBAABewgAAX8IAAKfCAACpwgAA8MIAAPLC AAD3wgAAKMMAAC3DAAB2wwAAusMAANHDAADWwwAAHcQAAGPEAABoxAAAjcQAALrEAAC/xAAA/sQA AAPFAABGxQAAi8UAANHFAAAXxgAAXcYAAKPGAADpxgAAL8cAAHXHAAB6xwAAkscAAJfHAADgxwAA KMgAAHHIAAC6yAAA4MgAAOLIAAApyQAAbckAAJLJAACXyQAAtMkAALnJAAD8yQAAQcoAAIfKAADN ygAAE8sAAFnLAACfywAApMsAANLLAADXywAA7MsAAPHLAADyywAAOswAADzMAACDzAAAhcwAALvM AADAzAAA4cwAAObMAAArzQAAc80AAKrNAACvzQAAtM0AAM/NAADUzQAAF84AAFzOAACizgAA6M4A AC7PAAB0zwAAus8AAL/PAADrzwAA8M8AAAXQAAAK0AAAQNAAAEXQAABh0AAAZtAAAKnQAADY0AAA 3dAAAOLQAAAI0QAACdEAACDRAAAi0QAA/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/gAAAAACAQFk8MIAAPLCAAD3wgAAKMMAAC3DAAB2wwAAusMAANHDAADWwwAAHcQA AGPEAABoxAAAjcQAALrEAAC/xAAA/sQAAAPFAABGxQAAi8UAANHFAAAXxgAAXcYAAKPGAADpxgAA L8cAAHXHAAB6xwAAkscAAJfHAADgxwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQ8AAB3gxwAAKMgAAHHIAAC6yAAA4MgAAOLIAAApyQAAbckAAJLJAACXyQAA tMkAALnJAAD8yQAAQcoAAIfKAADNygAAE8sAAFnLAACfywAApMsAANLLAADXywAA7MsAAPHLAADy ywAAOswAADzMAACDzAAAhcwAALvMAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAHbvMAADAzAAA4cwAAObMAAArzQAAc80AAKrNAACvzQAAtM0AAM/NAADU zQAAF84AAFzOAACizgAA6M4AAC7PAAB0zwAAus8AAL/PAADrzwAA8M8AAAXQAAAK0AAAQNAAAEXQ AABh0AAAZtAAAKnQAADY0AAA3dAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEPAAAd3dAAAOLQAAAI0QAACdEAACDRAAAi0QAAadEAAKfRAADN0QAA0tEAABTS AABY0gAAnNIAAOTSAAAt0wAAVdMAAFrTAACb0wAA2NMAAN/TAADh0wAADtQAAP0AAAAAAAAAAAAA AAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAARA8AQyQBRcaAAAABADvt VwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQ8AABUi0QAAadEAAKfRAADN0QAA0tEAABTSAABY0gAAnNIAAOTSAAAt0wAAVdMA AFrTAACb0wAA2NMAAN/TAADh0wAADtQAABPUAAAU1AAAFdQAAF3UAABf1AAAptQAAKjUAADt1AAA NdUAAHjVAAC/1QAAxNUAAMnVAAAH1gAADNYAAEXWAABK1gAAjdYAANLWAAAY1wAAXtcAAKTXAADq 1wAAMNgAAHbYAAC82AAAwdgAANnYAADe2AAAJ9kAAG/ZAAC42QAA/9kAACLaAAAk2gAAbNoAALXa AADR2gAA1toAAPjaAAD92gAAQNsAAIXbAADL2wAAEdwAAFfcAACd3AAA49wAACndAABv3QAAdN0A AKLdAACn3QAAvN0AAMHdAAD33QAA/N0AAB3eAAAe3gAAZt4AAGjeAACv3gAAsd4AALbeAAD73gAA Qt8AAIjfAACN3wAAqd8AAK7fAADZ3wAA3t8AAPLfAAD33wAAOuAAAH/gAADF4AAAC+EAAFHhAACX 4QAA3eEAACPiAABp4gAAr+IAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v4AAAAAAgEBZA7UAAAT1AAAFNQAABXUAABd1AAAX9QAAKbUAACo1AAA7dQAADXVAAB41QAA v9UAAMTVAADJ1QAAB9YAAAzWAABF1gAAStYAAI3WAADS1gAAGNcAAF7XAACk1wAA6tcAADDYAAB2 2AAAvNgAAMHYAADZ2AAA3tgAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAd3tgAACfZAABv2QAAuNkAAP/ZAAAi2gAAJNoAAGzaAAC12gAA0doAANbaAAD4 2gAA/doAAEDbAACF2wAAy9sAABHcAABX3AAAndwAAOPcAAAp3QAAb90AAHTdAACi3QAAp90AALzd AADB3QAA990AAPzdAAAd3gAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQ8AAB0d3gAAHt4AAGbeAABo3gAAr94AALHeAAC23gAA+94AAELfAACI3wAAjd8AAKnf AACu3wAA2d8AAN7fAADy3wAA998AADrgAAB/4AAAxeAAAAvhAABR4QAAl+EAAN3hAAAj4gAAaeIA AK/iAAD14gAAO+MAAIHjAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAABDwAAHa/iAAD14gAAO+MAAIHjAACG4wAAtOMAALnjAADO4wAA0+MAAAnkAAAO5AAAL+QA ADTkAAB55AAAwOQAAAblAAAL5QAAI+UAACjlAABQ5QAAWuUAAIXlAACt5QAA1uUAAPzlAAD95QAA YeYAAGvmAACF5gAAiuYAAKXmAACq5gAA5uYAAOfmAAAv5wAAMecAAHjnAAB65wAAf+cAAJLnAACX 5wAA4OcAACnoAABx6AAAnugAAKPoAADT6AAA2OgAABzpAABe6QAAd+kAAHzpAACk6QAA6ekAAO7p AAAo6gAALeoAAHHqAAC36gAA/uoAAEXrAACM6wAA0+sAABrsAAAf7AAAOOwAAD3sAAB67AAAkuwA AJfsAAC27AAAu+wAAP/sAAAk7QAAKe0AAFrtAABf7QAAqO0AAOntAAAx7gAAb+4AAHDuAADe7gAA 4+4AAAvvAABS7wAAV+8AAJLvAACX7wAAmO8AAJnvAACa7wAA4u8AAOTvAAAr8AAALfAAAHHwAAC3 8AAA/vAAAEXxAACM8QAA/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /gAAAAACAQFkgeMAAIbjAAC04wAAueMAAM7jAADT4wAACeQAAA7kAAAv5AAANOQAAHnkAADA5AAA BuUAAAvlAAAj5QAAKOUAAFDlAABa5QAAheUAAK3lAADW5QAA/OUAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQ8AABX85QAA/eUAAGHmAABr5gAAheYAAIrmAACl5gAAquYAAObmAADn5gAAL+cAADHnAAB4 5wAAeucAAH/nAACS5wAAl+cAAODnAAAp6AAAcegAAJ7oAACj6AAAugAAAAAAAAAAAAAAALoAAAAA AAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAA AAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAARA8AQyQBRcaAAAABAEntVwYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFaPoAADT6AAA2OgAABzpAABe6QAAd+kAAHzpAACk6QAA6ekAAO7pAAAo6gAALeoAAHHq AAC36gAA/uoAAEXrAACM6wAA0+sAABrsAAAf7AAAOOwAAD3sAAB67AAAkuwAAJfsAAC27AAAu+wA AP/sAAAk7QAAKe0AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAAAdKe0AAFrtAABf7QAAqO0AAOntAAAx7gAAb+4AAHDuAADe7gAA4+4AAAvvAABS7wAAV+8A AJLvAACX7wAAmO8AAJnvAACa7wAA4u8AAOTvAAAr8AAALfAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAARA8AQyQBRcaAAAABAErtVwYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQ8AABUt8AAAcfAAALfwAAD+8AAARfEAAIzxAADT8QAAGvIAAGDyAACm8gAA7PIAADLzAAA38wAA UPMAAFXzAACS8wAAqvMAAK/zAADO8wAA0/MAABf0AAA89AAAQfQAAGL0AABn9AAArfQAAPP0AAAK 9QAAD/UAABT1AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB DwAAHYzxAADT8QAAGvIAAGDyAACm8gAA7PIAADLzAAA38wAAUPMAAFXzAACS8wAAqvMAAK/zAADO 8wAA0/MAABf0AAA89AAAQfQAAGL0AABn9AAArfQAAPP0AAAK9QAAD/UAABT1AABC9QAAR/UAAI31 AADV9QAA8/UAAPj1AAA69gAAgvYAAIP2AAAI9wAADfcAAE33AABS9wAAjPcAAJH3AACS9wAAk/cA AJT3AACV9wAAlvcAAJf3AACY9wAAmfcAAJr3AACb9wAA4/cAAOX3AAAs+AAALvgAAHH4AAC2+AAA /PgAAEL5AACI+QAAzvkAABT6AABa+gAAoPoAAKX6AAC9+gAAwvoAAAv7AABT+wAAnPsAAOP7AAAG /AAAC/wAADT8AAA5/AAAfvwAAMf8AAAH/QAAQ/0AAEj9AAB5/QAAfv0AAMP9AADe/QAA4/0AAAL+ AABJ/gAATv4AAIn+AACO/gAA0v4AABj/AABf/wAApv8AAO3/AAA0AAEAewABAIAAAQCZAAEAngAB ANsAAQDzAAEA/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAAC AQFkFPUAAEL1AABH9QAAjfUAANX1AADz9QAA+PUAADr2AACC9gAAg/YAAAj3AAAN9wAATfcAAFL3 AACM9wAAkfcAAJL3AACT9wAAlPcAAJX3AACW9wAAl/cAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAARA8AQyQBRcaAAAABAEztVwYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8A ABWB9gAAB/cAAA0hAQD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAQiBBEgBAAVoTO1XBgdIAAAA Apf3AACY9wAAmfcAAJr3AACb9wAA4/cAAOX3AAAs+AAALvgAAHH4AAC2+AAA/PgAAEL5AACI+QAA zvkAABT6AABa+gAAoPoAAKX6AAC9+gAAwvoAAAv7AABT+wAAnPsAAOP7AAAG/AAAC/wAADT8AAA5 /AAAfvwAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAd fvwAAMf8AAAH/QAAQ/0AAEj9AAB5/QAAfv0AAMP9AADe/QAA4/0AAAL+AABJ/gAATv4AAIn+AACO /gAA0v4AABj/AABf/wAApv8AAO3/AAA0AAEAewABAIAAAQCZAAEAngABANsAAQDzAAEA+AABABcB AQAcAQEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB3z AAEA+AABABcBAQAcAQEAHQEBAB4BAQBmAQEAaAEBAK8BAQCxAQEA9QEBABoCAQAfAgEAJAIBAE0C AQBSAgEAmwIBAN0CAQDiAgEAIgMBAFYDAQBbAwEAkQMBAJYDAQDLAwEA0AMBABMEAQBYBAEAngQB AOQEAQAqBQEAcAUBALYFAQD8BQEAQgYBAEcGAQBfBgEAZAYBAK0GAQD1BgEAPgcBAIcHAQClBwEA pwcBAOgHAQAuCAEAcggBAHwIAQCBCAEAhggBALIIAQC3CAEA+ggBABwJAQAhCQEAJgkBAGIJAQBn CQEAnwkBAKQJAQClCQEApgkBAO4JAQDwCQEANwoBADkKAQB8CgEAwQoBAAcLAQBNCwEAkwsBANkL AQAfDAEAZQwBAKsMAQCwDAEAyAwBAM0MAQAUDQEAFg0BAFwNAQCIDQEAjQ0BAJINAQCuDQEAsw0B AO0NAQDyDQEA9w0BAPgNAQD5DQEA+g0BAPsNAQD8DQEA/Q0BAP4NAQD/DQEAAA4BAAEOAQACDgEA Aw4BAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZBwB AQAdAQEAHgEBAGYBAQBoAQEArwEBALEBAQD1AQEAGgIBAB8CAQAkAgEATQIBAFICAQCbAgEA3QIB AOICAQAiAwEAVgMBAFsDAQCRAwEAlgMBAMsDAQDQAwEAEwQBAFgEAQCeBAEA5AQBACoFAQBwBQEA tgUBAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdtgUB APwFAQBCBgEARwYBAF8GAQBkBgEArQYBAPUGAQA+BwEAhwcBAKUHAQCnBwEA6AcBAC4IAQByCAEA fAgBAIEIAQCGCAEAsggBALcIAQD6CAEAHAkBACEJAQAmCQEAYgkBAGcJAQCfCQEApAkBAKUJAQCm CQEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB2mCQEA 7gkBAPAJAQA3CgEAOQoBAHwKAQDBCgEABwsBAE0LAQCTCwEA2QsBAB8MAQBlDAEAqwwBALAMAQDI DAEAzQwBABQNAQAWDQEAXA0BAIgNAQCNDQEAkg0BAK4NAQCzDQEA7Q0BAPINAQD3DQEA+A0BAPkN AQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHfkNAQD6 DQEA+w0BAPwNAQD9DQEA/g0BAP8NAQAADgEAAQ4BAAIOAQADDgEABA4BAAUOAQAGDgEABw4BAAgO AQAJDgEACg4BAAsOAQAMDgEADQ4BAA4OAQAPDgEAEA4BABEOAQASDgEAEw4BABQOAQBcDgEAXg4B AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdAw4BAAQO AQAFDgEABg4BAAcOAQAIDgEACQ4BAAoOAQALDgEADA4BAA0OAQAODgEADw4BABAOAQARDgEAEg4B ABMOAQAUDgEAXA4BAF4OAQClDgEApw4BAKwOAQC7DgEAwA4BAP0OAQBGDwEAjg8BAMgPAQDNDwEA DxABAE4QAQBTEAEAlhABAN4QAQAnEQEAZBEBAKYRAQCrEQEA8xEBADkSAQCBEgEAmhIBAJ8SAQDn EgEALhMBAHcTAQCgEwEApRMBAO4TAQAyFAEAehQBAMMUAQDkFAEA6RQBACkVAQBvFQEAqBUBAK0V AQDsFQEAKhYBAC8WAQBzFgEAvBYBAPQWAQD5FgEAPxcBAIAXAQDHFwEA+hcBAP8XAQAAGAEAARgB AAIYAQBKGAEATBgBAJMYAQCVGAEArBgBALEYAQDpGAEALBkBAGsZAQCrGQEA9RkBAPoZAQA5GgEA eBoBAL4aAQD8GgEARBsBAEkbAQCGGwEAxRsBAAQcAQBFHAEAjhwBAJMcAQDQHAEAEB0BAFEdAQD+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+AAAAAAIBAWReDgEApQ4B AKcOAQCsDgEAuw4BAMAOAQD9DgEARg8BAI4PAQDIDwEAzQ8BAA8QAQBOEAEAUxABAJYQAQDeEAEA JxEBAGQRAQCmEQEAqxEBAPMRAQA5EgEAgRIBAJoSAQCfEgEA5xIBAC4TAQB3EwEAoBMBAKUTAQD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHaUTAQDuEwEA MhQBAHoUAQDDFAEA5BQBAOkUAQApFQEAbxUBAKgVAQCtFQEA7BUBACoWAQAvFgEAcxYBALwWAQD0 FgEA+RYBAD8XAQCAFwEAxxcBAPoXAQD/FwEAABgBAAEYAQACGAEAShgBAEwYAQCTGAEAlRgBAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdlRgBAKwYAQCx GAEA6RgBACwZAQBrGQEAqxkBAPUZAQD6GQEAORoBAHgaAQC+GgEA/BoBAEQbAQBJGwEAhhsBAMUb AQAEHAEARRwBAI4cAQCTHAEA0BwBABAdAQBRHQEAlB0BANodAQDfHQEAGh4BAFkeAQCRHgEA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB1RHQEAlB0BANod AQDfHQEAGh4BAFkeAQCRHgEA2B4BAPUeAQD6HgEALx8BAGkfAQCrHwEA6x8BADAgAQA1IAEATiAB AGggAQB+IAEAliABALQgAQC2IAEAuCABAL0gAQC+IAEAvyABAMAgAQDBIAEAwiABAMMgAQALIQEA DSEBAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBH5EeAQDYHgEA9R4B APoeAQAvHwEAaR8BAKsfAQDrHwEAMCABADUgAQBOIAEAaCABAH4gAQCWIAEAtCABALYgAQC4IAEA vSABAL4gAQC/IAEAwCABAMEgAQDCIAEAwyABAAshAQANIQEA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAZHAAfsNAvILDgPSGw JwUisCcFI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABAACgABAFsADwAC AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AG8AbgB0AAAAAAAAAAAAAAAAADAAWkABAPIAMAAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIA DwAIAE9KAwBRSgMAAAAAAA8jAQADAADeAQASAP////8ABAAAxkUAANJZAAAymQAAgfYAAA0hAQCU AAAApwAAAK0AAADCAAAA4QAAAAAEAAA5CgAA4Q0AAAoVAADuGwAAqCIAAGwnAAAdLgAA1TMAAEY2 AACPOQAACD0AAMJBAAAmRQAA4kgAAHNLAAAOTwAASVMAAJFXAABEXQAAu2EAAM5kAADjZgAA5WoA ACZuAAAccwAAsXYAAEl7AACZfgAAuoAAAL+FAADQiAAA34wAADWRAADMlAAAVZoAAOOdAABnoQAA dKUAAHCoAADOqwAAMbAAANSzAADytwAA6rkAAFC/AADwwgAA4McAALvMAADd0AAADtQAAN7YAAAd 3gAAgeMAAPzlAACj6AAAKe0AAC3wAAAU9QAAl/cAAH78AAAcAQEAtgUBAKYJAQD5DQEAXg4BAKUT AQCVGAEAkR4BAA0hAQCVAAAAlwAAAJgAAACZAAAAmwAAAJwAAACdAAAAnwAAAKAAAAChAAAAogAA AKMAAACkAAAApgAAAKgAAACpAAAAqgAAAKsAAACsAAAArgAAALAAAACxAAAAsgAAALMAAAC0AAAA tgAAALcAAAC4AAAAuQAAALsAAAC8AAAAvQAAAL4AAADAAAAAwQAAAMMAAADEAAAAxQAAAMcAAADI AAAAyQAAAMoAAADMAAAAzQAAAM4AAADPAAAA0QAAANIAAADTAAAA1AAAANYAAADXAAAA2AAAANoA AADbAAAA3AAAAN0AAADeAAAA4AAAAOIAAADjAAAA5QAAAOYAAADnAAAA6AAAAOoAAADrAAAA7AAA AO4AAAAABAAAvxgAAEgtAABYRAAAtV0AAO1uAAA5gAAAFZAAAPWhAABlsQAAVMEAACLRAACv4gAA jPEAAPMAAQADDgEAUR0BAA0hAQCWAAAAmgAAAJ4AAAClAAAArwAAALUAAAC6AAAAvwAAAMYAAADL AAAA0AAAANUAAADZAAAA3wAAAOQAAADpAAAA7QAAAP//AgAAAAcAVQBuAGsAbgBvAHcAbgAFAGIA cgBhAGoAYQAAAAAALgAAADUAAAA3AAAAPwAAAHEAAAB8AAAAfgAAAIMAAADKAAAA0QAAABMBAAAa AQAAVAEAAFkBAABbAQAAYwEAAKQBAACsAQAA5AEAAO4BAADwAQAA+AEAADkCAABBAgAAvwIAAMcC AADJAgAA0AIAAA8DAAASAwAAGgMAACIDAABbAwAAXQMAAF8DAABmAwAACQQAAA4EAAAPBAAAFwQA ABkEAAAhBAAAWgQAAF4EAABgBAAAZwQAAMEHAADKBwAARgoAAE4KAABZCgAAXQoAAGwKAAB5CgAA ewoAAH8KAADJCgAA1QoAANcKAADcCgAAtQwAALcMAACjEQAAsBEAALoRAADBEQAAfhIAAI4SAACY EgAAnxIAAMcSAADXEgAA4RIAAOgSAADrEwAA9xMAAAEUAAAIFAAAxhQAANUUAADfFAAA5hQAAA8V AAAfFQAAKRUAADAVAABYFQAAZRUAAG8VAAB2FQAAoRUAALEVAAC7FQAAwhUAAOoVAADyFQAA/BUA AAMWAAAzFgAAPhYAAEgWAABPFgAAJxgAAC8YAAA6GAAAPhgAAE0YAABaGAAAXBgAAGAYAACqGAAA thgAALgYAAC9GAAAOBsAADobAAAkHwAAKB8AAHggAACAIAAAtyAAALsgAADnIQAA6yEAADcoAAA7 KAAAxCgAAMkoAADzKAAA+CgAAEErAABFKwAANC8AAD8vAACMMAAAjzAAALgyAAC8MgAADzMAABcz AAC1NwAAujcAAM1BAADXQQAAdEIAAHhCAADIQgAAzEIAANlCAADdQgAA4kIAAOZCAABtQwAAcUMA AHlDAAB/QwAApUMAAKlDAAAJRAAAD0QAAGlFAACBRQAAl0UAAKJFAACnRQAAtUUAAHdGAAB/RgAA qEYAALZGAADjSwAA7ksAAHVMAAB5TAAAmUwAAKRMAADTTAAA10wAAChNAAAsTQAAGE4AABxOAABc UgAAYFIAAF5jAABoYwAAaWMAAGtjAACWYwAAmGMAAAZnAAAQZwAAmmcAAKRnAAA8agAAQGoAAHpq AACEagAA/WoAAAdrAABgbQAAZG0AAJttAACfbQAA1m0AANptAAARbgAAFW4AAExuAABQbgAAh24A AItuAADDbgAAx24AAP5uAAACbwAAOG8AADxvAAB0bwAAeG8AALBvAAC0bwAA6m8AAO5vAAAlcAAA KXAAAFJwAABWcAAAYXAAAGVwAACccAAAoHAAANdwAADbcAAAE3EAABdxAAAJcgAADnIAAKJ0AACn dAAABncAAAt3AABedwAAY3cAAEyEAABQhAAAOIYAAD6GAADPjAAA04wAAAqWAAAOlgAA6ZoAAO2a AACAnQAAhJ0AAKCeAACtngAAv54AAMyeAAD2ngAAA58AAA2fAAAUnwAAKZ8AADafAADBnwAAzp8A APqfAAAHoAAAM6AAAECgAAC5oAAAyaAAABChAAAdoQAAPqEAAE6hAADWoQAA2aEAAP6hAAALogAA KqIAADeiAABUogAAYaIAAAOkAAAMpAAA26QAAN+kAACPpQAAmKUAABOmAAAcpgAA0qYAAOKmAAD2 pgAAA6cAAOmtAAD0rQAAorYAAK22AABGuQAAVrkAAGC5AABnuQAAfLkAAIy5AADEuQAAyLkAANC5 AADduQAAProAAE66AABtugAAfboAAI26AACdugAAtbsAAL67AAC7vAAAxLwAAPa8AAADvQAAib0A AJa9AAD+vgAADr8AABi/AAAfvwAANL8AAES/AAD+vwAADsAAADDAAAA9wAAAbcAAAH3AAACnwAAA t8AAANbAAADmwAAA8MEAAPnBAADIwgAAzMIAAH3DAACGwwAAAcQAAArEAADCxAAA1cQAAOXEAAD1 xAAAHsUAACLFAAAzxQAAN8UAAMfNAADLzQAAR84AAFbOAADFzwAAzc8AAOjPAAD0zwAA/s8AAAXQ AACv0AAAu9AAAGrRAAB20QAAkdEAAKDRAACk0QAAtNEAAM3RAADZ0QAA+NEAAATSAAAh0gAALdIA ADfTAABA0wAAD9QAABPUAADE1AAAzdQAAEjVAABR1QAAB9YAABfWAAAr1gAAONYAAKrkAAC55AAA w+QAAMrkAADf5AAA7uQAACXlAAAp5QAAMeUAAD3lAACo5QAAt+UAANblAADl5QAA9eUAAATmAAAc 5wAAJecAACLoAAAr6AAAXegAAGroAADw6AAA/egAADDpAABA6QAASukAAFHpAABm6QAAdukAALXp AAC56QAAwekAAM3pAAAP6wAAH+sAAD7rAABO6wAAXusAAG7rAAAc7QAAJe0AAIjuAACM7gAAOu8A AEPvAAB17wAAgu8AAAjwAAAV8AAAU/AAAFfwAAB18AAAefAAAJ/wAACr8AAA7fAAAPHwAAAb8QAA KPEAADLxAAA58QAATvEAAFvxAAAe8gAAK/IAAEzyAABc8gAAEfMAAB7zAAA98wAASvMAAGfzAAB0 8wAAG/UAACT1AACo9gAAsfYAACz3AAA19wAA6/cAAPv3AABP+QAAX/kAAGn5AABw+QAAhfkAAJX5 AADG+QAA0/kAAAb6AAAW+gAANfoAAEX6AABV+gAAZfoAAH37AACG+wAAg/wAAIz8AAC+/AAAy/wA AOb9AADz/QAAK/4AADP+AAA9/gAARP4AAFn+AABh/gAA/P4AAAT/AAAl/wAAMP8AAF//AABn/wAA hv8AAI7/AACr/wAAs/8AAL0AAQDGAAEAlQEBAJkBAQBKAgEAUwIBAM4CAQDXAgEAjwMBAJoDAQCt AwEAtQMBAN4DAQDiAwEAFgQBABoEAQCNBAEAmAQBAKIEAQCpBAEAvgQBAMkEAQAJBQEAEQUBACoF AQA1BQEAVAUBAF8FAQB8BQEAhwUBACYHAQAvBwEA/gcBAAIIAQCzCAEAvAgBAO0IAQD1CAEAHQkB ACgJAQDdCgEA5AoBAGcLAQCMCwEA3gsBAOULAQBvDAEAeQwBAH8MAQCHDAEAqAwBALQMAQC9DAEA xQwBALwNAQDEDQEAyg0BANENAQCwDgEAuA4BAL4OAQDFDgEAyw4BANMOAQC2DwEAug8BAMAPAQDF DwEA1g8BAN4PAQDkDwEA6w8BAA8QAQATEAEAGRABAB4QAQAkEAEAKxABAEMQAQBIEAEA+hABAAIR AQBZEQEAbREBALESAQC6EgEAtRQBALoUAQC7FAEAwxQBAO0UAQD1FAEAFRUBAB0VAQD+FQEAAxYB AAQWAQAOFgEAMhYBADYWAQA9FgEARRYBAGUWAQBsFgEArBYBALUWAQDqFgEA8BYBAHUXAQB7FwEA fBcBAIQXAQCKFwEAkRcBALIXAQC5FwEAlxgBAJwYAQCdGAEAohgBAMYYAQDNGAEA1BgBANwYAQD8 GAEABBkBABgZAQAhGQEAQBkBAEkZAQAeGgEAJhoBAEYaAQBNGgEAYRoBAGoaAQADGwEABhsBACsb AQAtGwEAORsBAEEbAQBbGwEAYhsBAHMbAQB6GwEArxsBALYbAQA5HAEAQBwBAEEcAQBMHAEAUhwB AFccAQAPHQEABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAABIAAAAsAAAAVAAAAG8AAACt AAAAwQAAAI0FAACqBQAAPAYAAD8GAACIBgAAiwYAAAIHAAAHBwAAZgcAAGkHAACZBwAAnwcAAOIH AADkBwAAIggAACsIAAAkCQAARAkAAKEJAACyCQAALwoAADcKAABsCgAAeQoAALQKAAC3CgAA9woA AP4KAAA7CwAAQgsAABEMAAAaDAAAVgwAAF4MAACdDAAAnwwAALkMAADFDAAA3wwAAOYMAACtDQAA 5A0AABIOAAAtDgAATw4AAHYOAACPDgAAvw4AANkOAAAIDwAAHw8AAFEPAABqDwAAmg8AAMwPAADi DwAA9w8AACsQAABTEAAAdBAAAJEQAAC9EAAA0xAAAAYRAAAtEQAATxEAAGgRAACYEQAAyBEAAOER AAAAEgAAKhIAAEcSAABzEgAAphIAALwSAADvEgAABRMAACQTAABOEwAAaxMAAJcTAACwEwAA4BMA AA8UAAApFAAATRQAAHIUAACIFAAAuxQAAO0UAAAEFQAANxUAAE0VAAB9FQAAlhUAAMkVAADfFQAA ChYAACgWAABWFgAAcRYAAI8WAAC6FgAAyxYAAAMXAAAcFwAATBcAAKQXAAC1FwAATRgAAFoYAACV GAAAmBgAAN4YAADjGAAAIhkAAC8ZAABpGQAAaxkAAKoZAACzGQAA8BkAAPsZAAB3GgAAfhoAALka AADAGgAA/xoAAAMbAABFGwAASxsAANIbAADcGwAAXRwAAGUcAAA2HwAAOB8AAH0fAACEHwAAwB8A AMgfAAAGIAAACyAAAEwgAABRIAAA3SAAAOEgAAAgIQAAJyEAAGUhAABtIQAArSEAAK8hAAD2IQAA +yEAAJwiAACtIgAAEyYAABUmAABcJgAAZiYAAKUmAACxJgAA6CYAAO8mAAB0JwAAfScAAL0nAADG JwAABigAAAgoAABGKAAAUCgAAI0oAACWKAAASykAAE4pAACTKQAAlykAAF8qAABpKgAApyoAALAq AADoKgAA8SoAAC8rAAAyKwAAUS0AAFMtAACQLQAAmy0AANMtAADgLQAAFi4AACEuAABcLgAAXy4A AKMuAACvLgAA6y4AAO4uAAB8LwAAgS8AAMAvAADJLwAAdDAAAHYwAAD5MAAACjEAAIMxAACGMQAA xDMAANAzAAAJNAAAFDQAAFI0AABVNAAAmzQAAKQ0AADkNAAA5jQAAG81AAB3NQAA2jYAAN02AAAg NwAAJDcAAGM3AABpNwAAqTcAALA3AADxNwAA+jcAADc4AAA7OAAAfDgAAIM4AADDOAAAyjgAAAs5 AAASOQAAUTkAAFQ5AACZOQAAnTkAAOA5AADjOQAAbDoAAHg6AAD4OgAABTsAADk7AABFOwAAzDsA AM47AAB0PAAAhTwAAPo8AAABPQAAQj0AAEc9AACKPQAAkT0AABdAAAAfQAAAW0AAAGRAAADmQAAA 7EAAACZBAAAqQQAAHUMAACNDAABQRQAAWUUAAN5FAADnRQAAHEYAAChGAABlRgAAaEYAAPFGAAD1 RgAAUUkAAGNJAADcTAAA5UwAACRNAABOTQAAXU0AAGxNAACmTQAArU0AAORNAADxTQAAPE4AAEFO AAB5TgAAjk4AAFFPAABgTwAA7lEAAP9RAACGUgAAiVIAAIRTAACJUwAA3VMAAOFTAABgVAAAZFQA AKNUAACrVAAA7FQAAPZUAAAzVQAAOVUAAHVVAACCVQAAvVUAAL9VAACTVwAAqFcAAG5YAAB8WAAA TloAAFNaAAAAWwAABFsAAEdbAABMWwAAplsAAKtbAAAxXAAAQlwAAHRcAAB9XAAAulwAAMRcAAD3 XAAAA10AAD1dAABDXQAAfF0AAIZdAACyXgAAtl4AAPpeAAD/XgAAQF8AAEVfAACHXwAAjl8AAM1f AADQXwAAEWAAABZgAABZYAAAXmAAAKBgAACsYAAAb2EAAHlhAAC1YQAAwGEAAPlhAAD+YQAAQWIA AERiAACkYgAArGIAAORiAADuYgAAmGMAAJpjAACoZAAAq2QAAOpkAAD/ZAAAxWUAANNlAAC1aAAA xmgAAChpAAA5aQAAgGkAAJFpAACmaQAAuGkAAM1pAADeaQAA8WkAAANqAAAWagAAJGoAADNqAABA agAAT2oAAF5qAADDawAAymsAAE1sAABXbAAAomwAALZsAABkbQAAfW0AAJ9tAAC4bQAA2m0AAPNt AAAVbgAALm4AAFBuAABpbgAAi24AAKRuAADHbgAA324AAAJvAAAabwAAPG8AAFVvAAB4bwAAkG8A ALRvAADLbwAA7m8AAAZwAAApcAAAQXAAAGVwAAB8cAAAoHAAALdwAADbcAAA8nAAABdxAAAtcQAA j3EAAKBxAAAJcgAALXIAAFByAABacgAAlnIAAJ1yAACdcwAAsnMAAHV0AACDdAAAn3QAAKF0AACw dQAAvHUAAAN3AAAFdwAA1XcAAN53AAAdeAAAH3gAAJR4AACpeAAAb3kAAH15AABSewAAWnsAAPt7 AAAMfAAABX0AAA19AABKfQAAUX0AAIt9AACXfQAA0X0AANR9AAAZfgAAG34AAE1+AABifgAAKH8A ADZ/AADqfwAA838AAHCBAAB3gQAAuIEAALqBAAAkgwAAL4MAAG2DAABvgwAAr4MAALiDAACQhAAA pYQAAGuFAAB5hQAA34YAAPCGAADqhwAA7ocAAFGIAABZiAAAz4gAAN2IAACNiQAAnIkAAPyJAAAA igAASIoAAFeKAAC3igAAu4oAAAOLAAAPiwAAdIsAAH+LAAC2iwAAx4sAAB+MAAApjAAAPowAAEmM AACwjAAAtYwAAPmMAAD+jAAAlY0AAKaNAAA7jgAAPY4AAFuOAABwjgAANo8AAESPAADUkAAA5pAA AG6RAAB1kQAAhJEAAJmRAABfkgAAbZIAAJOWAACilgAAdJcAAIWXAAA8mAAARpgAABOZAAAYmQAA c5kAAHeZAAC5mQAAvJkAAKGaAACmmgAAK5sAADSbAAB0mwAAfJsAALSbAAC9mwAA+psAAP+bAAAj nQAAJ50AAGqdAAB2nQAAsZ0AALedAAD4nQAA/Z0AAIKeAACGngAAa58AAG+fAACtnwAAtp8AAO6f AAD3nwAAeqAAAIGgAAAvoQAANqEAAKKhAACjoQAAE6IAABaiAADWogAA56IAABqjAAAvowAA+qUA AP2lAABCpgAASaYAAIumAACQpgAAOqcAAEGnAACDpwAAh6cAANKnAADnpwAAoagAALCoAADiqgAA 56oAAImrAACMqwAAPKwAAE2sAADFrAAA16wAADutAABHrQAAia0AAJStAADVrQAA5q0AACauAAAu rgAAZ64AAHCuAACvrgAAuK4AAN+vAADrrwAAf7AAAIOwAAARsQAAErEAAFOxAABosQAAIrIAADGy AABctAAAYbQAAPW0AAAGtQAAfrUAAJC1AAD0tQAAALYAAEK2AABNtgAAjrYAAJ+2AADftgAA57YA ACC3AAAptwAAaLcAAHG3AACbtwAAp7cAADu4AAA/uAAAv7gAAMa4AAADuQAADLkAAL25AADDuQAA BboAAAq6AABWugAAWboAAMq6AADfugAAG70AACe9AACgvQAAp70AALK+AADDvgAAeb8AAH2/AAC9 vwAAxr8AAPq/AAAOwAAAIMAAACfAAACFwAAAiMAAANDAAADmwAAAB8EAABzBAADowwAA68MAADDE AAA3xAAAecQAAH7EAADixAAA9cQAACnFAAArxQAAbcUAAHbFAAC9xQAA0sUAAIzGAACbxgAARcgA AFbIAADVyAAA2sgAANjJAADtyQAAp8oAALbKAABVzAAAWswAALHMAAC3zAAAqs0AALbNAAAczgAA JM4AAOzOAADzzgAANc8AADvPAACjzwAAqs8AAGjQAAB50AAA8NAAAPTQAAA40QAAOdEAAHvRAACC 0QAA4dEAAOTRAABO0gAAY9IAAC/VAAAy1QAAd9UAAH7VAADA1QAAxdUAAG/WAAB21gAAuNYAALzW AAAB1wAAFtcAANDXAADf1wAAEdoAABbaAABx2gAAgtoAAErbAABM2wAAndsAAKLbAAC22wAAvNsA APvbAAAQ3AAAytwAANncAAAA3gAAEN4AALLeAADS3gAAI+AAACjgAADI4AAAyuAAAJniAACe4gAA OuMAAEvjAADo4wAA6+MAADHkAAA25AAAeeQAAHvkAABh5QAAauUAAL/lAADC5QAAMeYAAEbmAACC 6AAAjugAAAfpAAAO6QAAq+kAAK7pAADs6QAA9ekAADTqAAA36gAAcOoAAHvqAAAn6wAAKusAAO3r AAD+6wAAMewAAEbsAACa7wAApu8AAB/wAAAm8AAAtfAAALzwAAD78AAA/vAAAJDxAACU8QAA2PEA AOLxAAA98gAARPIAACbzAAAp8wAA7vMAAP/zAAAy9AAAR/QAANH1AADt9QAAE/cAABb3AABb9wAA YvcAAKT3AACp9wAAIPgAACX4AADP+AAA0fgAAB76AAAh+gAAkvoAAKf6AADj/AAA7/wAAHH9AACC /QAA/f0AAAT+AACe/gAApf4AAG//AABy/wAA1P8AAOn/AAC1AgEAuAIBAP0CAQAEAwEARgMBAEsD AQCqAwEAtQMBAOsDAQD0AwEAMQQBADoEAQB1BAEAeQQBAP0EAQAGBQEAPQUBAEAFAQD5BQEACgYB AD0GAQBSBgEAZwoBAHgKAQCfCwEApgsBADgNAQA9DQEAdQ0BAIANAQAEDgEABg4BAEoOAQBlDgEA iA8BAJAPAQDUEAEA4hABAIARAQCHEQEA/REBAAgSAQABEwEADRMBAFETAQBZEwEA2BMBAOMTAQBV FAEAZhQBALsUAQDfFAEA9hQBAB0VAQA7FQEAWhUBAHwVAQCeFQEArxUBALQVAQAEFgEALhYBAEYW AQBsFgEAfxYBAKsWAQDPFgEA8BYBAAAXAQAFFwEAUhcBAHsXAQCSFwEAuRcBANIXAQD1FwEAFRgB ADMYAQBJGAEAThgBAJ0YAQDFGAEA3RgBAAQZAQAiGQEAPxkBAGUZAQCIGQEAmBkBAJ0ZAQDnGQEA DBoBACcaAQBNGgEAaxoBAIoaAQClGgEAwhoBANwaAQDhGgEAAxsBACobAQA5GwEAYhsBAIIbAQCZ GwEAuxsBANobAQDvGwEA9BsBAFIcAQBmHAEAmhwBAJ8cAQAPHQEABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHAP//FAAAAAUAYgByAGEAagBhADwARAA6AFwAVABlAGwAbABpAHUAbQBcAGQAcgBh AGYAdABzAFwAbABtAHAAXABkAHIAYQBmAHQALQBmAHIAZQBkAGUAdAB0AGUALQBsAG0AcAAtAHcA ZABtAC0AMAAxAC0AYwBvAG0AbQBlAG4AdABzAC4AZABvAGMABQBiAHIAYQBqAGEAPABEADoAXABU AGUAbABsAGkAdQBtAFwAZAByAGEAZgB0AHMAXABsAG0AcABcAGQAcgBhAGYAdAAtAGYAcgBlAGQA ZQB0AHQAZQAtAGwAbQBwAC0AdwBkAG0ALQAwADEALQBjAG8AbQBtAGUAbgB0AHMALgBkAG8AYwAF AGIAcgBhAGoAYQBDAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA YQB2AGUAIABvAGYAIABkAHIAYQBmAHQALQBmAHIAZQBkAGUAdAB0AGUALQBsAG0AcAAtAHcAZABt AC0AMAAxAC0AYwBvAG0AbQBlAG4AdABzAC4AYQBzAGQABQBiAHIAYQBqAGEAQwBDADoAXABUAEUA TQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAZAByAGEAZgB0 AC0AZgByAGUAZABlAHQAdABlAC0AbABtAHAALQB3AGQAbQAtADAAMQAtAGMAbwBtAG0AZQBuAHQA cwAuAGEAcwBkAAUAYgByAGEAagBhAEMAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2 AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGQAcgBhAGYAdAAtAGYAcgBlAGQAZQB0AHQAZQAtAGwA bQBwAC0AdwBkAG0ALQAwADEALQBjAG8AbQBtAGUAbgB0AHMALgBhAHMAZAAFAGIAcgBhAGoAYQBD AEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYA IABkAHIAYQBmAHQALQBmAHIAZQBkAGUAdAB0AGUALQBsAG0AcAAtAHcAZABtAC0AMAAxAC0AYwBv AG0AbQBlAG4AdABzAC4AYQBzAGQABQBiAHIAYQBqAGEAPABEADoAXABUAGUAbABsAGkAdQBtAFwA ZAByAGEAZgB0AHMAXABsAG0AcABcAGQAcgBhAGYAdAAtAGYAcgBlAGQAZQB0AHQAZQAtAGwAbQBw AC0AdwBkAG0ALQAwADEALQBjAG8AbQBtAGUAbgB0AHMALgBkAG8AYwAFAGIAcgBhAGoAYQBDAEMA OgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABk AHIAYQBmAHQALQBmAHIAZQBkAGUAdAB0AGUALQBsAG0AcAAtAHcAZABtAC0AMAAxAC0AYwBvAG0A bQBlAG4AdABzAC4AYQBzAGQABQBiAHIAYQBqAGEAPABEADoAXABUAGUAbABsAGkAdQBtAFwAZABy AGEAZgB0AHMAXABsAG0AcABcAGQAcgBhAGYAdAAtAGYAcgBlAGQAZQB0AHQAZQAtAGwAbQBwAC0A dwBkAG0ALQAwADEALQBjAG8AbQBtAGUAbgB0AHMALgBkAG8AYwAFAGIAcgBhAGoAYQA8AEQAOgBc AFQAZQBsAGwAaQB1AG0AXABkAHIAYQBmAHQAcwBcAGwAbQBwAFwAZAByAGEAZgB0AC0AZgByAGUA ZABlAHQAdABlAC0AbABtAHAALQB3AGQAbQAtADAAMQAtAGMAbwBtAG0AZQBuAHQAcwAuAGQAbwBj AAIApXEHCQ8ACQT/D/8P/w//D/8P/w//D/8P/w8BAEVzQycPAAkE/w//D/8P/w//D/8P/w//D/8P AQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAAuAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAAC4AAgAAAKVx BwkAAAAAAAAAAAAAAABFc0MnAAAAAAAAAAAAAAAA/////////////wIAAAAAAAAA/0ABgAEAZDEA AGQxAABMeywBAQABAGQxAAAAAAAAWDEAAAAAAAACEAAAAAAAAAANHQEAMAAACABAAAAEAAAARxaQ AQAAAgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAA UgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBt AGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEA bAAAAD81kAEAAAIHAwkCAgUCBASHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABDAG8AdQByAGkAZQBy ACAATgBlAHcAAAAiAAQAcIiIGAAA0AIAAGgBAAAAAGPsVwZy7VcGAAAAAAoAogAAABoqAAD/7wAA AQB6AAAABAADEP8BAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAXAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAApQbAB7QAtACAADIwAAAQABkAZAAAABkAAAC7JgEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP// EgAAAAAAAAAAAAAAAAAAAAUAYgByAGEAagBhAAUAYgByAGEAagBhAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAABkAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAAMAAAAAG AAAAzAAAAAcAAADYAAAACAAAAOgAAAAJAAAA+AAAABIAAAAEAQAACgAAACABAAAMAAAALAEAAA0A AAA4AQAADgAAAEQBAAAPAAAATAEAABAAAABUAQAAEwAAAFwBAAACAAAA5AQAAB4AAAABAAAAAABz AB4AAAABAAAAAABzAB4AAAAGAAAAYnJhamEAZgAeAAAAAQAAAAByYWoeAAAAAQAAAAByYWoeAAAA BwAAAE5vcm1hbAAAHgAAAAYAAABicmFqYQAAAB4AAAADAAAAMTAAah4AAAATAAAATWljcm9zb2Z0 IFdvcmQgOC4wAABAAAAAAEySoRYAAABAAAAAAJrCUXYYwQFAAAAAAFRF8ZkYwQEDAAAAAQAAAAMA AAAaKgAAAwAAAP/vAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAA BdXN1ZwuGxCTlwgAKyz5rjgBAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQ AAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgA AAAMAAAA1QAAAAIAAADkBAAAHgAAAA4AAABUZWxsaXVtLCBJbmMuADQAAwAAAP8BAAADAAAAegAA AAMAAAC7JgEAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA AQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2 AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsANAA2AEMA RgAxADQAOQA2AC0AOAA0ADYAOAAtADEAMQBEADUALQA4ADEANAA4AC0AMAAwADAAMAAwADAAMAAw ADAAMAAwADAAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAd AAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAA ADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAA SAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABW AAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQA AABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAA AHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAA gQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACP AAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0A AACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAA AKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAA ugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADI AAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYA AADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAA AOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA/v////EAAADyAAAA 8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAAB AQAAAgEAAAMBAAAEAQAABQEAAAYBAAAHAQAACAEAAAkBAAAKAQAA/v///wwBAAANAQAADgEAAA8B AAAQAQAAEQEAABIBAAD+////FAEAABUBAAAWAQAAFwEAABgBAAAZAQAAGgEAAP7////9/////f// //3///8fAQAA/v////7////+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAABgS/ZcdhjBAVAgzw6aGMEB IQEAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADwAAAAYzQAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAe3gEAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwEAAAAQAAAAAAAABQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT AQAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAABQIM8OmhjBAVAgzw6aGMEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wEA/v8D CgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1T V29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_000_01C11905.4F0CA366-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 07:04:18 -0700 Message-Id: <200107301359.JAA22631@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lmp-00.txt Date: Mon, 30 Jul 2001 09:59:23 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang et al. Filename : draft-ietf-ccamp-lmp-00.txt Pages : 57 Date : 27-Jul-01 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels, links, and bundled links. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage traffic engineering (TE) links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010727132406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010727132406.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jul 2001 06:58:03 -0700 Message-ID: <3B656722.D9B866A7@lucent.com> Date: Mon, 30 Jul 2001 09:54:42 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. 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, May I ask why draft-xu-bgp-gmpls-01.txt is not in the list? Thanks, Yangguang Kireeti Kompella wrote: > > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 18:57:51 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590AFD009@MILAN> From: dguo@turinnetworks.com To: eric.gray@sandburst.com, kireeti@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: Drafts update Date: Fri, 27 Jul 2001 18:56:32 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11708.864CEC90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11708.864CEC90 Content-Type: text/plain; charset="iso-8859-1" I would second Eric except putting "YES" to #2. My point is that the "common" control plane must tackle "specific" issues to be "common" - we so far have gmpls framework in place and several "thinner" docs on the top for gmpls to support sonet/sdh,wdm,... G709 might be legitimate/special enough to warrant study. just my 2c. -Dan Guo -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] SSubject: Re: Drafts update Kireeti, My revised answer: 1. Yes, CCAMP 2. Wait to hear why this is a 'common control and management plane' issue as opposed to an optical networking specific issue. 3. Yes 4. Wait until after London meeting to gauge its acceptance there 5. Wait until after London meeting to gauge its acceptance there 6. Yes ------_=_NextPart_001_01C11708.864CEC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Drafts update

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

-Dan Guo

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

------_=_NextPart_001_01C11708.864CEC90-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 18:28:59 -0700 From: "manoj juneja" To: DCheng@PolarisNetworks.com, ccamp@ops.ietf.org Cc: v.sharma@ieee.org Bcc: Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt Date: Fri, 27 Jul 2001 18:24:18 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dean, I think the routing module should be aware of only the data channel interfaces and not the control channels/interfaces (at least not for routing of GMPLS messages). There may be 2 cases where either there will be one-to-one mapping between the control channel and data channel or multiple data channel interfaces will be served by 1 common control channel. Once I get the information from routing module that which specific outgoing data channel/interface is used for resource allocation then I can very well get the control channel where to send the control traffic. Initially when I configure my data channel/interfaces, I can configure the information that which control channel/interface this data channel/interface has to use. Regards, manoj. >From: "Cheng, Dean" >To: 'manoj juneja' , ccamp@ops.ietf.org >CC: v.sharma@ieee.org >Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt >Date: Fri, 27 Jul 2001 18:04:34 -0700 > >Manoj, > > The routing module certainly needs to be aware of > control channel network for reasons including the > following: > > 1) To route/forward control protocol packets > including OSPF/ISIS/RSVP/CR-LDP. > > 2) To route/forward management traffic if > chosen to do so. > >Dean > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Friday, July 27, 2001 5:20 PM >To: ccamp@ops.ietf.org >Cc: v.sharma@ieee.org >Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt > > >Hi All, > I have gone through draft-many-ccamp-gmpls-routing-00.txt and >draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers >to > >the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned >that control channels are advertised into routing as normal >links. But the IInd draft (ospf-gmpls) has not mentioned anything about >it. Should the routing module be aware of control channel network ? I >feel it should not. > >After reading the IInd draft it seems that routing module should not be >aware of control channel (network) but I got this doubt as the IInd >draft makes reference to the Ist one. > >Please clarify. > >Regards, >manoj. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 18:12:38 -0700 Message-ID: From: "Cheng, Dean" To: 'manoj juneja' , ccamp@ops.ietf.org Cc: v.sharma@ieee.org Subject: RE: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt Date: Fri, 27 Jul 2001 18:04:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, The routing module certainly needs to be aware of control channel network for reasons including the following: 1) To route/forward control protocol packets including OSPF/ISIS/RSVP/CR-LDP. 2) To route/forward management traffic if chosen to do so. Dean -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Friday, July 27, 2001 5:20 PM To: ccamp@ops.ietf.org Cc: v.sharma@ieee.org Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt Hi All, I have gone through draft-many-ccamp-gmpls-routing-00.txt and draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers to the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned that control channels are advertised into routing as normal links. But the IInd draft (ospf-gmpls) has not mentioned anything about it. Should the routing module be aware of control channel network ? I feel it should not. After reading the IInd draft it seems that routing module should not be aware of control channel (network) but I got this doubt as the IInd draft makes reference to the Ist one. Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 17:22:16 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: v.sharma@ieee.org Bcc: Subject: Doubt in draft draft-many-ccamp-gmpls-routing-00.txt Date: Fri, 27 Jul 2001 17:19:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have gone through draft-many-ccamp-gmpls-routing-00.txt and draft-kompella-ospf-gmpls-extensions-02.txt drafts. The IInd draft refers to the Ist draft. In section 5.1 of Ist draft (gmpls-routing) it is mentioned that control channels are advertised into routing as normal links. But the IInd draft (ospf-gmpls) has not mentioned anything about it. Should the routing module be aware of control channel network ? I feel it should not. After reading the IInd draft it seems that routing module should not be aware of control channel (network) but I got this doubt as the IInd draft makes reference to the Ist one. Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 17:09:47 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: lberger@movaz.com, Eric.Mannie@ebone.com Bcc: Subject: Doubt in draft draft-ietf-mpls-generalized-signalling-05.txt Date: Fri, 27 Jul 2001 17:08:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have following doubt in "draft-ietf-mpls-generalized -signalling-05.txt" draft. This draft has introduced new field switching type in Generalized Label Request Object. After looking at the structure of switching type field in latest OSPF document (GMPLS extensions to OSPF, Field Name : Interface switching capability descriptor), I could not make out why this is present in per LSP establishment request ? This field advertises the bandwidth (both min. and max.) for various priority levels (p = 0 -> 7). Furthermore, this field also contain Encoding (I assume LSP encoding type) field which is already there in Generalized Label Reqest object. I am not able to understand why this type of information is required in Per Connection Establishment Request ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 15:03:01 -0700 Message-ID: <3B61E4E8.26F73B6F@sandburst.com> Date: Fri, 27 Jul 2001 18:02:16 -0400 From: Eric Gray 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, My revised answer: 1. Yes, CCAMP 2. Wait to hear why this is a 'common control and management plane' issue as opposed to an optical networking specific issue. 3. Yes 4. Wait until after London meeting to gauge its acceptance there 5. Wait until after London meeting to gauge its acceptance there 6. Yes You wrote: > > 4. draft-many-ccamp-gmpls-framework-00.txt > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 14:48:22 -0700 Date: Fri, 27 Jul 2001 14:45:47 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107272145.OAA12990@kummer.juniper.net> To: eric.gray@sandburst.com, kireeti@juniper.net Subject: Re: Drafts update Cc: ccamp@ops.ietf.org Hi Eric, > Is there any reason why you skipped number 4? Is "I failed kindergarten" a valid excuse? Thanks, Eric: I missed one, through the excessive use of cut and insufficient use of paste: 4. draft-many-ccamp-gmpls-framework-00.txt Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 14:32:59 -0700 Message-ID: <3B61DDCB.3CC3F33A@sandburst.com> Date: Fri, 27 Jul 2001 17:31:55 -0400 From: Eric Gray 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, Is there any reason why you skipped number 4? Here's my answers to 1-3 and 5-6... 1. Yes, CCAMP 2. Wait to hear why this is a 'common control and management plane' issue as opposed to an optical networking specific issue. 3. Yes 5. Wait until after London meeting to gauge its acceptance there 6. Yes You wrote: > Hi Folks, > > Can we get a sense of the consensus whether the following drafts > should be made CCAMP WG documents? Please respond with > (a) yes > (b) no > (c) wait > > 1. draft-dubuc-lmp-mib-02.txt > 2. draft-fontana-ccamp-gmpls-g709-00.txt > 3. draft-kompella-ospf-gmpls-extensions-02.txt > 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > 6. draft-many-ccamp-gmpls-routing-00.txt > > (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this > be a WG document, either in MPLS or CCAMP.) > > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 14:18:39 -0700 Message-ID: From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: Drafts update Date: Fri, 27 Jul 2001 14:17:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Response attached. Thanks, Ayan -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, July 27, 2001 1:37 PM To: ccamp@ops.ietf.org Subject: Drafts update Hi Folks, Can we get a sense of the consensus whether the following drafts should be made CCAMP WG documents? Please respond with (a) yes (b) no (c) wait 1. draft-dubuc-lmp-mib-02.txt [YES] 2. draft-fontana-ccamp-gmpls-g709-00.txt 3. draft-kompella-ospf-gmpls-extensions-02.txt [YES] 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt 6. draft-many-ccamp-gmpls-routing-00.txt [YES] (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this be a WG document, either in MPLS or CCAMP.) Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 13:38:34 -0700 Date: Fri, 27 Jul 2001 13:37:16 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107272037.NAA12320@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Drafts update Hi Folks, Can we get a sense of the consensus whether the following drafts should be made CCAMP WG documents? Please respond with (a) yes (b) no (c) wait 1. draft-dubuc-lmp-mib-02.txt 2. draft-fontana-ccamp-gmpls-g709-00.txt 3. draft-kompella-ospf-gmpls-extensions-02.txt 5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt 6. draft-many-ccamp-gmpls-routing-00.txt (Note: for draft-dubuc-lmp-mib-02.txt, the question is, should this be a WG document, either in MPLS or CCAMP.) Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 13:23:17 -0700 Date: Fri, 27 Jul 2001 13:21:24 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107272021.NAA12054@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP agenda Hi, Here is the CCAMP agenda. If we've missed you, or you'd like a slot, send mail to us (the WG chairs, *not* the list), and we'll see if we can accommodate you. Kireeti & Vijay. --------------- Administrivia/Blue Sheets/ Minutes takers 5 min Charter & drafts update 10 min Update from the Design Teams 10 min GMPLS update (Lou Berger) 10 min SONET/SDH (Eric Mannie) 15 min G709 (Dimitri?) 10 min Architecture (Eric Mannie) 10 min Framework (Yangguang Xu) 5 min SONET/SDH framework (Greg B.) 5 min LMP (Jonathan Lang) 5 min OLI Reqts (Andre+Osama) 5 min NTIP (Osama Aboul-Magd) 10 min LMP-WDM (Andre Fredette) 10 min resolution 5 min Tunnel Trace (Ron Bonica) 10 min RSVP for Mesh (Kalmanek/Li) 5 min | subject to time RSVP for OAPS (Dan Guo) 5 min | availability ------------------------------- CCAMP WG documents (Joint with MPLS) draft-ietf-mpls-generalized-cr-ldp-04.txt draft-ietf-mpls-generalized-rsvp-te-04.txt draft-ietf-mpls-generalized-signaling-05.txt draft-ietf-mpls-lmp-02.txt draft-ietf-ccamp-gmpls-architecture-00.txt draft-ietf-ccamp-gmpls-sonet-sdh-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 08:51:07 -0700 Message-ID: <3B618D8B.67A6408F@alcatel.be> Date: Fri, 27 Jul 2001 17:49:31 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG-NA MIME-Version: 1.0 To: Andre Fredette CC: Bala Rajagopalan , "'ccamp@ops.ietf.org'" Subject: Re: Optical Link Interface - Correction Content-Type: multipart/mixed; boundary="------------B6C820374E870FA8F34E3C3C" This is a multi-part message in MIME format. --------------B6C820374E870FA8F34E3C3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andre, If in the following statement: > 4. Fault Notification (By the way, I think the ChannelStatus > Message defined in LMP-WDM could replace the current ChannelFail > Message in LMP) You refer to the added value of the "Condition" field then i agree with your proposal. In order to re-inforce my previous statement i am strongly convinced that the proposed LMP (extended to WDM) approach is the best one. It allows to have a complete solution for the IP-based distributed control plane relying on 3 protocols (and not 4). My vote is clearly for LMP-WDM. Regards, Dimitri. Andre Fredette wrote: > > Bala, > > Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP debate, though I > do know that you think the OLI is important and you care that the solution > is a good one. I also agree (as I've stated before) that either LMP-WDM or > NTIP could be made to work. I just believe that having the group focus on > one protocol rather than two will have a better end result and aid in wider > deployment. > > I'd also be glad to work on streamlining LMP-WDM. > > As I see it, the basic requirements are the same for both LMP and OLI for > the following: > 1. Control Channel Maintenance (A.K.A. a light weight hello protocol). > 2. The ability to exchange information on links (link summary, perhaps with > a few different TLVs) > 3. Discovery/Test. (Note: The main purpose here is for two devices to agree > on ID's for each link so information exchange regarding the links is > possible. The only reasonable way it is possible to automate this, is to > send some type of test messages on the physical links). To do this, > you need to be able > to terminate the links. > 4. Fault Notification (By the way, I think the ChannelStatus Message > defined in LMP-WDM > could replace the current ChannelFail Message in LMP) > 5. Notification whether a link is in use (ChannelActive Message). > > Because of this we have proposed basing the OLI on LMP. > > If these features need streamlining for LMP-WDM, they probably also need > streamlining for LMP, so let's fix them once. > > If there are other LMP-WDM-specific procedures that need to be streamlined, > I'm all ears. > > The major difference I see is that LMP needs is the ability to manage link > bundles for the purpose of routing advertisements, but the OLI doesn't. In > the LMP-WDM case, I was expecting we'd usually have a single link bundle > (effectively ignoring this feature of LMP). > > Regarding the discovery portion of LMP (i.e., "link connectivity > verification"), from a protocol standpoint, it should work. It does > require that the PXC be able to terminate each port with an appropriate > interface (from LMP: "For the LMP Test procedure, the free (unallocated) > data-bearing links MUST be opaque (i.e., able to be terminated)"). The PXC > would need to support termination of the various types of ports that could > be used (e.g., SONET, SDH). But, this is more of a hardware requirement > than a protocol requirement. > > Andre > > At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote: > > >Forgot to attach the new NTIP draft. > >Also, I meant "working on (4)", not (3). > > > > > >Bala Rajagopalan > >Tellium, Inc. > >2 Crescent Place > >P.O. Box 901 > >Oceanport, NJ 07757-0901 > >Tel: (732) 923-4237 > >Fax: (732) 923-9804 > >Email: braja@tellium.com > > > > > -----Original Message----- > > > From: Bala Rajagopalan > > > Sent: Friday, July 27, 2001 9:28 AM > > > To: 'Andre Fredette'; ccamp@ops.ietf.org > > > Subject: RE: Optical Link Interface > > > > > > > > > Andre: > > > > > > I believe you're counting me in the "agnostic" category. > > > I hope this is not taken as "don't care", since I > > > do have an interest in making a choice quickly. > > > > > > I have looked at the LMP-WDM draft (again) and the new > > > NTIP draft sent by Osama (attached). I see the following: > > > > > > 1. Both these solutions gloss over the details of > > > auto-discovery between OXCs and WDM. (Note: the > > > issues are the same regardless of the protocol used > > > and neither provides full details. Furthermore, > > > the hardware requirements and actions under both > > > are the same). > > > > > > 2. If we leave out (1), then the other functions are > > > based on messaging over the control channel > > > between the OXC and the WDM. This messaging > > > can be done one way or the other. > > > > > > 3. Both require control channel maintenance using > > > (simple) keepalive. > > > > > > 4. It seems LMP-WDM can be streamlined to make it > > > more lean and mean. > > > > > > Unless there is a significant technical issue > > > of one choice over the other, we have to consider > > > the fact that LMP-WDM has the first mover advantage. > > > Is it possible for > > > the NTIP proponents to seriously consider working on > > > (3)? Specifically, focus LMP-WDM on OLI requirements > > > only and not carry any unrelated LMP concepts into > > > LMP-WDM. Would this satisfy the design motivation for NTIP? > > > > > > Regards, > > > > > > Bala > > > > > > > > > Bala Rajagopalan > > > Tellium, Inc. > > > 2 Crescent Place > > > P.O. Box 901 > > > Oceanport, NJ 07757-0901 > > > Tel: (732) 923-4237 > > > Fax: (732) 923-9804 > > > Email: braja@tellium.com > > > > > > > -----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. > > > > > > > > > > > --------------B6C820374E870FA8F34E3C3C Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NSG - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------B6C820374E870FA8F34E3C3C-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 08:27:56 -0700 Message-ID: <007e01c116af$84ccb2a0$21eb883e@movaz.com> From: "Adrian Farrel" To: Subject: Re: Optical Link Interface Date: Fri, 27 Jul 2001 11:11:57 -0400 Just a brief $0.02 (perhaps only $0.015). >From an implementation point of view it seems preferable to extend a protocol that one might already have implemented thereby re-using code and reaching stability more quickly. >From a standardization point of view there seems no sense in having two protocols that can provide the same function. We should be looking towards ease of interoperation - why shouldn't the OLI be an interface between components manufactured by different OEMs? To say that LMP-WDM as an extension of LMP is of no help because you don't necessarily have LMP only puts LMP-WDM on the same footing as NTIP, not behind it. It seems to me that issues of function level in the two protocols are a diversion since it is well within the capabilities of all concerned to enhance either protocol to provide the function required. So it should be possible to make LMP-WDM or NTIP satisfy the OLI requirements. This leaves us with Kireeti's list which I paraphrase as 1. One protocol or two? 1a. IETF should (will!) only allow one of LMP-WDM and NTIP to go forward, as Kireeti has said. 1b. People implementing LMP will surely prefer LMP-WDM. 2. Peer or master-slave relationship. Of some interest, but it is always possible to make a peer-based protocol behave in a master-slave way and vice versa. 3. Underlying transport. Does a protocol's dependency on certain characteristics of the underlying transport constrain the implementation and introduce issues? My vote is for LMP-WDM (but I am an author). I sympathize with the inventors of NTIP and urge them to bring what they have learned to the LMP-WDM draft to make the finished protocol even more successful. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 08:27:51 -0700 Message-ID: <007d01c116af$832e9300$21eb883e@movaz.com> From: "Adrian Farrel" To: "manoj juneja" Cc: Subject: Re: Explicit Label Control Date: Fri, 27 Jul 2001 10:51:55 -0400 Manoj, Your reading of the drafts is correct, explicit label control is intended to allow an ERO to include labels for any hop as well as an ultimate label for egress control. That O-UNI (currently?) only uses ERO labels for egress control is fine. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "manoj juneja" To: Sent: Thursday, July 26, 2001 3:15 PM Subject: Explicit Label Control > Hi All, > > In GMPLS and O-UNI drafts, the concept of Egress/explicit Label control is > described. Is this valid only at egress or intermediate nodes also ? I have > gone through both the GMPLS and O-UNI drafts. The O-UNI draft clearly > describes it as Egress Label i.e. label to be used at destination UNI. But > GMPLS describes the term Explicit Label object. The GMPLS draft mentions > that the explicit label subobject can be present anywhere (as per my > understanding) in ERO provided that this sub-object should follow a > subobject containing the IP address or interface identifier (strict object). > I mean to say whether the Explicit Label object will only be at the > end of ERO or it can appear in between in case of GMPLS ? > > Please clarify. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 08:08:20 -0700 From: Andre Fredette To: Bala Rajagopalan Cc: "'ccamp@ops.ietf.org'" Message-Id: <5.1.0.14.2.20010727101544.02e1cbd0@mailbox> Date: Fri, 27 Jul 2001 11:01:37 -0400 Subject: RE: Optical Link Interface - Correction Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Bala, Yes, I counted you as "agnostic" in the LMP-WDM vs. NTIP debate, though I do know that you think the OLI is important and you care that the solution is a good one. I also agree (as I've stated before) that either LMP-WDM or NTIP could be made to work. I just believe that having the group focus on one protocol rather than two will have a better end result and aid in wider deployment. I'd also be glad to work on streamlining LMP-WDM. As I see it, the basic requirements are the same for both LMP and OLI for the following: 1. Control Channel Maintenance (A.K.A. a light weight hello protocol). 2. The ability to exchange information on links (link summary, perhaps with a few different TLVs) 3. Discovery/Test. (Note: The main purpose here is for two devices to agree on ID's for each link so information exchange regarding the links is possible. The only reasonable way it is possible to automate this, is to send some type of test messages on the physical links). To do this, you need to be able to terminate the links. 4. Fault Notification (By the way, I think the ChannelStatus Message defined in LMP-WDM could replace the current ChannelFail Message in LMP) 5. Notification whether a link is in use (ChannelActive Message). Because of this we have proposed basing the OLI on LMP. If these features need streamlining for LMP-WDM, they probably also need streamlining for LMP, so let's fix them once. If there are other LMP-WDM-specific procedures that need to be streamlined, I'm all ears. The major difference I see is that LMP needs is the ability to manage link bundles for the purpose of routing advertisements, but the OLI doesn't. In the LMP-WDM case, I was expecting we'd usually have a single link bundle (effectively ignoring this feature of LMP). Regarding the discovery portion of LMP (i.e., "link connectivity verification"), from a protocol standpoint, it should work. It does require that the PXC be able to terminate each port with an appropriate interface (from LMP: "For the LMP Test procedure, the free (unallocated) data-bearing links MUST be opaque (i.e., able to be terminated)"). The PXC would need to support termination of the various types of ports that could be used (e.g., SONET, SDH). But, this is more of a hardware requirement than a protocol requirement. Andre At 09:36 AM 7/27/2001 -0400, Bala Rajagopalan wrote: >Forgot to attach the new NTIP draft. >Also, I meant "working on (4)", not (3). > > >Bala Rajagopalan >Tellium, Inc. >2 Crescent Place >P.O. Box 901 >Oceanport, NJ 07757-0901 >Tel: (732) 923-4237 >Fax: (732) 923-9804 >Email: braja@tellium.com > > > -----Original Message----- > > From: Bala Rajagopalan > > Sent: Friday, July 27, 2001 9:28 AM > > To: 'Andre Fredette'; ccamp@ops.ietf.org > > Subject: RE: Optical Link Interface > > > > > > Andre: > > > > I believe you're counting me in the "agnostic" category. > > I hope this is not taken as "don't care", since I > > do have an interest in making a choice quickly. > > > > I have looked at the LMP-WDM draft (again) and the new > > NTIP draft sent by Osama (attached). I see the following: > > > > 1. Both these solutions gloss over the details of > > auto-discovery between OXCs and WDM. (Note: the > > issues are the same regardless of the protocol used > > and neither provides full details. Furthermore, > > the hardware requirements and actions under both > > are the same). > > > > 2. If we leave out (1), then the other functions are > > based on messaging over the control channel > > between the OXC and the WDM. This messaging > > can be done one way or the other. > > > > 3. Both require control channel maintenance using > > (simple) keepalive. > > > > 4. It seems LMP-WDM can be streamlined to make it > > more lean and mean. > > > > Unless there is a significant technical issue > > of one choice over the other, we have to consider > > the fact that LMP-WDM has the first mover advantage. > > Is it possible for > > the NTIP proponents to seriously consider working on > > (3)? Specifically, focus LMP-WDM on OLI requirements > > only and not carry any unrelated LMP concepts into > > LMP-WDM. Would this satisfy the design motivation for NTIP? > > > > Regards, > > > > Bala > > > > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com > > > > > -----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: Fri, 27 Jul 2001 08:03:25 -0700 Message-ID: <3B61813D.FD7639BD@sandburst.com> Date: Fri, 27 Jul 2001 10:57:01 -0400 From: Eric Gray 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, Just to nag on a bit, weren't these supposed to be in CCAMP? Why did they not get submitted as draft-ietf-ccamp-generalized-signaling-00.txt draft-ietf-ccamp-generalized-rsvp-te-00.txt draft-ietf-ccamp-generalized-cr-ldp-00.txt You wrote: > FYI - > > New versions of the GMPLS signaling drafts have been submitted. We > attempted to cover the major last call issues. For those who don't want to > wait, the drafts are available at: > > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 07:41:12 -0700 Message-ID: <3B617C1A.ABE672CD@acm.org> Date: Fri, 27 Jul 2001 10:35:06 -0400 From: Matt Squire Reply-To: mattsquire@acm.org MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Optical Link Interface Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You can bump the LMP-WDM count up to 9. I just don't see any techical advantages to NTIP and the implementation path (based on the assumption that many folks will implement LMP) is easier with the LMP-WDM solution. And to echo everyone else's sentiment: Two protocols be bad. Andre Fredette wrote: > > From my count on the mailing list we have the following results so far: > > LMP-WDM: 8 > NTIP: 3 (All from Nortel) > Agnostic: 1 > > And then there are the other 16 co-authors of LMP-WDM who haven't posted > (perhaps because they don't think they have any new points to add). > > Andre > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 06:36:47 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040401982425@mail1.tellium.com> From: Bala Rajagopalan To: "'Andre Fredette'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface - Correction Date: Fri, 27 Jul 2001 09:36:10 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C116A1.18EB861E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C116A1.18EB861E Content-Type: text/plain; charset="iso-8859-1" Forgot to attach the new NTIP draft. Also, I meant "working on (4)", not (3). Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Bala Rajagopalan > Sent: Friday, July 27, 2001 9:28 AM > To: 'Andre Fredette'; ccamp@ops.ietf.org > Subject: RE: Optical Link Interface > > > Andre: > > I believe you're counting me in the "agnostic" category. > I hope this is not taken as "don't care", since I > do have an interest in making a choice quickly. > > I have looked at the LMP-WDM draft (again) and the new > NTIP draft sent by Osama (attached). I see the following: > > 1. Both these solutions gloss over the details of > auto-discovery between OXCs and WDM. (Note: the > issues are the same regardless of the protocol used > and neither provides full details. Furthermore, > the hardware requirements and actions under both > are the same). > > 2. If we leave out (1), then the other functions are > based on messaging over the control channel > between the OXC and the WDM. This messaging > can be done one way or the other. > > 3. Both require control channel maintenance using > (simple) keepalive. > > 4. It seems LMP-WDM can be streamlined to make it > more lean and mean. > > Unless there is a significant technical issue > of one choice over the other, we have to consider > the fact that LMP-WDM has the first mover advantage. > Is it possible for > the NTIP proponents to seriously consider working on > (3)? Specifically, focus LMP-WDM on OLI requirements > only and not carry any unrelated LMP concepts into > LMP-WDM. Would this satisfy the design motivation for NTIP? > > Regards, > > Bala > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----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_000_01C116A1.18EB861E Content-Type: text/plain; name="draft-sahay-ccamp-ntip-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-sahay-ccamp-ntip-01.txt" CCAMP WG V. Sahay = B. Narayanan = Internet Draft R. Ramaswami = Document: draft-sahay-ccamp-ntip-01.txt O. Aboul-Magd = B. Jamoussi = Nortel Networks = = R. Jain = S. Dharanikota = Nayna Networks = = R. Hartani = Caspian Networks = = July 2001 = =20 =20 Network Transport Interface Protocol (NTIP) for Photonic =20 Cross Connects (PXC)=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 1. Abstract=20 =20 This draft describes the transport network interface protocol (NTIP) = for photonic cross connects (PXC). NTIP is implemented between a PXC = and transport network element (TNEs), also known as line systems.=20 NTIP is a protocol that uses TCP/IP for the transport of information = related to defect notification, trace monitoring, adjacency=20 discovery, and diagnostic messages between directly attached PXC and = TNE. The use of TCP as the transport protocol ensures reliable and=20 in-sequence delivery of NTIP messages.=20 =20 2. Conventions used in this document=20 =20 =20 Sahay Expires January 2002 1=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 =20 =20 3. Introduction=20 =20 Fast restoration of failed light paths is critical for PXCs and it=20 requires support for fast and accurate failure detection. Most PXCs=20 do not look into the optical signals that flow through them. Some=20 can detect presence or loss of light on a port. However presence of=20 light does not necessarily mean that the light path is fine. For=20 example when a link fails, generators between the point of failure=20 and the PXC may inject an alarm indication signal (AIS) on a light=20 signal. Unless the PXC decodes the framing of the light signal=20 (possibly using some electrical circuitry), AIS will appear as=20 presence of light. Also, some of the DWDM equipment (also called=20 Transport Network Elements in this document) can control the=20 switching ON and OFF of the AIS by configuration (or on demand). = This=20 feature can be leveraged to the advantage of the faster fault=20 detection and hence the recovery times.=20 =20 Unlike the PXC, the transport network elements (TNE) attached to it=20 are aware of their equipment failure as well as the quality and=20 framing of the light paths passing through them. Failure information = can be dynamically conveyed from the TNE to the PXC using out of=20 band IP messaging.=20 =20 The transport network interface protocol (NTIP) defines the set of=20 messages and the transport mechanism used for the exchange of=20 failure conditions. NTIP is implemented between the PXC and the TNE. = NTIP is an IP message handshake transported over an IP network. The=20 implementation of NTIP between TNE and PXC achieves the following=20 goals:=20 =20 - Defect Notification: NTIP is used by the TNE to relay failure=20 conditions and precise link, fiber, and equipment status=20 notification to PXC. Defect reporting can be both event-driven=20 (e.g., link failures), polling-driven (e.g., regular link sanity=20 checks) or time-driven (e.g., periodic).=20 =20 - Trace Monitoring: A PXC can use NTIP to request a TNE to monitor a = certain pattern in the overhead of a light path. This capability=20 could be used by PXC for validating light path identity.=20 =20 - Diagnostics: NTIP could be used by OXC to request a TNE to perform = diagnostics on any port or channel.=20 =20 - Adjacency Discovery: NTIP could be used by both PXC and TNE to=20 send and receive in band signals for automatic discovery of their=20 optical connectivity.=20 =20 =20 Sahay Expires January 2002 2=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 This draft describes NTIP procedures and messages to achieve its=20 design goals.=20 =20 4. Reference Model=20 =20 The current generation of PXCs will interoperate with opaque line=20 systems such as SONET regenerators, wavelength translators, etc.=20 Eventually when enough transparent line systems are deployed, PXCs=20 will interwork with them leading to an all optical network (AON).=20 The need for NTIP exists in both cases. The following reference=20 model focuses on interoperation of PXCs with opaque line systems.=20 =20 A reference model is shown in Figure 1. TNE are used to connect PXC=20 ports to the transport system. TNE could be a set of OEO devices=20 followed by a DWDM mux as shown in Figure 1. A TNE regenerates the=20 signal coming from the PXC and might be capable of translating the=20 wavelength. The key features of a TNE in the reference model are its = ability to detect defects on its ports and to communicate defect=20 information back to the PXC using NTIP.=20 =20 Drop Line=20 Side side=20 | |=20 | |=20 +---------+| TNE | |\ /| TNE +---------+=20 | +---|V +---+V | \ / | +---+ |---+ |=20 | |Por|->| |->| \ / |<-| |<-|Por| |=20 | | t| |---| | \ / | |---| | t| |=20 | | |<-| |<-| \ / |->| |->| | | =20 | +---| +---+ | \=3D=3D=3D=3D=3D>/ | +---+ |---+ = |=20 | | | /<=3D=3D=3D=3D=3D\ | | = PXC |=20 | PXC +---| +---+ | / \ | +---+ |---+ |=20 | |Por|->| |->| / \ |<-| |<-|Por| |=20 | | t| |---| | / \ | |---| | t| |=20 | | |<-| |<-| / DWDM MUX \ |->| |->| | |=20 | +---| +---+ |/ \| +---+ |---+ |=20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D|=20 |controlle| +=3D=3D=3D+ +=3D=3D=3D+ = |controlle|=20 | r |<>| | | |<>| r |=20 +---------+^ +=3D=3D=3D+ +=3D=3D=3D+ = ^+---------+=20 | TNE TNE |=20 | controller controller |=20 NTIP NTIP=20 =20 PXC =3D Photonic CrossConnect TNE =3D Transport Network = Element=20 TX =3D Transmit RX =3D Receive=20 =20 FIGURE 1: PXC to TNE Reference Configuration=20 =20 Each PXC port consists of two unidirectional fibers, one for input=20 (RX) and one for output (TX). Four TNE ports are associated with=20 each PXC port (RX and TX). The TNE port that is connected to PXC is=20 referred to as drop-side port, and the one that is connected to the=20 =20 Sahay Expires January 2002 3=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 line is called the line-side port. Figure 1 shows that a PXC will=20 communicate with several TNEs. On the other hand, a TNE only=20 communicates with a single PXC.=20 =20 A TNE can detect failures on signals it receives. Additionally some=20 TNEs may be able to detect certain failures on their output ports=20 such as laser failure. =20 =20 5. NTIP Overview=20 =20 5.1 Configuration=20 =20 Whenever automatic discovery is not available, a PXC is provisioned=20 with information on how its ports are connected to TNE. It is also=20 provisioned with the primary and the secondary IP addresses of each=20 TNE connected to it.=20 =20 NTIP defines a set of configurable parameters such as protocol=20 timers, retry counts, etc. Those parameters could be assigned=20 default values or allowed to be set as needed or negotiated.=20 =20 5.2 Registration=20 =20 As a TNE starts up, it registers with the PXC whose address is=20 configured in it. A TNE registers by opening a TCP session with the=20 PXC, and sending a registration request message. TNE registration=20 allows PXC to create its internal context structure for this=20 particular TNE.=20 =20 5.3 Keep Alive=20 =20 NTIP utilizes keep alive messages. Keep alive messages are exchanged = periodically between TNE and PXC to verify the sanity of the=20 connection. The keep alive message interval is a configurable=20 parameter.=20 =20 5.4 Automatic Discovery=20 =20 A PXC might have hundreds or even thousands of ports. Manual entries = of port adjacency between PXC and TNEs connected to it is tedious=20 and error prone. Furthermore manual entry has to be repeated every=20 time there is change in adjacency due to, for instance, re-cabling.=20 =20 One application of the NTIP interface is for use in automatic=20 adjacency discovery between PXC and TNEs. For that purpose it is=20 assumed that the TNE is aware of its ports mapping, i.e. the mapping = between its drop side TX and RX ports, and its line side ports. This = mapping is mad available using NTIP to the auto discovery process=20 (ADP). =20 =20 The TNE drop side port is supposed to operate in one of two modes,=20 Pass-through and Insert. In the Insert mode the drop side TX inserts = an identity pattern into the signal overhead, e.g. J0. The PXC is=20 =20 Sahay Expires January 2002 4=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 made aware of the TNE port identity patterns over the NTIP interface = using a MappingTable message. In the Pass-through mode, the TNE drop = side TX passes the signal without modification.=20 =20 The auto discovery process starts with the PXC port establishing a=20 cross connect to a well-known Test RX as shown in Figure 2. The PXC=20 then sends a ModeSwitch message to the TNE to switch the TNE drop=20 side TX mode to the Insert mode. The TNE starts inserting its=20 identity pattern (could be a system wide unique id or a trail trace=20 id). =20 =20 +-------------+ +----+----+=20 | |---->| RX | TX |--->=20 | | +----+----+=20 | PXC |=20 | | +----+----+=20 | |<----| TX | RX |<---=20 | | +----+----+=20 +-------------+=20 | ^ <-- NTIP-->=20 | |=20 V |=20 +---+ +---+=20 | | | |=20 +---+ +---+=20 =20 Test Test=20 RX TX=20 =20 Figure 2: Auto Discovery Configuration=20 =20 The Test RX is requested to report the Identity message it sees. The = ADP maps the identity message to the drop side TX port id and the=20 PXC port id. To verify mapping, the Test TX is requested to send the = same identity pattern to the TNE drop side RX over NTIP using the=20 discovered PXC port. The TNE drop side RX verify the received=20 identity pattern and reports match pr mismatch.=20 =20 The Test TX/RX could be internal or external to the PXC. In the case = of external Test TX/RX, communication would be done over NTIP=20 interface.=20 =20 The procedure for auto-discovery is also applicable for link=20 verification.=20 =20 5.5 Defect Monitoring=20 =20 Defect monitoring is initiated by the PXC by telling the TNE which=20 ports to monitor for defects (signal degradation, loss of light,=20 etc.). Defect monitoring will be initiated by the PXC after setting=20 a light path through a TNE port. PXC terminates defect monitoring on = a port before it disconnects the light path on that port.=20 =20 =20 Sahay Expires January 2002 5=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 5.6 Trace Monitoring=20 =20 Trace monitoring ensures that a light path is connected to the=20 correct client. A trace (light path Id) is injected by the client in = the light path. After setting up a light path, PXC will request TNE=20 to match the supplied trace id with that in the light path. The TNE=20 informs the PXC in case of a mismatch. =20 =20 Trace Id is a pattern that can be injected and monitored in a light=20 path without affecting its payload. A few different alternative ways = of implementing it are possible. Trace Id may be injected in wrapper = or as a pilot tone. NTIP supports all of them.=20 =20 The PXC discontinue the trace monitoring process for a particular=20 light path before deleting it.=20 =20 5.7 Status Request/Response=20 =20 Status request is initiated by the PXC and is triggered by an NTIP=20 user application, e.g. NMS. Status response contains the status of=20 the requested to TNE ports. It is sent by the TNE in response to=20 status request.=20 =20 5.8 Batching of Messages=20 =20 To reduce message traffic, TNE can pack several defect notification=20 messages into a single message. Latency could be experienced as a=20 result of batching since TNE has to hold off sending defects for an=20 amount of time necessary to collect enough defects.=20 =20 5.9 Resynchronization=20 =20 Resynchronization is needed every time an NTIP session restarts. An=20 NTIP session could restart due to TCP connection failure, PXC=20 restart due to internal reasons, e.g. control plan restart or PXC=20 restart, TNE restart, or as a result of a deletion of the NTIP=20 session due to time out.=20 =20 Each TNE keeps track of its NTIP session. If the session is deleted, = it attempts to create another session over TCP/IP periodically. The=20 time it waits before initiating a second attempt is a configurable=20 parameter.=20 =20 Once TNE succeeds in creating a TCP connection with PXC, it repeats=20 the registration procedure as mentioned in section 5.2. Upon=20 receiving the registration request, the PXC goes into a=20 resynchronization phase requesting an update on the port status of=20 all TNE ports that it is interested in. The PXC confirms the end of=20 the synchronization phase to the TNE when it receives the status of=20 all the requested ports.=20 =20 Resynchronization helps the reporting of failure events that would=20 have been missed by the PXC due to the NTIP session being down. It=20 =20 Sahay Expires January 2002 6=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 also allows the TNE not to remember the defects monitoring commands=20 given before resynchronization.=20 =20 5.10 TNE to PXC Transport=20 =20 A single high availability router/switch is recommended for=20 connecting TNE to PXC. This transport arrangement is referred to as=20 NTIP transport network. TNE defect messages are required to reach=20 the PXC with little delays. It is recommended that the NTIP network=20 supports the priority handling of packets, e.g. differentiated=20 services. Messages related to defect reporting are transported with=20 high priority. All other messages, that are not time critical, are=20 transported using a lower priority.=20 =20 NTIP messages are transported reliably using TCP as the transport=20 protocol. The use of TCP also ensures in-sequence delivery of NTIP=20 messages, hence relieving the protocol developer from creating an=20 additional layer for reliable delivery.=20 =20 Figure 3 shows the logical connectivity between PXC and TNE.=20 =20 +-----+ +-----+=20 | | +--------------+ +----+ |=20 | | | |-------+----+ |--+=20 | PXC |---| IP Network |-------| |-+=20 | | | | +----+=20 | | +-------------+ TNEs=20 +-----+ =20 |<---------------------------->|=20 TCP Session =20 =20 FIGURE 3: PXC-TNE Logical Connectivity=20 =20 Figure 3 emphasizes the fact that a PXC communicates with several=20 TNEs while a TNE only communicates with a single PXC.=20 =20 5.11 Defect Types=20 =20 A TNE will report the following defects to PXC. =20 =20 - Signal Degrade (SD): TNE reports this type of failure when the=20 light signal on one of its ports degrades below a configured=20 threshold.=20 =20 - Signal Fails (SF): TNE reports SF to PXC when the incoming signal=20 fails on one of its ports.=20 =20 - AIS: TNE reports AIS to PXC when it detects AIS-LINE on one of its = ports.=20 =20 - Trace Mismatch: TNE reports Trace Mismatch when it mismatch is=20 detected by one of its ports between an injected pattern and the=20 expected pattern.=20 =20 Sahay Expires January 2002 7=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 =20 - Equipment Failure: TNE will notify PXC of equipment failure (e.g.=20 OEO card or laser failure on the transport side) and the port=20 number that suffered the failure.=20 =20 6.0 NTIP and OLI Requirements=20 =20 The requirements for the interface between PXC and the line system,=20 denoted as OLI (Optical Link Interface), have been discusses in [3]. = Most of those requirements have been taken from the earlier version=20 of this draft that was presented back in March during the IETF 50=20 meeting. In this section we discuss how far NTIP satisfies those=20 requirements.=20 =20 6.1 General OLI Characteristics=20 =20 General OLI requirements are reliabile, secure, and simple. NTIP=20 meets the reliability and security requirements by employing TCP as=20 its transport mechanism. TCP provide reliable and orderly=20 transmission of NTIP messages. Furthermore it provides a flow=20 control mechanism that allows for bulk transmission of NTIP=20 messages. The TCP window mechanism paces messages for cases where=20 the traffic volume increase for instance due to, for instance, re- synchronization.=20 =20 Line systems (TNEs) do not usually have much memory, and can only=20 keep a limited amount of state. NTIP achieves simplicity by=20 establishing a master-slave, as opposed to peer, relationship=20 between the PXC and TNEs. This minimizes the amount of states kept=20 at the TNE and makes efficient used of the limited memory available. = =20 6.2 OLI Functionality=20 =20 OLI basic functionality as defined in [3] are: neighbor discovery,=20 control channel maintenance, re-synchronization, connectivity=20 discovery, fault management, and link property information.=20 =20 Neighbor discovery and control channel maintenance are achieved in=20 NTIP by means of a simple registration and keep alive procedures. =20 =20 Connectivity discovery has been discussed in section 5.4. It allows=20 for the automatic discovery and mapping between PXC ports and TNE=20 ports.=20 =20 Fault management and re-synchronization have always been the main=20 focus of NTIP as discussed in a previous revision of this draft.=20 Fault management includes fault notification and trace monitoring,=20 both have originally been introduced in a previous revision of this=20 draft. NTIP introduced the notion of priority handing of fault=20 notification messages to expedite light path recovery and=20 restoration in the order of few tens ms.=20 =20 =20 Sahay Expires January 2002 8=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 Trace monitoring has ingeniously been introduced by NTIP and has=20 been adopted as one of the main requirements of OLI. =20 =20 Most of the link property information, e.g. SRLG and span length can = be configured. If necessary they can be added to NTIP with minor=20 modifications.=20 =20 7.0 NTIP Messages and Procedures=20 =20 All NTIP messages start with the following two fields:=20 =20 NTIP Vers: =20 2-byte field that contains the NTIP protocol version number.=20 =20 Type:=20 2-byte field that contains the message type=20 =20 The version number provides the features supported by the other side = of the NTIP communication. It is only verified at the establishment=20 of NTIP session, and is used during registration and=20 resynchronization states. =20 =20 7.1 Registration Message=20 =20 The format of the Registration Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = + + = | | = + TNE Model Number + = | | = + + = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Type:=20 Type =3D REG-REQ =20 =20 TNE Model Number:=20 16-byte filed that specifies the TNE model number=20 =20 Procedure:=20 Registration Message is sent by the TNE to the PXC at start up. If = a PXC receives a Registration Message with a different NTIP Vers=20 than expected it may take one of the following actions:=20 =20 - Reject the registration request=20 =20 =20 Sahay Expires January 2002 9=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 - Reject the registration request if the received NTIP Vers = differs=20 by more than an allowed difference. If the difference is=20 acceptable, then the message set common to the two versions will = be supported.=20 =20 7.2 Registration Complete Message=20 =20 The format of the Registration Complete Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Type:=20 Type =3D REG-COMPLETE =20 =20 Procedure:=20 The Registration Complete Message is sent by PXC to TNE indicating = a successful completion of the registration. The message is sent=20 only during the initial synchronization phase.=20 =20 7.3 KeepAlive Message=20 =20 The format of the KeepAlive Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Type: =20 Type =3D KEEP-ALIVE-REQ =20 =20 Procedure:=20 The KeepAlive Message is sent by the TNE to PXC every T-keep-alive- interval seconds (the default is 60 seconds). If PXC does not = receive=20 a KeepAlive Message every T-keep-alive-timeout (t-keep-alive-timeout = =3D 3*T-keep-alive-interval), it takes down the NTIP session.=20 =20 7.4 KeepAlive Response Message=20 =20 The format of the KeepAlive Response Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Type:=20 =20 Sahay Expires January 2002 10=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 Type =3D KEEP-ALIVE_RES=20 =20 Procedure:=20 The KeepAlive Response Message is sent by PXC to TNE in response = to=20 a KeepAlive Message.=20 =20 7.5 Monitor Request Message=20 =20 The format of the Monitor Request Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Length | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | No. of Ports | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |AR |DM | TType |MT | Tr Len | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ Trace ID ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |AR |DM | TType |MT | Tr Len | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ Trace ID ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 =20 =20 Type:=20 Type =3D MON-REQ =20 =20 No. of Ports: =20 2-byte field that contains the number of ports reported in this=20 message.=20 =20 Port Address:=20 4-byte field that is formatted as:=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Sahay Expires January 2002 11=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 | shelf | slot | Sub Slot | port | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 =20 Alarm Reporting, AR:=20 2-bit field that indicates start, stop, or no change to alarm=20 reporting.=20 =20 Defect Monitoring, DM:=20 2-bit field that indicates start, stop, or no change to failure=20 monitoring.=20 =20 Trace Type, TType:=20 4-bit used to indicate the trace type. Possible types are, pilot=20 tone, wrapper, J0 bytes.=20 =20 Monitor of Trace, MT:=20 2-bit field that indicates start, stop, or no change to trace=20 monitoring=20 =20 Trace Length, Tr Len:=20 6-bit field that indicates the length of the monitored trace.=20 =20 Trace ID:=20 Up to 63 bytes. It defines the trace to be monitored. User could=20 treat the Trace ID as ASCII or binary=20 =20 Procedure:=20 The Monitor Request Message is sent by PXC to TNE. After setting a = light path through TNE, PXC will send Monitor Request Message=20 indicating the start of defect monitoring and the list of = monitored=20 ports. Before disconnecting a light path, PXC sends Monitor = Request=20 Message with DM set to stop indicating the end of the defect=20 monitoring process.=20 =20 The Monitor Request Message is also used for the start and the = stop=20 of alarm reporting and trace monitoring. Upon the start of trace=20 monitoring, the PXC supplies the Trace ID to be compared to that = in=20 the light path (say, in SONET J0 bytes, or in wrapper, or pilot=20 tone). Trace ID is not included in the Monitor Request Message = when=20 MT is set to stop or no change.=20 =20 7.6 Defect Notification=20 =20 The format for the Defect Notification Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Length | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Sahay Expires January 2002 12=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 | No. of Ports | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | FS | FT | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | FS | FT | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 =20 Type: =20 Type =3D DEFECT-NOTIFICATION =20 =20 Failure Status, FS:=20 2-bit field that indicates fail or clear.=20 =20 Failure Type, FT:=20 1-byte filed that indicates the failure (defect) type as discussed = in section 5.10.=20 =20 Procedure:=20 The Defect Notification Message is sent by the TNE in response to = a=20 PXC Monitor Request Message. The Defect Notification Message is=20 sent with the highest possible priority to reach the destination=20 PXC in a timely fashion.=20 =20 7.7 Status Request Message=20 =20 The format of the Status Request Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Length | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | No. of Ports | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Tag | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Sahay Expires January 2002 13=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Tag | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 =20 Type:=20 Type =3D STATUS-REQ =20 =20 Tag:=20 A 4-bit field that is used for message identification=20 =20 Procedure:=20 The Status Request Message is sent by PXC to TNE to solicit the=20 status of some or all of the TNE ports. Status Request Message=20 could also be sent to query the status of a previously issued=20 Monitor Request Message.=20 =20 7.8 Status Response Message=20 =20 The format of the Status Response Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Length | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | No. of Ports | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Tag | CStat | Dyn Stat | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Tag | CStat | Dyn Stat | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 =20 Type:=20 Type =3D STATUS-RESP =20 =20 Configuration Status, CStat:=20 4-bit field that indicates the provisioned state of a TNE port. It = indicates whether the port is enabled or disabled.=20 =20 Dynamic State, Dyn Stat:=20 =20 Sahay Expires January 2002 14=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 1-byte field that indicates the failure type experience by a TNE=20 port.=20 =20 Procedure:=20 The Status Response Message is sent from TNE to PXC. A TNE sends a = Status Response Message in response to a Status Request Message.=20 For each port requested, the Status Response Message includes a=20 configuration status (enabled or disabled), and a dynamic port=20 defect status that specify the failure type as discussed in=20 section 5.10.=20 =20 7.9 Configuration Update=20 =20 The format of the Configuration Update Message is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | NTIP Vers | Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Length | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | No. of Ports | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | CStat | Dyn Stat | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = ~ ~ = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Port Address | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | CStat | Dyn Stat | Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Type: =20 Type =3D CONFIG-UPDATE =20 =20 Procedure:=20 The Configuration Update Message is sent unsolicited by TNE to=20 PXC. It is used for dynamically modifying the configuration while=20 in operation. =20 =20 8. Security Considerations=20 =20 This draft does not introduce any new security issues.=20 =20 =20 9. References=20 =20 =20 Sahay Expires January 2002 15=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996.=20 =20 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997=20 =20 3 A. Fredette, Editor, =93 Optical Link Interface Requirements=94,=20 draft-many-oli-reqts-00.txt, work in progress, June 2001=20 =20 =20 =20 =20 =20 =20 10. Author's Addresses=20 =20 Vasant Sahay=20 Nortel Networks=20 2305 Mission College Blvd=20 Santa Clara, CA 95054, USA=20 Phone: 408-565-4601=20 E.mail: vasants@nortelnetworks.com=20 =20 Rajiv Ramaswami=20 Nortel Networks=20 2305 Mission College Blvd=20 Santa Clara, CA 95054, USA=20 Phone: 408-565-4621=20 Email: rajiv@nortelnetworks.com=20 =20 Babu Narayanan=20 Nortel Networks=20 2305 Mission College Blvd=20 Santa Clara, CA 95054, USA=20 Phone: 408-565-4537=20 Email: bon@nortelnetworks.com=20 =20 =20 Osama S. Aboul-Magd=20 Nortel Networks=20 P.O. Box 3511, Station C=20 Ottawa, Ontario, Canada=20 K1Y 4H7=20 Phone: 613-763-5827=20 Email: osama@nortelnetworks.com=20 =20 Bilel Jamoussi=20 Nortel Networks=20 600 Technology Park Drive=20 Billerica, MA 01821, USA=20 Phone: 978-288-4506=20 Email: jamoussi@nortelnetworks.com=20 =20 Sahay Expires January 2002 16=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 =20 Raj Jain=20 Nayna Networks, Inc.=20 157 Topaz St=20 Milpitas, CA 95035, USA=20 Phone: 408-956-8000 Ext 309=20 Email: raj@nayna.com=20 =20 Sudheer Dharanikota=20 Nayna Networks, Inc.=20 157 Topaz St=20 Milpitas, CA 95035, USA=20 Phone: 408-956-8000 Ext 357=20 Email: Sudheer@nayna.com=20 =20 Riad Hartani=20 Caspian Networks=20 170 Bytech Drive=20 San Jose, CA 95134, USA=20 Phone: 408-382-5216=20 Email: riad@caspiannetworks.com=20 =20 =20 =20 =20 Sahay Expires January 2002 17=20 =0C Draft-sahay-ccamp-ntip-01.txt July 2001=20 =20 =20 =20 Full Copyright Statement=20 =20 "Copyright (C) The Internet Society (date). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it = or assist in its implmentation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into=20 =20 Sahay Expires January 2002 18=20 =0C ------_=_NextPart_000_01C116A1.18EB861E-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jul 2001 06:28:40 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040401982424@mail1.tellium.com> From: Bala Rajagopalan To: "'Andre Fredette'" , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Fri, 27 Jul 2001 09:27:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Andre: I believe you're counting me in the "agnostic" category. I hope this is not taken as "don't care", since I do have an interest in making a choice quickly. I have looked at the LMP-WDM draft (again) and the new NTIP draft sent by Osama (attached). I see the following: 1. Both these solutions gloss over the details of auto-discovery between OXCs and WDM. (Note: the issues are the same regardless of the protocol used and neither provides full details. Furthermore, the hardware requirements and actions under both are the same). 2. If we leave out (1), then the other functions are based on messaging over the control channel between the OXC and the WDM. This messaging can be done one way or the other. 3. Both require control channel maintenance using (simple) keepalive. 4. It seems LMP-WDM can be streamlined to make it more lean and mean. Unless there is a significant technical issue of one choice over the other, we have to consider the fact that LMP-WDM has the first mover advantage. Is it possible for the NTIP proponents to seriously consider working on (3)? Specifically, focus LMP-WDM on OLI requirements only and not carry any unrelated LMP concepts into LMP-WDM. Would this satisfy the design motivation for NTIP? Regards, Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----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: Fri, 27 Jul 2001 02:32:19 -0700 Message-ID: <114DE1AABD7DD41189B600508BAF1271028A9B47@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: "'Lou Berger'" Cc: "'ccamp@ops.ietf.org'" Subject: Re: new gmpls signaling drafts Date: Fri, 27 Jul 2001 11:18:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lou, You wrote: > New versions of the GMPLS signaling drafts have been submitted. We > attempted to cover the major last call issues. For those who don't want to wait, > the drafts are available at: > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt Would it be possible to somehow summarize the issues that were considered when writing these new drafts and how these issues have been dealt with? That would be very helpful. Thanks a lot. Leen Mak. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 14:02:21 -0700 Message-ID: <3B6084CD.6163029D@utfors.se> Date: Thu, 26 Jul 2001 22:59:57 +0200 From: Loa Andersson MIME-Version: 1.0 To: Martin Dubuc CC: Andre Fredette , ccamp@ops.ietf.org Subject: Re: Optical Link Interface Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit All, second (or maybe third) in motion. I think Andre's proposal has a very solid foundation. As I understand it even the people proposing NTIP, do so based on the argument that two protocols are better than one. Somestimes even quoting "(I)SP's" wanting this. Speaking as an operator I can't find any reason to complicate our network with two protocols (even though marginally different) that give me the same thing. For the very same reason that we won't deploy CR-LDP, we won't deploy a second optical link interface protocol. The only chance that we will deploy NTIP is that it will be the one and only pick by CCAMP, and I can't see that happen. Let's go for LMP-WDM and let's stop the standardization process for alternatives. /Loa Martin Dubuc wrote: > > I support your proposal. > > Martin > > -----Original Message----- > From: Andre Fredette [mailto:fredette@photonex.com] > Sent: Monday, July 23, 2001 10:01 PM > To: ccamp@ops.ietf.org > Subject: Optical Link Interface > > Last month, the "Optical Link Interface (OLI) Requirements" document > http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > was discussed on the ccamp mailing list and achieved "rough consensus" > according to our working group co-chairs. Given this, we'd like to make > some progress on the protocol specification. I'd like to generate some > discussion on this mailing list before the IETF meeting in London > because > meaningful technical discussion cannot occur in the time allocated > during > the meeting. > > There have been two proposals in the IETF to satisfy the OLI > requirements: > > 1. [LMP-WDM]: > "Link Management Protocol (LMP) for DWDM Optical Line Systems" > http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt > (note, this updated document was submitted Friday, so it should show up > on the official website soon). > > and > > 2. [NTIP]: > "Network Transport Interface Protocol (NTIP) for Photonic Cross > Connects" > (PXC) > http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt > > LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, > while > NTIP proposes a new protocol. We believe that the LMP approach is best > because: > > 1. [LMP-WDM] satisfies the OLI Requirements. > > 2. The extensions to LMP are quite natural and fit within the spirit of > the > LMP protocol. > > 3. LMP is a reasonably mature IETF protocol specification: > - It has been in the works for well over a year. > - It is an official working group document. > > 4. It is better to have one protocol, than two for a given function > (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) > > 5. Using the same protocol simplifies both implementation and management > on > devices, such as optical cross-connects and routers, that may need to > use > both simultaneously. > > While there is no doubt in my mind that NTIP could be made to satisfy > the > OLI requirements, It is my strong opinion that LMP should be the > solution > chosen by the CCAMP working group due to the reasons outlined above. > > Comments please! > > Regards, > Andre -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 12:18:22 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Explicit Label Control Date: Thu, 26 Jul 2001 12:15:15 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In GMPLS and O-UNI drafts, the concept of Egress/explicit Label control is described. Is this valid only at egress or intermediate nodes also ? I have gone through both the GMPLS and O-UNI drafts. The O-UNI draft clearly describes it as Egress Label i.e. label to be used at destination UNI. But GMPLS describes the term Explicit Label object. The GMPLS draft mentions that the explicit label subobject can be present anywhere (as per my understanding) in ERO provided that this sub-object should follow a subobject containing the IP address or interface identifier (strict object). I mean to say whether the Explicit Label object will only be at the end of ERO or it can appear in between in case of GMPLS ? Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:53:34 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010726143300.02c99a48@mailbox> Date: Thu, 26 Jul 2001 14:52:23 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Thu, 26 Jul 2001 11:48:35 -0700 Reply-To: From: "Vishal Sharma" To: "manoj juneja" , Subject: RE: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt Date: Thu, 26 Jul 2001 11:47:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, As stated in my previous email, please check the latest version of the OSPF routing enhancements draft (which should show up on the IETF drafts directory sometime this week, or early next week) titled draft-kompella-ospf-gmpls-extensions-02.txt This is the latest version of the draft you are looking at, and is more complete than the one you are reading. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of manoj juneja Sent: Thursday, July 26, 2001 11:34 AM To: ccamp@ops.ietf.org Subject: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt Hi All, I have a doubt regarding draft-kompella-ospf-gmpls-extensions -01.txt. Section 4.1 of this document states that "control channels are advertised into OSPF as normal IS links as mentioned in the previous section". First, What is the need for advertising control channel information in OSPF ? I can very well find the control channel once I get the information about the data channel/interface. There may be one-to-one mapping of control channel and data channel/interface or multiple data interfaces share the same control channel. Second, in the above quoted sentence, I could not find the previous section (prior to section 4.1) in the draft where the information regarding control channels is described. Is this the latest draft ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:46:43 -0700 Reply-To: From: "Vishal Sharma" To: "manoj juneja" , Cc: , Subject: RE: Fwd: RE: {SUKLM} numbering scheme Date: Thu, 26 Jul 2001 11:45:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, Please check the latest version of the OSPF routing enhancements draft (which should show up on the IETF drafts directory sometime this week, or early next week) titled draft-kompella-ospf-gmpls-extensions-02.txt and check the "Interface Switching Capability Descriptor" -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of manoj juneja Sent: Thursday, July 26, 2001 11:24 AM To: lberger@movaz.com Cc: ccamp@ops.ietf.org; Eric.Mannie@ebone.com Subject: Re: Fwd: RE: {SUKLM} numbering scheme Hi Lou, In the latest GMPLS draft(draft-ietf-mpls-generalized -signalling-05.txt), Generalized Label Request object has been modified. Now, It consists of fields LSP encoding type, G-PID and switching type (newly added field). The reference to draft-kompella -ospf-gmpls-extensions-02.txt has been made for the description of switching type field. The latest document that I can found regarding GMPLS extensions to ospf is draft-kompella-ospf-gmpls-extensions-01.txt and this document doesn't mention about switching type. Please clarify where to look for the description of this field. Regards, manoj. >From: Lou Berger >To: "manoj juneja" >CC: ccamp@ops.ietf.org,lberger@movaz.com,Eric.Mannie@ebone.com >Subject: Re: Fwd: RE: {SUKLM} numbering scheme >Date: Thu, 26 Jul 2001 10:22:28 -0400 > >Thank you for catching this. > >Lou > >At 09:26 PM 7/25/01, manoj juneja wrote: >>Hi Eric and Lou, >> The new GMPLS signalling drafts still distinguish >>between different SDH and SONET version of specifications (like 2000, >>1995 etc.). Eric, As u said earlier that we will be having only one >>value for SDH and one for SONET LSP encoding type. please see the mail >>below for further information. I want to know that whether this has been >>done intentionally or it is just a bug that still need to be removed. >> >>Please clarify. >> >>Regards, >>manoj. >>> >>> >>> >>> >>>>From: "Mannie, Eric" >>>>To: 'manoj juneja' , ccamp@ops.ietf.org >>>>CC: "'lberger@movaz.com'" >>>>Subject: RE: {SUKLM} numbering scheme >>>>Date: Thu, 28 Jun 2001 21:38:10 +0200 >>>> >>>>Hello Manoj, >>>> >>>>The label is the same of course. >>>> >>>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is >>>>a >>>>small bug coming from an old version. That should be removed by Lou. We >>>>should have only one SDH LSP encoding type value for SDH (same for >>>>SONET). >>>> >>>>Lou: thanks to correct it. >>>> >>>>For the conversion table, Maarten should still have it. >>>> >>>>Kind regards, >>>> >>>>Eric >>>> >>>>-----Original Message----- >>>>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >>>>Sent: Thursday, June 28, 2001 8:28 PM >>>>To: ccamp@ops.ietf.org >>>>Subject: {SUKLM} numbering scheme >>>> >>>> >>>>Hi All, >>>> I have a doubt regarding {SUKLM} numbering scheme. If I >>>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be >>>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH >>>>ITU-T G.707 2000 ? >>>> >>>>Eric, on the ipo u and marteen once exchanged the conversion table for >>>>EDCBA and SU, If that table is correct, can u please tell me the >>>>formula from which u derived that table ? >>>> >>>>Regards, >>>>manoj. >>>> >>>> >>>>_________________________________________________________________ >>>>Get your FREE download of MSN Explorer at http://explorer.msn.com >>>> >>> >>> >>>_________________________________________________________________ >>>Get your FREE download of MSN Explorer at >>>http://explorer.msn.com/intl.asp >>> >> >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:35:17 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubt in draft-kompella-ospf-gmpls-extensions-01.txt Date: Thu, 26 Jul 2001 11:34:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a doubt regarding draft-kompella-ospf-gmpls-extensions -01.txt. Section 4.1 of this document states that "control channels are advertised into OSPF as normal IS links as mentioned in the previous section". First, What is the need for advertising control channel information in OSPF ? I can very well find the control channel once I get the information about the data channel/interface. There may be one-to-one mapping of control channel and data channel/interface or multiple data interfaces share the same control channel. Second, in the above quoted sentence, I could not find the previous section (prior to section 4.1) in the draft where the information regarding control channels is described. Is this the latest draft ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:25:21 -0700 From: "manoj juneja" To: lberger@movaz.com Cc: ccamp@ops.ietf.org, Eric.Mannie@ebone.com Bcc: Subject: Re: Fwd: RE: {SUKLM} numbering scheme Date: Thu, 26 Jul 2001 11:23:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Lou, In the latest GMPLS draft(draft-ietf-mpls-generalized -signalling-05.txt), Generalized Label Request object has been modified. Now, It consists of fields LSP encoding type, G-PID and switching type (newly added field). The reference to draft-kompella -ospf-gmpls-extensions-02.txt has been made for the description of switching type field. The latest document that I can found regarding GMPLS extensions to ospf is draft-kompella-ospf-gmpls-extensions-01.txt and this document doesn't mention about switching type. Please clarify where to look for the description of this field. Regards, manoj. >From: Lou Berger >To: "manoj juneja" >CC: ccamp@ops.ietf.org,lberger@movaz.com,Eric.Mannie@ebone.com >Subject: Re: Fwd: RE: {SUKLM} numbering scheme >Date: Thu, 26 Jul 2001 10:22:28 -0400 > >Thank you for catching this. > >Lou > >At 09:26 PM 7/25/01, manoj juneja wrote: >>Hi Eric and Lou, >> The new GMPLS signalling drafts still distinguish >>between different SDH and SONET version of specifications (like 2000, >>1995 etc.). Eric, As u said earlier that we will be having only one >>value for SDH and one for SONET LSP encoding type. please see the mail >>below for further information. I want to know that whether this has been >>done intentionally or it is just a bug that still need to be removed. >> >>Please clarify. >> >>Regards, >>manoj. >>> >>> >>> >>> >>>>From: "Mannie, Eric" >>>>To: 'manoj juneja' , ccamp@ops.ietf.org >>>>CC: "'lberger@movaz.com'" >>>>Subject: RE: {SUKLM} numbering scheme >>>>Date: Thu, 28 Jun 2001 21:38:10 +0200 >>>> >>>>Hello Manoj, >>>> >>>>The label is the same of course. >>>> >>>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is >>>>a >>>>small bug coming from an old version. That should be removed by Lou. We >>>>should have only one SDH LSP encoding type value for SDH (same for >>>>SONET). >>>> >>>>Lou: thanks to correct it. >>>> >>>>For the conversion table, Maarten should still have it. >>>> >>>>Kind regards, >>>> >>>>Eric >>>> >>>>-----Original Message----- >>>>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >>>>Sent: Thursday, June 28, 2001 8:28 PM >>>>To: ccamp@ops.ietf.org >>>>Subject: {SUKLM} numbering scheme >>>> >>>> >>>>Hi All, >>>> I have a doubt regarding {SUKLM} numbering scheme. If I >>>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be >>>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH >>>>ITU-T G.707 2000 ? >>>> >>>>Eric, on the ipo u and marteen once exchanged the conversion table for >>>>EDCBA and SU, If that table is correct, can u please tell me the >>>>formula from which u derived that table ? >>>> >>>>Regards, >>>>manoj. >>>> >>>> >>>>_________________________________________________________________ >>>>Get your FREE download of MSN Explorer at http://explorer.msn.com >>>> >>> >>> >>>_________________________________________________________________ >>>Get your FREE download of MSN Explorer at >>>http://explorer.msn.com/intl.asp >>> >> >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:03:23 -0700 content-class: urn:content-classes:message Subject: RE: Optical Link Interface MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jul 2001 14:02:25 -0400 Message-ID: Thread-Topic: Optical Link Interface Thread-Index: AcET6Rkunxz2Vg0QQUGZnJ30+xsN9wCE+gzw From: "Martin Dubuc" To: "Andre Fredette" Cc: I support your proposal. Martin -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 11:02:02 -0700 content-class: urn:content-classes:message Subject: RE: Optical Link Interface MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jul 2001 14:00:14 -0400 Message-ID: Thread-Topic: Optical Link Interface Thread-Index: AcEVeDbMLCTFunncTYKbhcEipaT8bgAg6O7w From: "Martin Dubuc" To: "Kireeti Kompella" , , Cc: , , 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: Thu, 26 Jul 2001 10:56:01 -0700 Message-ID: <3B605936.AD968396@cisco.com> Date: Thu, 26 Jul 2001 10:53:58 -0700 From: Suresh Katukam Organization: Cisco Systems MIME-Version: 1.0 To: rajesh@tejasnetworks.com CC: Martin Dubuc , mpls@UU.NET, jplang@calient.net, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Queries regarding LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rajesh, > > > > Q3) Destination address can be multicast or any valid IP address of > > destination node (most likely the NodeID of the destination node). > > If it is the Node ID of the neighbour then how does one find it > without manual configuration ?? Is it with the help of an IGP > such as OSPF ? We would like to automate things as much as > possible. Initial Config message will go out on a multicast address. This makes it easy for initial communication. All other messages will be addressed to Node ID. Section 9 of OIF2000.125.5. clairifies this issues. This may change again if Node ID is not be a routable IP address. It should be really the source IP address of the Config message to whom you should send your LMP messages. Thanks, Suresh > > If LMP is designed as an independent protocol then IMHO > we should use a multicast address. > > Regds, > - Rajesh Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jul 2001 07:25:36 -0700 Message-Id: <4.3.2.7.2.20010726102157.00b0ef00@mo-ex1> Date: Thu, 26 Jul 2001 10:22:28 -0400 To: "manoj juneja" From: Lou Berger Subject: Re: Fwd: RE: {SUKLM} numbering scheme Cc: ccamp@ops.ietf.org,lberger@movaz.com,Eric.Mannie@ebone.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Thank you for catching this. Lou At 09:26 PM 7/25/01, manoj juneja wrote: >Hi Eric and Lou, > The new GMPLS signalling drafts still distinguish >between different SDH and SONET version of specifications (like 2000, >1995 etc.). Eric, As u said earlier that we will be having only one >value for SDH and one for SONET LSP encoding type. please see the mail >below for further information. I want to know that whether this has been >done intentionally or it is just a bug that still need to be removed. > >Please clarify. > >Regards, >manoj. >> >> >> >> >>>From: "Mannie, Eric" >>>To: 'manoj juneja' , ccamp@ops.ietf.org >>>CC: "'lberger@movaz.com'" >>>Subject: RE: {SUKLM} numbering scheme >>>Date: Thu, 28 Jun 2001 21:38:10 +0200 >>> >>>Hello Manoj, >>> >>>The label is the same of course. >>> >>>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a >>>small bug coming from an old version. That should be removed by Lou. We >>>should have only one SDH LSP encoding type value for SDH (same for SONET). >>> >>>Lou: thanks to correct it. >>> >>>For the conversion table, Maarten should still have it. >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >>>Sent: Thursday, June 28, 2001 8:28 PM >>>To: ccamp@ops.ietf.org >>>Subject: {SUKLM} numbering scheme >>> >>> >>>Hi All, >>> I have a doubt regarding {SUKLM} numbering scheme. If I >>>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be >>>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH >>>ITU-T G.707 2000 ? >>> >>>Eric, on the ipo u and marteen once exchanged the conversion table for >>>EDCBA and SU, If that table is correct, can u please tell me the >>>formula from which u derived that table ? >>> >>>Regards, >>>manoj. >>> >>> >>>_________________________________________________________________ >>>Get your FREE download of MSN Explorer at http://explorer.msn.com >>> >> >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 20:06:51 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Andre Fredette'" , "'Kireeti Kompella'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 23:04:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1157F.A72F0130" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1157F.A72F0130 Content-Type: text/plain; charset="iso-8859-1" I actually found it pretty weak. Bilel. That's a very interesting analogy. Andre At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote: >In an ideal world, CR-LDP as an extension of LDP would have been >the way to go. It's funny that you should be arguing on the other >side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read >CR-LDP) which is just an extension of LMP (read LDP) which nobody >needs anyway (read "TE is the only MPLS app"). Such is life .. ------_=_NextPart_001_01C1157F.A72F0130 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface

I actually found it pretty weak.

Bilel.


That's a very interesting analogy.

Andre

At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote:
>In an ideal world, CR-LDP as an extension of LDP would have been
>the way to go.  It's funny that you should be arguing on the other
>side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
>CR-LDP) which is just an extension of LMP (read LDP) which nobody
>needs anyway (read "TE is the only MPLS app").  Such is life ..

------_=_NextPart_001_01C1157F.A72F0130-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 20:04:39 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Kireeti Kompella'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 23:01:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1157F.509D23B0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1157F.509D23B0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, > [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS > applications. The market has settled on RSVP-TE in ONE of the many MPLS > applications -- namely Traffic Engineering of an IP network -- It's irrelevant what application RSVP-TE fits in. RSVP-TE and CR-LDP do the same thing in slightly different ways. [Bilel] only time will tell. In an ideal world, CR-LDP as an extension of LDP would have been the way to go. It's funny that you should be arguing on the other side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read CR-LDP) which is just an extension of LMP (read LDP) which nobody needs anyway (read "TE is the only MPLS app"). Such is life ... [Bilel] 2 very different situations. + RSVP-TE is an extension of RSVP -- Are you saying "TE is the only MPLS app" ? or is the JD effect? Bilel. ------_=_NextPart_001_01C1157F.509D23B0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface

Hi Kireeti,

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
> applications. The market has settled on RSVP-TE in ONE of the many MPLS
> applications -- namely Traffic Engineering of an IP network --

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

[Bilel] only time will tell.

In an ideal world, CR-LDP as an extension of LDP would have been
the way to go.  It's funny that you should be arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) which nobody
needs anyway (read "TE is the only MPLS app").  Such is life ...

[Bilel] 2 very different situations. + RSVP-TE is an extension of RSVP --
Are you saying "TE is the only MPLS app" ? or is the JD effect?

Bilel.

------_=_NextPart_001_01C1157F.509D23B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 19:00:02 -0700 Date: Wed, 25 Jul 2001 18:57:27 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107260157.SAA02400@kummer.juniper.net> To: jamoussi@nortelnetworks.com, kireeti@juniper.net, osama@nortelnetworks.com Subject: RE: Optical Link Interface Cc: bon@nortelnetworks.com, ccamp@ops.ietf.org, vasants@nortelnetworks.com 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, 25 Jul 2001 18:27:02 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: lberger@movaz.com, Eric.Mannie@ebone.com Bcc: Subject: Fwd: RE: {SUKLM} numbering scheme Date: Wed, 25 Jul 2001 18:26:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric and Lou, The new GMPLS signalling drafts still distinguish between different SDH and SONET version of specifications (like 2000, 1995 etc.). Eric, As u said earlier that we will be having only one value for SDH and one for SONET LSP encoding type. please see the mail below for further information. I want to know that whether this has been done intentionally or it is just a bug that still need to be removed. Please clarify. Regards, manoj. > > > > >>From: "Mannie, Eric" >>To: 'manoj juneja' , ccamp@ops.ietf.org >>CC: "'lberger@movaz.com'" >>Subject: RE: {SUKLM} numbering scheme >>Date: Thu, 28 Jun 2001 21:38:10 +0200 >> >>Hello Manoj, >> >>The label is the same of course. >> >>The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a >>small bug coming from an old version. That should be removed by Lou. We >>should have only one SDH LSP encoding type value for SDH (same for SONET). >> >>Lou: thanks to correct it. >> >>For the conversion table, Maarten should still have it. >> >>Kind regards, >> >>Eric >> >>-----Original Message----- >>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >>Sent: Thursday, June 28, 2001 8:28 PM >>To: ccamp@ops.ietf.org >>Subject: {SUKLM} numbering scheme >> >> >>Hi All, >> I have a doubt regarding {SUKLM} numbering scheme. If I >>allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be >>different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH >>ITU-T G.707 2000 ? >> >>Eric, on the ipo u and marteen once exchanged the conversion table for >>EDCBA and SU, If that table is correct, can u please tell me the >>formula from which u derived that table ? >> >>Regards, >>manoj. >> >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at http://explorer.msn.com >> >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 18:14:48 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04453261@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Andre Fredette Cc: Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 21:11:05 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1156F.D83DDA90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1156F.D83DDA90 Content-Type: text/plain; charset="iso-8859-1" Andre, Please go ahead and implement LMP. As I mentioned it is optional, and that is your choice. My argument applies to LMP-WDM. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 3:47 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Comments inline. At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote: Andre, This is a misrepresentation of my argument. My argument is: - LMP is at best optional. This is your opinion. The members of the CCAMP working group have decided that LMP is useful and needs to be specified. Not everyone is going to implement it. - Let's not try to force it on everyone. The way I read this is that you don't plan to implement LMP, so you want to make it harder for those that do? Therefore your argument to use LMP is not reasonable. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Wednesday, July 25, 2001 2:11 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C1156F.D83DDA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A= ndre,

<= ![if = !supportEmptyParas]> 

=

P= lease go ahead and implement LMP. As I mentioned it is optional, and that is = your choice. My argument applies to LMP-WDM. =

<= ![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: Andre Fredette = [mailto:fredette@photonex.com]
Sent: Wednesday, July = 25, 2001 3:47 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

 

Comments inline.

At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:

Andre,

This is a misrepresentation of my = argument.
My argument is:
- LMP is at best optional. =


This is your opinion.  The members of the CCAMP working group have = decided that LMP is useful and needs to be specified.


Not everyone is going to implement it.
- Let's not try to force it on everyone.=


The way I read this is that you don't plan to implement LMP, so you = want to make it harder for those that do?



Therefore your argument to use LMP is not reasonable.

Regards;

Osama Aboul-Magd
Nortel = Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July = 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it = is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will = be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what = is the limitation here? Are you saying having a simple design is a limitation? = Not everything has to be complex.

[Jonathan]  Other DWDM vendors are = not happy with the master-slave model.  Also, the claim that NTIP is simple = is an explicit assertion and you seem to be trying to make an implicit = assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that = the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think = this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back = them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by = the ADs and
Working Group chairs in Minnesota that only one protocol = will progress in
the IETF.

[Osama] I don't understand why CR-LDP and RSVP-TE have = been brought to this discussion. This is a completely different situation. = LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both = being developed prior to either one of them being widely deployed.  The = effort involved in developing 2 protocols concurrently to do the same thing is = widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that = do basically the same thing and one, I think the choice should be = clear.

Andre

------_=_NextPart_001_01C1156F.D83DDA90-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 18:06:19 -0700 Message-ID: From: John Drake To: 'Osama Aboul-Magd' , Kireeti Kompella , Bilel Jamoussi Cc: ccamp@ops.ietf.org, Vasant Sahay , Babu Narayanan Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 18:02:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1156E.AEFE6CE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1156E.AEFE6CE0 Content-Type: text/plain; charset="iso-8859-1" "the existence of two protocols here have proven to be useful." What in the world does this mean? Useful to who and for what? -----Original Message----- From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] Sent: Wednesday, July 25, 2001 5:46 PM To: Kireeti Kompella; Bilel Jamoussi Cc: ccamp@ops.ietf.org; Vasant Sahay; Babu Narayanan Subject: RE: Optical Link Interface Kireeti. Even though I don't think reviving CR-LDP and RSVP-TE history will get us anywhere, there should always be the chance to offer customers the black model T. the existence of two protocols here have proven to be useful. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Kireeti Kompella [ mailto:kireeti@juniper.net ] Sent: Wednesday, July 25, 2001 5:04 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Bilel, > [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS > applications. The market has settled on RSVP-TE in ONE of the many MPLS > applications -- namely Traffic Engineering of an IP network -- It's irrelevant what application RSVP-TE fits in. RSVP-TE and CR-LDP do the same thing in slightly different ways. In an ideal world, CR-LDP as an extension of LDP would have been the way to go. It's funny that you should be arguing on the other side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read CR-LDP) which is just an extension of LMP (read LDP) which nobody needs anyway (read "TE is the only MPLS app"). Such is life ... > The (I)SPs > that deployed it did not have a choice from their vendors. Guilty as charged. We gave them black model Ts, and they liked them. They didn't ask for any other colors, and aren't asking now, apart from idle curiosity. > Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The > market prefers competing solutions to get the best of breed. All the ISP folks that I know who had to make a choice say that the process of choosing is mostly non-technical, and very much a big pain. The data I have indicates that the market wants competing implementations of the same standard, not competing standards. That's where the real value of "best of breed" lies. Kireeti. ------_=_NextPart_001_01C1156E.AEFE6CE0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
"the existence of two protocols here have proven to be useful."  What in the world does this mean?  Useful to who and for what?
 
-----Original Message-----
From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 5:46 PM
To: Kireeti Kompella; Bilel Jamoussi
Cc: ccamp@ops.ietf.org; Vasant Sahay; Babu Narayanan
Subject: RE: Optical Link Interface

Kireeti.

Even though I don't think reviving CR-LDP and RSVP-TE history will get us anywhere, there should always be the chance to offer customers the black model T. the existence of two protocols here have proven to be useful.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Kireeti Kompella [mailto:kireeti@juniper.net]
Sent:   Wednesday, July 25, 2001 5:04 PM
To:     Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc:     ccamp@ops.ietf.org
Subject:        RE: Optical Link Interface

Hi Bilel,

> [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS
> applications. The market has settled on RSVP-TE in ONE of the many MPLS
> applications -- namely Traffic Engineering of an IP network --

It's irrelevant what application RSVP-TE fits in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

In an ideal world, CR-LDP as an extension of LDP would have been
the way to go.  It's funny that you should be arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) which nobody
needs anyway (read "TE is the only MPLS app").  Such is life ...

> The (I)SPs
> that deployed it did not have a choice from their vendors.

Guilty as charged.  We gave them black model Ts, and they liked them.
They didn't ask for any other colors, and aren't asking now, apart
from idle curiosity.

> Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The
> market prefers competing solutions to get the best of breed.

All the ISP folks that I know who had to make a choice say that
the process of choosing is mostly non-technical, and very much a
big pain.

The data I have indicates that the market wants competing
implementations of the same standard, not competing standards.
That's where the real value of "best of breed" lies.

Kireeti.

------_=_NextPart_001_01C1156E.AEFE6CE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 18:05:29 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04453260@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Dimitri Papadimitriou , Andre Fredette Cc: "Hamid Ould-Brahim" , Jonathan Lang , ccamp , "Vasant Sahay" , "Babu Narayanan" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 21:01:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1156E.8BF48BD0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1156E.8BF48BD0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, Thanks for your advice. I don't know what information model you are looking at. Does it belong to LTSFGTC class? The immediate problem is the inter-working between OXC-LS, and for that you don't need LMP. I suggest you have your model kept with other "obsolete information models" Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Wednesday, July 25, 2001 6:56 PM To: Andre Fredette Cc: Ould-Brahim, Hamid [CAR:1A00:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; Jonathan Lang; ccamp Subject: Re: Optical Link Interface << File: Card for Dimitri Papadimitriou >> Hi Andre et all, The argument you stated in your previous e-mail is fundamental, as explained in the document we have a protocol for the OXC-OXC interaction so that the "logical" solution is to extend the proposed protocol to the intra-link exchange of information whatever kind of device it is (WDM or others). Sorry Vijay, from this point of view it is not only a carrier facility but also related to the consistency of the approach proposed by your supplier. Use the same protocol for both functions is one of the key element to achieve the expected objective. Consequently, the solution proposed by Osama and colleagues can be clearly put on the shelf of the "lost protocols" because even if fulfilling the same requirements it doesn't fit into a consistent informational model. Regards, Dimitri. Andre Fredette wrote: > > At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote: > > > Andre, > > > >> > >> Osama, > >> > >> [Note: I tried to trim this note down to the key arguments so that > >> it is easier to follow.] > >> > >> My main argument (and I believe it is shared by the rest of the > >> LMP-WDM co-authors) is as follows: > >> 1. LMP exists. > >> 2. LMP solves most of the OLI problems, > >> 3. Therefore, let's use LMP. > >> > >> Osama's main argument is: > >> 1. I don't think LMP should exist. > >> 2. Therefore let's create a new protocol. > >> > >> Given that the members of the working group have decided that LMP > >> will be developed, I don't think Osama's argument is reasonable. > >> > >> We went through that before and the WG has decided to make > >> explicit the clarification that the issue is just between > >> LMP-WDM and NTIP and not between LMP and NTIP. > > > > The whole point of LMP-WDM is to use an existing protocol to solve a > new problem rather than create a new protocol just for the sake of > creating a new one. If there is a technical argument against using > LMP for this problem, let's hear it! > > >> > >> Besides that I think that some of the arguments > >> advanced are: > >> > >> 1. The issue is not how many protocols need to be advanced. > > > > This is a significant issue. > > >> > >> 2. The choice of advancing a given protocol should be > >> influenced by whether it is deployed or likely to be > >> widely deployed. And this applies even in the case > >> of one single protocol. > >> > >> 3. No matter what protocol(s) is/are selected, > >> it is the market who makes the final decision. > >> > >> Hamid. > >> > >> At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: > >> > >> > [Osama] what is the limitation here? Are you saying > >> > having a simple design is a limitation? Not everything has > >> > to be complex. > >> > [Jonathan] Other DWDM vendors are not happy with the > >> > master-slave model. Also, the claim that NTIP is simple is > >> > an explicit assertion and you seem to be trying to make an > >> > implicit assertion that LMP is complex. > >> > > >> > >> On the master-slave issue. There is clearly some information that > >> the line system does not need. For example, I don't expect the > >> Link Characteristics need to be advertised from OXC to OLS. I > >> think this works fine within the context of LMP. > >> > >> You have made claims of complexity, but have never been able to > >> back them up with fact. > >> > >> > Given the CR-LDP fiasco in MPLS, it was clearly stated by > >> > the ADs and > >> > Working Group chairs in Minnesota that only one protocol > >> > will progress in > >> > the IETF. > >> > > >> > [Osama] I don't understand why CR-LDP and RSVP-TE have been > >> > brought to this discussion. This is a completely different > >> > situation. LMP hasn't seen the wide deployment that RSVP-TE > >> > has. The example is inadequate. > >> > > >> > [Jonathan] CR-LDP and RSVP-TE were both being developed > >> > prior to either one of them being widely deployed. The > >> > effort involved in developing 2 protocols concurrently to do > >> > the same thing is widely perceived as being counter > >> > productive. > >> > > >> > >> Given the choice between specifying and implementing two protocols > >> that do basically the same thing and one, I think the choice > >> should be clear. > >> > >> Andre > > ------_=_NextPart_001_01C1156E.8BF48BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

Dimitri,

Thanks for your advice. I don't know what information = model you are looking at. Does it belong to LTSFGTC class?

The immediate problem is the inter-working between = OXC-LS, and for that you don't need LMP. I suggest you have your model = kept with other "obsolete information models"

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Dimitri Papadimitriou [mailto:dimitri.papadimi= triou@alcatel.be]
Sent:   Wednesday, July 25, 2001 6:56 = PM
To:     Andre Fredette
Cc:     Ould-Brahim, Hamid = [CAR:1A00:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; Jonathan Lang; = ccamp
Subject:        = Re: Optical Link Interface

 << File: Card for Dimitri Papadimitriou = >> Hi Andre et all,

The argument you stated in your previous e-mail is = fundamental,
as explained in the document we have a protocol for = the OXC-OXC
interaction so that the "logical" solution = is to extend the
proposed protocol to the intra-link exchange of = information
whatever kind of device it is (WDM or others). =

Sorry Vijay, from this point of view it is not only a = carrier
facility but also related to the consistency of the = approach
proposed by your supplier. Use the same protocol for = both
functions is one of the key element to achieve the = expected
objective.

Consequently, the solution proposed by Osama and = colleagues can
be clearly put on the shelf of the "lost = protocols" because even
if fulfilling the same requirements it doesn't fit = into a
consistent informational model.

Regards,
Dimitri. 

Andre Fredette wrote:
>
> At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim = wrote:
>
> > Andre,
> >
> >>
> >> Osama,
> >>
> >> [Note: I tried to trim this note down = to the key arguments so that
> >> it is easier to follow.]
> >>
> >> My main argument (and I believe it is = shared by the rest of the
> >> LMP-WDM co-authors) is as = follows:
> >> 1. LMP exists.
> >> 2. LMP solves most of the OLI = problems,
> >> 3. Therefore, let's use LMP.
> >>
> >> Osama's main argument is:
> >> 1. I don't think LMP should = exist.
> >> 2. Therefore let's create a new = protocol.
> >>
> >> Given that the members of the working = group have decided that LMP
> >> will be developed, I don't think = Osama's argument is reasonable.
> >>
> >> We went through that before and the WG = has decided to make
> >> explicit the clarification that the = issue is just between
> >> LMP-WDM and NTIP and not between LMP = and NTIP.
> >
>
> The whole point of LMP-WDM is to use an = existing protocol to solve a
> new problem rather than create a new protocol = just for the sake of
> creating a new one.  If there is a = technical argument against using
> LMP for this problem, let's hear it!
>
> >>
> >> Besides that I think that some of the = arguments
> >> advanced are:
> >>
> >> 1. The issue is not how many protocols = need to be advanced.
> >
>
> This is a significant issue.
>
> >>
> >> 2. The choice of advancing a given = protocol should be
> >>    influenced by = whether it is deployed or likely to be
> >>    widely deployed. And = this applies even in the case
> >>    of one single = protocol.
> >>
> >> 3. No matter what protocol(s) is/are = selected,
> >>    it is the market who = makes the final decision.
> >>
> >> Hamid.
> >>
> >> At 10:41 AM 7/25/2001 -0700, Jonathan = Lang wrote:
> >>
> >> = >           &n= bsp;  [Osama] what is the limitation here? Are you saying
> >> >      = having a simple design is a limitation? Not everything has
> >> >      to = be complex.
> >> >      = [Jonathan]  Other DWDM vendors are not happy with the
> >> >      = master-slave model.  Also, the claim that NTIP is simple is
> >> >      an = explicit assertion and you seem to be trying to make an
> >> >      = implicit assertion that LMP is complex.
> >> >
> >>
> >> On the master-slave issue.  There = is clearly some information that
> >> the line system does not need.  = For example, I don't expect the
> >> Link Characteristics need to be = advertised from OXC to OLS.  I
> >> think this works fine within the = context of LMP.
> >>
> >> You have made claims of complexity, = but have never been able to
> >> back them up with fact.
> >>
> >> >      = Given the CR-LDP fiasco in MPLS, it was clearly stated by
> >> >      the = ADs and
> >> >      = Working Group chairs in Minnesota that only one protocol
> >> >      = will progress in
> >> >      the = IETF.
> >> >
> >> >      = [Osama] I don't understand why CR-LDP and RSVP-TE have been
> >> >      = brought to this discussion. This is a completely different
> >> >      = situation. LMP hasn't seen the  wide deployment that = RSVP-TE
> >> >      = has. The example is inadequate.
> >> >
> >> >      = [Jonathan] CR-LDP and RSVP-TE were both being developed
> >> >      = prior to either one of them being widely deployed.  The
> >> >      = effort involved in developing 2 protocols concurrently to do
> >> >      the = same thing is widely perceived as being counter
> >> >      = productive.
> >> >
> >>
> >> Given the choice between specifying = and implementing two protocols
> >> that do basically the same thing and = one, I think the choice
> >> should be clear.
> >>
> >> Andre
> >

------_=_NextPart_001_01C1156E.8BF48BD0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 17:51:33 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F0445325F@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Kireeti Kompella , "Bilel Jamoussi" Cc: ccamp@ops.ietf.org, "Vasant Sahay" , "Babu Narayanan" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 20:46:24 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1156C.656C1D40" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1156C.656C1D40 Content-Type: text/plain; charset="iso-8859-1" Kireeti. Even though I don't think reviving CR-LDP and RSVP-TE history will get us anywhere, there should always be the chance to offer customers the black model T. the existence of two protocols here have proven to be useful. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Wednesday, July 25, 2001 5:04 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH] Cc: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Bilel, > [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS > applications. The market has settled on RSVP-TE in ONE of the many MPLS > applications -- namely Traffic Engineering of an IP network -- It's irrelevant what application RSVP-TE fits in. RSVP-TE and CR-LDP do the same thing in slightly different ways. In an ideal world, CR-LDP as an extension of LDP would have been the way to go. It's funny that you should be arguing on the other side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read CR-LDP) which is just an extension of LMP (read LDP) which nobody needs anyway (read "TE is the only MPLS app"). Such is life ... > The (I)SPs > that deployed it did not have a choice from their vendors. Guilty as charged. We gave them black model Ts, and they liked them. They didn't ask for any other colors, and aren't asking now, apart from idle curiosity. > Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The > market prefers competing solutions to get the best of breed. All the ISP folks that I know who had to make a choice say that the process of choosing is mostly non-technical, and very much a big pain. The data I have indicates that the market wants competing implementations of the same standard, not competing standards. That's where the real value of "best of breed" lies. Kireeti. ------_=_NextPart_001_01C1156C.656C1D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

Kireeti.

Even though I don't think reviving CR-LDP and RSVP-TE = history will get us anywhere, there should always be the chance to = offer customers the black model T. the existence of two protocols here = have proven to be useful.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Kireeti Kompella [mailto:kireeti@juniper.net] =
Sent:   Wednesday, July 25, 2001 5:04 = PM
To:     Jamoussi, Bilel = [BL60:1A00-M:EXCH]
Cc:     = ccamp@ops.ietf.org
Subject:        = RE: Optical Link Interface

Hi Bilel,

> [Bilel Jamoussi] John, you seem to have a very = narrow view of MPLS
> applications. The market has settled on RSVP-TE = in ONE of the many MPLS
> applications -- namely Traffic Engineering of = an IP network --

It's irrelevant what application RSVP-TE fits = in.  RSVP-TE and CR-LDP
do the same thing in slightly different ways.

In an ideal world, CR-LDP as an extension of LDP = would have been
the way to go.  It's funny that you should be = arguing on the other
side now -- let's do NTIP (read RSVP-TE) instead of = LMP-WDM (read
CR-LDP) which is just an extension of LMP (read LDP) = which nobody
needs anyway (read "TE is the only MPLS = app").  Such is life ...

> The (I)SPs
> that deployed it did not have a choice from = their vendors.

Guilty as charged.  We gave them black model Ts, = and they liked them.
They didn't ask for any other colors, and aren't = asking now, apart
from idle curiosity.

> Also, the market has 2 routing protocols in the = IGP: OSPF and IS-IS -- The
> market prefers competing solutions to get the = best of breed.

All the ISP folks that I know who had to make a = choice say that
the process of choosing is mostly non-technical, and = very much a
big pain.

The data I have indicates that the market wants = competing
implementations of the same standard, not competing = standards.
That's where the real value of "best of = breed" lies.

Kireeti.

------_=_NextPart_001_01C1156C.656C1D40-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 17:34:34 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F0445325E@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Bala Rajagopalan , "'Kireeti Kompella'" , ccamp@ops.ietf.org Cc: "Vasant Sahay" , "Babu Narayanan" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 20:32:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1156A.7F02EF60" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1156A.7F02EF60 Content-Type: text/plain; charset="iso-8859-1" Neighbor discovery is included in the latest revision of the draft. I submitted last Friday. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] Sent: Wednesday, July 25, 2001 5:54 PM To: 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Kireeti: Thanks for distilling the issues into the 3 bullet items. I would also like to add my two cents on these points as an OXC vendor: > a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol. > I think both choices have pitfalls. LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One may exist without the other. Indeed, for a WDM vendor, LMP-WDM will be a new protocol to implement. If they balk, I can't unilaterally choose LMP-WDM on the OXC side. Also, my experience so far has been that neighbor discovery based on LMP is not simple to realize in transparent switches, the main candidate for OLI. So, the question of LMP-WDM as an extension of LMP (as it currently stands) may be moot. NTIP: The present definition does not provide for neighbor discovery, a function required under OLI. Is another protocol required for this? If so, the value of NTIP is diluted. So, I think a case can be made for NTIP only if the neighbor disc. function is taken out of OLI. Similarly, a rather strong case for LMP-WDM can be made if the LMP neighbor disc. functionality could be simplified. I would personally prefer the second option since it provides a complete package (if there is any all-optical vendor out there who has got LMP neighbor discovery running, send me email :-) ). > > b) Two protocols vs. one. > One. But one that is useful in practice. > > c) The model: master-slave vs. peer. > Both LMP-WDM and NTIP can operate in the request-response mode. I don't see this as an issue. > > d) The transport protocol: TCP or raw over IP. > No big deal either way. ------_=_NextPart_001_01C1156A.7F02EF60 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface

Neighbor discovery is included in the latest revision of the draft. I submitted last Friday.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Bala Rajagopalan [mailto:BRaja@tellium.com]
Sent:   Wednesday, July 25, 2001 5:54 PM
To:     'Kireeti Kompella'; ccamp@ops.ietf.org
Subject:        RE: Optical Link Interface

Kireeti:

Thanks for distilling the issues into the 3 bullet
items. I would also like to add my two cents on these
points as an OXC vendor:


> a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol.
>
  I think both choices have pitfalls.

  LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One
may exist without the other. Indeed, for a WDM vendor, LMP-WDM
will be a new protocol to implement. If they balk, I can't unilaterally
choose LMP-WDM on the OXC side. Also, my experience so far
has been that neighbor discovery based on LMP is not simple
to realize in transparent switches, the main candidate for OLI.
So, the question of LMP-WDM as an extension of LMP (as it
currently stands) may be moot.

  NTIP: The present definition does not provide for neighbor
  discovery, a function required under OLI. Is another protocol
  required for this? If so, the value of NTIP is diluted.

So, I think a case can be made for NTIP only if the neighbor
disc. function is taken out of OLI. Similarly, a rather strong
case for LMP-WDM can be made if the LMP neighbor disc. functionality
could be simplified. I would personally prefer the second
option since it provides a complete package
(if there is any all-optical vendor out there who
has got LMP neighbor discovery running, send me email :-) ).


>
> b) Two protocols vs. one.
>
    One. But one that is useful in practice.
>
> c) The model: master-slave vs. peer.
>
 Both LMP-WDM and NTIP can operate in the request-response mode.
I don't see this as an issue.

>
> d) The transport protocol: TCP or raw over IP.
>
  No big deal either way.



------_=_NextPart_001_01C1156A.7F02EF60-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 16:21:58 -0700 From: Andre Fredette To: Sudheer Dharanikota Cc: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010725191957.03168458@mailbox> Date: Wed, 25 Jul 2001 19:20:46 -0400 Subject: Re: Optical Link Interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Good points. Andre At 02:10 PM 7/25/2001 -0700, Sudheer Dharanikota wrote: >Hi: > >My few cents .. being involved in these discussions. > >Kireeti Kompella wrote: > > > > > > > c) The model: master-slave vs. peer. > > > > This is the key debate (in my opinion). Is LMP-WDM a "natural > > extension of LMP", as Andre says; or is the master-slave model > > more appropriate in this context, as Osama says? > > > >The issue here is who has the control over which resource. >The OXCs have control over the links and link bundles, and >the DWDMs have the control over the fault reporting behaviour, >the monitoring (may not be in the first release of the requirements) >and the mapping of logical nature of the links and link bundles >to the physical resources. > >In my opinion there are and there will be DWDM and OXC >boxes which will not be capable of doing all the required >features (as mentioned in the above paragraph). This leads >to negotiation of features (or capabilities) between the two. > >Hence I feel this protocol LMP-DWDM or NTIP should be a >peer-to-peer protocol. > > > > > d) The transport protocol: TCP or raw over IP. > > > > Does the reliability of using TCP as transport offer a real > > advantage in this context? Or do the complications of > > managing failover with TCP outweigh this benefit? > > > > > >The main goal of these protocols is to report a failure as >quickly as possible. A failure typically effect multiple >links. Another observation is that the two elements (DWDM and >OXC) need not be immediate neighbors. They can go through >DCN. But in either case the amount of traffic in the control >plane may not cause packet losses. > >With these two observations I feel that TCP is an over kill. > > >Cheers, > >sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 16:20:29 -0700 From: Andre Fredette To: Kireeti Kompella Cc: jamoussi@nortelnetworks.com, ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010725191734.02595008@mailbox> Date: Wed, 25 Jul 2001 19:19:26 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed That's a very interesting analogy. Andre At 02:04 PM 7/25/2001 -0700, Kireeti Kompella wrote: >In an ideal world, CR-LDP as an extension of LDP would have been >the way to go. It's funny that you should be arguing on the other >side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read >CR-LDP) which is just an extension of LMP (read LDP) which nobody >needs anyway (read "TE is the only MPLS app"). Such is life ... Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 16:18:33 -0700 From: Andre Fredette To: Kireeti Kompella Cc: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010725183017.0242c0d8@mailbox> Date: Wed, 25 Jul 2001 19:17:16 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Kireeti, Thank you for helping us to focus on the technical arguments. I agree with your comments below. On the master-slave vs. peer issue, I think both would work, but the peer model is more flexible without being significantly more complex. LMP is just not a complex protocol (no matter how you slice it). Andre At 01:39 PM 7/25/2001 -0700, Kireeti Kompella wrote: >Hi, > >This email is as a router vendor/implementor. > >The issues (so far) are: > >a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol. > > Subject to (c) below, I much prefer having to implement LMP > (which I will have to) and add on the features needed for > the OLI, rather than implement two different protocols. The > rationale is the same as was used when deciding to extend > link state IGPs with TE information rather than do a new TE > link state flooding protocol, or to do GMPLS as an extension > of MPLS rather than develop a new optical signaling protocol. > >b) Two protocols vs. one. > > One. > >c) The model: master-slave vs. peer. > > I'm not qualified to speak here; this is the domain of the > optical gurus. However, I'll make two tangential points. The > first is that the answer seems to depend on the architecture > of the component systems, which probably indicates that the > protocol should do both. The second is a piece of generic > wisdom (?) that it is generally easier to add bells onto a > peer-oriented protocol to deal with the master-slave case > than to add whistles to a master-slave protocol to make it > work in the peer case. > >d) The transport protocol: TCP or raw over IP. > > It is my understanding that the PXC-WDM link is usually one IP > hop; it seems that TCP is an overkill in that case. Also, > building failover capability for TCP-based protocols is rather > more challenging. > > (Side note: both protocols can be made to work either way, so > this is not so much of an NTIP-LMP_WDM issue as much as "what > transport should OLI use?") > >Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 16:05:08 -0700 Message-Id: <4.3.2.7.2.20010725190653.022108d0@bucket.cisco.com> Date: Wed, 25 Jul 2001 19:09:47 -0400 To: "Bilel Jamoussi" , "'Jonathan Lang'" , "Osama Aboul-Magd" , "'Andre Fredette'" , "'ccamp@ops.ietf.org'" From: "Thomas D. Nadeau" Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_38487371==_.ALT" --=====================_38487371==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been >talking to view this as a very healthy and competitive approach to have a >scalable and robust solution(s). Traffic Engineering an IP network (the >only application where RSVP-TE is deployed today) is a very narrow segment >of the MPLS/GMPLS applications market. Not exactly. I think that we want a scalable and robust *standard* and competitive implementations, not competing standards. Remember Beta vs. VHS? That is a good example of what happens when you get the latter: consumer confusion and inevitably wasted money and effort on the part of both the consumer and the vendor. :( I think that the ADs are right here: lets settle on a single solution soon. I would opt for LMP and LMP-WDM for the reasons already espoused. --Tom --=====================_38487371==_.ALT Content-Type: text/html; charset="us-ascii"
[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been talking to view this as a very healthy and competitive approach to have a scalable and robust solution(s). Traffic Engineering an IP network (the only application where RSVP-TE is deployed today) is a very narrow segment of the MPLS/GMPLS applications market.

        Not exactly. I think that we want a scalable and
robust *standard* and competitive implementations,
not competing standards. Remember Beta vs. VHS? That
is a good example of what happens when you get the
latter: consumer confusion and inevitably wasted money
and effort on the part of both the consumer and the
vendor. :(  I think that the ADs are right here: lets
settle on a single solution soon. I would opt for LMP
and LMP-WDM for the reasons already espoused.

        --Tom

--=====================_38487371==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 15:57:39 -0700 Message-ID: <3B5F4E99.F0B16B6C@alcatel.be> Date: Thu, 26 Jul 2001 00:56:25 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG-NA MIME-Version: 1.0 To: Andre Fredette CC: Hamid Ould-Brahim , Osama Aboul-Magd , Jonathan Lang , ccamp Subject: Re: Optical Link Interface Content-Type: multipart/mixed; boundary="------------5FAC6B0E9FA6E01440A67834" This is a multi-part message in MIME format. --------------5FAC6B0E9FA6E01440A67834 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andre et all, The argument you stated in your previous e-mail is fundamental, as explained in the document we have a protocol for the OXC-OXC interaction so that the "logical" solution is to extend the proposed protocol to the intra-link exchange of information whatever kind of device it is (WDM or others). Sorry Vijay, from this point of view it is not only a carrier facility but also related to the consistency of the approach proposed by your supplier. Use the same protocol for both functions is one of the key element to achieve the expected objective. Consequently, the solution proposed by Osama and colleagues can be clearly put on the shelf of the "lost protocols" because even if fulfilling the same requirements it doesn't fit into a consistent informational model. Regards, Dimitri. Andre Fredette wrote: > > At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote: > > > Andre, > > > >> > >> Osama, > >> > >> [Note: I tried to trim this note down to the key arguments so that > >> it is easier to follow.] > >> > >> My main argument (and I believe it is shared by the rest of the > >> LMP-WDM co-authors) is as follows: > >> 1. LMP exists. > >> 2. LMP solves most of the OLI problems, > >> 3. Therefore, let's use LMP. > >> > >> Osama's main argument is: > >> 1. I don't think LMP should exist. > >> 2. Therefore let's create a new protocol. > >> > >> Given that the members of the working group have decided that LMP > >> will be developed, I don't think Osama's argument is reasonable. > >> > >> We went through that before and the WG has decided to make > >> explicit the clarification that the issue is just between > >> LMP-WDM and NTIP and not between LMP and NTIP. > > > > The whole point of LMP-WDM is to use an existing protocol to solve a > new problem rather than create a new protocol just for the sake of > creating a new one. If there is a technical argument against using > LMP for this problem, let's hear it! > > >> > >> Besides that I think that some of the arguments > >> advanced are: > >> > >> 1. The issue is not how many protocols need to be advanced. > > > > This is a significant issue. > > >> > >> 2. The choice of advancing a given protocol should be > >> influenced by whether it is deployed or likely to be > >> widely deployed. And this applies even in the case > >> of one single protocol. > >> > >> 3. No matter what protocol(s) is/are selected, > >> it is the market who makes the final decision. > >> > >> Hamid. > >> > >> At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: > >> > >> > [Osama] what is the limitation here? Are you saying > >> > having a simple design is a limitation? Not everything has > >> > to be complex. > >> > [Jonathan] Other DWDM vendors are not happy with the > >> > master-slave model. Also, the claim that NTIP is simple is > >> > an explicit assertion and you seem to be trying to make an > >> > implicit assertion that LMP is complex. > >> > > >> > >> On the master-slave issue. There is clearly some information that > >> the line system does not need. For example, I don't expect the > >> Link Characteristics need to be advertised from OXC to OLS. I > >> think this works fine within the context of LMP. > >> > >> You have made claims of complexity, but have never been able to > >> back them up with fact. > >> > >> > Given the CR-LDP fiasco in MPLS, it was clearly stated by > >> > the ADs and > >> > Working Group chairs in Minnesota that only one protocol > >> > will progress in > >> > the IETF. > >> > > >> > [Osama] I don't understand why CR-LDP and RSVP-TE have been > >> > brought to this discussion. This is a completely different > >> > situation. LMP hasn't seen the wide deployment that RSVP-TE > >> > has. The example is inadequate. > >> > > >> > [Jonathan] CR-LDP and RSVP-TE were both being developed > >> > prior to either one of them being widely deployed. The > >> > effort involved in developing 2 protocols concurrently to do > >> > the same thing is widely perceived as being counter > >> > productive. > >> > > >> > >> Given the choice between specifying and implementing two protocols > >> that do basically the same thing and one, I think the choice > >> should be clear. > >> > >> Andre > > --------------5FAC6B0E9FA6E01440A67834 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NSG - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------5FAC6B0E9FA6E01440A67834-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 15:14:49 -0700 Date: Wed, 25 Jul 2001 15:11:49 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107252211.PAA00876@kummer.juniper.net> To: BRaja@tellium.com, ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi Bala, > I would also like to add my two cents on these > points as an OXC vendor: Thanks, Bala for your perspective, both as an OXC vendor and as a non-author :-) Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:54:40 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040401982413@mail1.tellium.com> From: Bala Rajagopalan To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 17:54:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti: Thanks for distilling the issues into the 3 bullet items. I would also like to add my two cents on these points as an OXC vendor: > a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol. > I think both choices have pitfalls. LMP-WDM: First, LMP and LMP-WDM serve two different purposes. One may exist without the other. Indeed, for a WDM vendor, LMP-WDM will be a new protocol to implement. If they balk, I can't unilaterally choose LMP-WDM on the OXC side. Also, my experience so far has been that neighbor discovery based on LMP is not simple to realize in transparent switches, the main candidate for OLI. So, the question of LMP-WDM as an extension of LMP (as it currently stands) may be moot. NTIP: The present definition does not provide for neighbor discovery, a function required under OLI. Is another protocol required for this? If so, the value of NTIP is diluted. So, I think a case can be made for NTIP only if the neighbor disc. function is taken out of OLI. Similarly, a rather strong case for LMP-WDM can be made if the LMP neighbor disc. functionality could be simplified. I would personally prefer the second option since it provides a complete package (if there is any all-optical vendor out there who has got LMP neighbor discovery running, send me email :-) ). > > b) Two protocols vs. one. > One. But one that is useful in practice. > > c) The model: master-slave vs. peer. > Both LMP-WDM and NTIP can operate in the request-response mode. I don't see this as an issue. > > d) The transport protocol: TCP or raw over IP. > No big deal either way. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:21:37 -0700 Message-ID: From: "Bilel Jamoussi" To: "'John Drake'" , "'Andre Fredette'" , "Osama Aboul-Magd" Cc: "'Jonathan Lang'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 17:19:59 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1154F.8F906850" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1154F.8F906850 Content-Type: text/plain; charset="iso-8859-1" John, apology accepted. the slideware comment is in reference to the "more flexible model" of products vs product limitations -- not NTIP nor LMP-WDM. > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, July 25, 2001 5:06 PM To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; John Drake; 'Andre Fredette'; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface Bilel, I'm awfully sorry, I was just teasing you. You had started things with your assertion that LMP-WDM was slideware, but you're right, it was beneath me. Incidentally, I think your note might have had more credibility if you'd sent it privately. Thanks, John -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Wednesday, July 25, 2001 1:48 PM To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface However, NTIP addresses an immediate need and does not HAVE to be based on LMP. [John Drake] Well, there is a immediate need for a protocol that can support the OLI. However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. [Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! try to stay professional ------_=_NextPart_001_01C1154F.8F906850 Content-Type: text/html; charset="iso-8859-1"
John, apology accepted.
 
the slideware comment is in reference to the "more flexible model" of products vs product limitations -- not NTIP nor LMP-WDM.
 
> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers.
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, July 25, 2001 5:06 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; John Drake; 'Andre Fredette'; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; 'ccamp@ops.ietf.org'
Subject: RE: Optical Link Interface

Bilel,
 
I'm awfully sorry, I was just teasing you.  You had started things with your assertion that LMP-WDM was slideware, but you're right, it was beneath me.
 
Incidentally, I think your note might have had more credibility if you'd sent it privately. 
 
Thanks,
 
John 
-----Original Message-----
From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 1:48 PM
To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org'
Subject: RE: Optical Link Interface

 
However, NTIP addresses an immediate need and does not HAVE to be based on LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.  However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! 
try to stay professional
 
 
 
------_=_NextPart_001_01C1154F.8F906850-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:12:46 -0700 Date: Wed, 25 Jul 2001 17:12:10 -0400 From: Vijay Gill To: Kireeti Kompella cc: , Subject: RE: Optical Link Interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Jul 2001, Kireeti Kompella wrote: > CR-LDP) which is just an extension of LMP (read LDP) which nobody > needs anyway (read "TE is the only MPLS app"). Such is life ... > > > The (I)SPs > > that deployed it did not have a choice from their vendors. > > Guilty as charged. We gave them black model Ts, and they liked them. > They didn't ask for any other colors, and aren't asking now, apart > from idle curiosity. Having been there in the middle of this, I can attest to it that if we (the isp's selecting the signalling) felt that CR-LDP was a good enough solution, we'd have asked our vendors for it. However, the protocol evolution at the time was scary enough with so many cooks that the simple and fairly straightforward RSVP-TE process was very appealing. > > market prefers competing solutions to get the best of breed. > > All the ISP folks that I know who had to make a choice say that > the process of choosing is mostly non-technical, and very much a > big pain. In general, best of breed solutions tend to invoke stupendous amounts of pain as we try and integrate the backends. > The data I have indicates that the market wants competing > implementations of the same standard, not competing standards. That's > where the real value of "best of breed" lies. Precisely. Well said, Kireeti. /vijay Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:11:02 -0700 Message-ID: <3B5F35BE.8F1A1D26@nayna.com> Date: Wed, 25 Jul 2001 14:10:22 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Optical Link Interface Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: My few cents .. being involved in these discussions. Kireeti Kompella wrote: > > > c) The model: master-slave vs. peer. > > This is the key debate (in my opinion). Is LMP-WDM a "natural > extension of LMP", as Andre says; or is the master-slave model > more appropriate in this context, as Osama says? > The issue here is who has the control over which resource. The OXCs have control over the links and link bundles, and the DWDMs have the control over the fault reporting behaviour, the monitoring (may not be in the first release of the requirements) and the mapping of logical nature of the links and link bundles to the physical resources. In my opinion there are and there will be DWDM and OXC boxes which will not be capable of doing all the required features (as mentioned in the above paragraph). This leads to negotiation of features (or capabilities) between the two. Hence I feel this protocol LMP-DWDM or NTIP should be a peer-to-peer protocol. > > d) The transport protocol: TCP or raw over IP. > > Does the reliability of using TCP as transport offer a real > advantage in this context? Or do the complications of > managing failover with TCP outweigh this benefit? > > The main goal of these protocols is to report a failure as quickly as possible. A failure typically effect multiple links. Another observation is that the two elements (DWDM and OXC) need not be immediate neighbors. They can go through DCN. But in either case the amount of traffic in the control plane may not cause packet losses. With these two observations I feel that TCP is an over kill. Cheers, sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:06:30 -0700 Message-ID: From: John Drake To: 'Bilel Jamoussi' , John Drake , 'Andre Fredette' , Osama Aboul-Magd Cc: Jonathan Lang , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 14:05:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1154D.8F752A10" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1154D.8F752A10 Content-Type: text/plain; charset="iso-8859-1" Bilel, I'm awfully sorry, I was just teasing you. You had started things with your assertion that LMP-WDM was slideware, but you're right, it was beneath me. Incidentally, I think your note might have had more credibility if you'd sent it privately. Thanks, John -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Wednesday, July 25, 2001 1:48 PM To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface However, NTIP addresses an immediate need and does not HAVE to be based on LMP. [John Drake] Well, there is a immediate need for a protocol that can support the OLI. However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. [Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! try to stay professional ------_=_NextPart_001_01C1154D.8F752A10 Content-Type: text/html; charset="iso-8859-1"
Bilel,
 
I'm awfully sorry, I was just teasing you.  You had started things with your assertion that LMP-WDM was slideware, but you're right, it was beneath me.
 
Incidentally, I think your note might have had more credibility if you'd sent it privately. 
 
Thanks,
 
John 
-----Original Message-----
From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 1:48 PM
To: 'John Drake'; 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org'
Subject: RE: Optical Link Interface

 
However, NTIP addresses an immediate need and does not HAVE to be based on LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.  However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! 
try to stay professional
 
 
 
------_=_NextPart_001_01C1154D.8F752A10-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:05:22 -0700 Date: Wed, 25 Jul 2001 14:04:17 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107252104.OAA29850@kummer.juniper.net> To: jamoussi@nortelnetworks.com Subject: RE: Optical Link Interface Cc: ccamp@ops.ietf.org Hi Bilel, > [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS > applications. The market has settled on RSVP-TE in ONE of the many MPLS > applications -- namely Traffic Engineering of an IP network -- It's irrelevant what application RSVP-TE fits in. RSVP-TE and CR-LDP do the same thing in slightly different ways. In an ideal world, CR-LDP as an extension of LDP would have been the way to go. It's funny that you should be arguing on the other side now -- let's do NTIP (read RSVP-TE) instead of LMP-WDM (read CR-LDP) which is just an extension of LMP (read LDP) which nobody needs anyway (read "TE is the only MPLS app"). Such is life ... > The (I)SPs > that deployed it did not have a choice from their vendors. Guilty as charged. We gave them black model Ts, and they liked them. They didn't ask for any other colors, and aren't asking now, apart from idle curiosity. > Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The > market prefers competing solutions to get the best of breed. All the ISP folks that I know who had to make a choice say that the process of choosing is mostly non-technical, and very much a big pain. The data I have indicates that the market wants competing implementations of the same standard, not competing standards. That's where the real value of "best of breed" lies. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 14:02:28 -0700 Date: Wed, 25 Jul 2001 17:01:47 -0400 From: Vijay Gill To: Bilel Jamoussi cc: "'John Drake'" , "'Andre Fredette'" , Osama Aboul-Magd , "'Jonathan Lang'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Jul 2001, Bilel Jamoussi wrote: > > > However, NTIP addresses an immediate need and does not HAVE to be based on > LMP. > [John Drake] > Well, there is a immediate need for a protocol that can support the OLI. > However, as you pointed out, since NTIP is slideware, it can't be an > immediate solution to that immediate need. > > [Bilel Jamoussi] John, you have a bad reputation of putting words in > people's mouths -- Don't use that style with me!! > try to stay professional Folks, lets try and keep this clean please. Removing co-chair hat. >From an operators perspective, I'd much rather that my vendors (and the coders who have to code these protocols up), concentrate on implementation and maintenance of fewer protocols. This tends to make the code robust and the more robust code is (and we are all aware of the state of the software in the internet), the fewer pages. The fewer pages I get, the happier I am. The implementors have spoken on the NTIP vs LMP-DWDM, and as an operator, I _will_ be spending money where I feel the most comfortable, and as of now, I'm tending towards the implementors who think that extension of LMP is easier for them than writing up NTIP from scratch. Hat-on. So lets try to quickly focus on the resolution of this issue. We've been bickering back and forth over this for far too long. thank you /vijay Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:58:29 -0700 From: "manoj juneja" To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE Date: Wed, 25 Jul 2001 13:57:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Tom, I am referring to the latest GMPLS signalling drafts. http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt Lou Berger has sent these drafts on ccamp mailing list. Regards, manoj. >From: "Thomas D. Nadeau" >To: "manoj juneja" , ccamp@ops.ietf.org >Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to >RSVP-TE >Date: Wed, 25 Jul 2001 16:25:40 -0400 > > > Which "GMPLS drafts" are you referring to? > > --Tom > >> I have a doubt related to recently included AdminStatus object in >>GMPLS drafts. It states two reasons for including this object. In Ist >>case, the usage of this object by ingress node in non-refresh path >>message or by transit or egress node in the notify message before >>deleting the LSP is fine. Is this to supress the alarm generation by >>optical nodes as loss of light will propagate faster than the tear down >>signalling messages (Path/Resv Tear? >>Can someone please explain me other reason to include this object in >>PATH/RESV messages ? Is the use of this procedure only applicable prior to >>LSP deletion ? >> >>Regards, >>manoj. >> >> >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp >> > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:50:52 -0700 Message-ID: From: "Bilel Jamoussi" To: "'John Drake'" , "'Andre Fredette'" , "Osama Aboul-Magd" Cc: "'Jonathan Lang'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 16:48:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1154B.18ECD7F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1154B.18ECD7F0 Content-Type: text/plain; charset="iso-8859-1" However, NTIP addresses an immediate need and does not HAVE to be based on LMP. [John Drake] Well, there is a immediate need for a protocol that can support the OLI. However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. [Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! try to stay professional ------_=_NextPart_001_01C1154B.18ECD7F0 Content-Type: text/html; charset="iso-8859-1"
 
However, NTIP addresses an immediate need and does not HAVE to be based on LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.  However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. 
 
[Bilel Jamoussi] John, you have a bad reputation of putting words in people's mouths -- Don't use that style with me!! 
try to stay professional
 
 
 
------_=_NextPart_001_01C1154B.18ECD7F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:40:02 -0700 Date: Wed, 25 Jul 2001 13:39:16 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107252039.NAA29684@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi, This email is as a router vendor/implementor. The issues (so far) are: a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol. Subject to (c) below, I much prefer having to implement LMP (which I will have to) and add on the features needed for the OLI, rather than implement two different protocols. The rationale is the same as was used when deciding to extend link state IGPs with TE information rather than do a new TE link state flooding protocol, or to do GMPLS as an extension of MPLS rather than develop a new optical signaling protocol. b) Two protocols vs. one. One. c) The model: master-slave vs. peer. I'm not qualified to speak here; this is the domain of the optical gurus. However, I'll make two tangential points. The first is that the answer seems to depend on the architecture of the component systems, which probably indicates that the protocol should do both. The second is a piece of generic wisdom (?) that it is generally easier to add bells onto a peer-oriented protocol to deal with the master-slave case than to add whistles to a master-slave protocol to make it work in the peer case. d) The transport protocol: TCP or raw over IP. It is my understanding that the PXC-WDM link is usually one IP hop; it seems that TCP is an overkill in that case. Also, building failover capability for TCP-based protocols is rather more challenging. (Side note: both protocols can be made to work either way, so this is not so much of an NTIP-LMP_WDM issue as much as "what transport should OLI use?") Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:37:42 -0700 Message-ID: From: John Drake To: 'Bilel Jamoussi' , 'Andre Fredette' , Osama Aboul-Magd Cc: Jonathan Lang , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 13:36:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11549.73284760" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11549.73284760 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Wednesday, July 25, 2001 1:22 PM To: 'Andre Fredette'; Osama Aboul-Magd Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface Andre, it's not that simple. You are not "using" LMP, you are extending LMP to become a different protocol WDM-LMP. [John Drake] This is simply not true. There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To Come) -- I believe LMP fits here and the OLI solution should not be based on LMP. [John Drake] This is just rant However, NTIP addresses an immediate need and does not HAVE to be based on LMP. [John Drake] Well, there is a immediate need for a protocol that can support the OLI. However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. Bilel. -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 2:11 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C11549.73284760 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 1:22 PM
To: 'Andre Fredette'; Osama Aboul-Magd
Cc: 'Jonathan Lang'; 'ccamp@ops.ietf.org'
Subject: RE: Optical Link Interface

Andre, it's not that simple. You are not "using" LMP, you are extending LMP to become a different protocol WDM-LMP.
[John Drake] 
This is simply not true.     
 
There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To Come) -- I believe LMP fits here and the OLI solution should not be based on LMP.
[John Drake] 
This is just rant
 
 
However, NTIP addresses an immediate need and does not HAVE to be based on LMP.
[John Drake] 
Well, there is a immediate need for a protocol that can support the OLI.  However, as you pointed out, since NTIP is slideware, it can't be an immediate solution to that immediate need. 
 
Bilel.
-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.


Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
------_=_NextPart_001_01C11549.73284760-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:23:24 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Andre Fredette'" , "Osama Aboul-Magd" Cc: "'Jonathan Lang'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 16:22:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11547.772B9210" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11547.772B9210 Content-Type: text/plain; charset="iso-8859-1" Andre, it's not that simple. You are not "using" LMP, you are extending LMP to become a different protocol WDM-LMP. There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To Come) -- I believe LMP fits here and the OLI solution should not be based on LMP. However, NTIP addresses an immediate need and does not HAVE to be based on LMP. Bilel. -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 2:11 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C11547.772B9210 Content-Type: text/html; charset="iso-8859-1"
Andre, it's not that simple. You are not "using" LMP, you are extending LMP to become a different protocol WDM-LMP.
 
There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To Come) -- I believe LMP fits here and the OLI solution should not be based on LMP.
 
However, NTIP addresses an immediate need and does not HAVE to be based on LMP.
 
Bilel.
-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.


Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
------_=_NextPart_001_01C11547.772B9210-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:21:19 -0700 Message-Id: <4.3.2.7.2.20010725162446.02103250@bucket.cisco.com> Date: Wed, 25 Jul 2001 16:25:40 -0400 To: "manoj juneja" , ccamp@ops.ietf.org From: "Thomas D. Nadeau" Subject: Re: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Which "GMPLS drafts" are you referring to? --Tom > I have a doubt related to recently included AdminStatus object in > GMPLS drafts. It states two reasons for including this object. In Ist > case, the usage of this object by ingress node in non-refresh path > message or by transit or egress node in the notify message before > deleting the LSP is fine. Is this to supress the alarm generation by > optical nodes as loss of light will propagate faster than the tear down > signalling messages (Path/Resv Tear? >Can someone please explain me other reason to include this object in >PATH/RESV messages ? Is the use of this procedure only applicable prior to >LSP deletion ? > >Regards, >manoj. > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:18:57 -0700 Date: Wed, 25 Jul 2001 13:16:43 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107252016.NAA29549@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: RE: Optical Link Interface Hi, I wade into this discussion with trepidation. I'll send out two mails. This one is as a CCAMP co-chair, and attempts to distill the issues so far. This plane is the LMP-DWM vs. NTIP plane. If you have other travel plans, this would be an excellent time to disembark. Both protocols satisfy the requirements. Thanks to the authors of the requirements draft to reach agreement on this! The issues (so far) are: a) LMP-WDM as an extension of LMP vs. NTIP as a new protocol. LMP-WDM is an extension of LMP, a reasonably mature protocol. NTIP is a new protocol. These facts may mean it would take less time to standardize LMP-WDM than NTIP. How relevant this is, I can't say. b) Two protocols vs. one. NTIP and LMP-WDM are two protocols with one purpose. I don't want two protocols with one purpose. (As far as I understand, the ADs and the TA don't want two protocols with one purpose.) To make this crystal clear: LMP & NTIP is acceptable. LMP & LMP-WDM is acceptable. LMP-WDM & NTIP (with or without LMP) is not. "Let the market decide" is a final resort ... let's try not to go there. c) The model: master-slave vs. peer. This is the key debate (in my opinion). Is LMP-WDM a "natural extension of LMP", as Andre says; or is the master-slave model more appropriate in this context, as Osama says? d) The transport protocol: TCP or raw over IP. Does the reliability of using TCP as transport offer a real advantage in this context? Or do the complications of managing failover with TCP outweigh this benefit? An aside: the issue of deployment keeps coming up. The IETF does not deploy protocols: it proposes standards. Ideally, the proposed standards meet requirements (from service providers!), which hopefully indicates a willingness to deploy those proposals. Deployment comes into play when considering moving a proposed standard to standard (and a standard to historic) -- but we are far from there. If deployment was a criterion, the IETF would have killed CR-LDP a long time ago, making the world a sadder, duller place, but making my life (as implementor, draft writer and WG chair) much simpler. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:18:06 -0700 Message-ID: From: John Drake To: 'Bilel Jamoussi' , Jonathan Lang , Osama Aboul-Magd , 'Andre Fredette' , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 13:15:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11546.95F91E70" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11546.95F91E70 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com] Sent: Wednesday, July 25, 2001 1:05 PM To: 'Jonathan Lang'; Osama Aboul-Magd; 'Andre Fredette'; 'ccamp@ops.ietf.org' Subject: RE: Optical Link Interface > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. [Bilel Jamoussi] The model can be very flexible when it's at the slideware stage. [John Drake] Are you discussing NTIP? > - To link with other standards bodies, as far as I know T1X1, where the optical knowledge > exists, is yet to arrive to a definition of this interface. More contributions are > solicited to better understand its need and applications. Given that, I'd like to > understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 > messages were posted to the mailing list and mostly from authors of the OLI requirements > draft. > - I don't see harm in having two protocols. The market made its decisions on the examples > you mentioned, and I am sure it will happen again in this case. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been talking to view this as a very healthy and competitive approach to have a scalable and robust solution(s). Traffic Engineering an IP network (the only application where RSVP-TE is deployed today) is a very narrow segment of the MPLS/GMPLS applications market. Bilel. ------_=_NextPart_001_01C11546.95F91E70 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
 
-----Original Message-----
From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 1:05 PM
To: 'Jonathan Lang'; Osama Aboul-Magd; 'Andre Fredette'; 'ccamp@ops.ietf.org'
Subject: RE: Optical Link Interface


> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers.
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

[Bilel Jamoussi] The model can be very flexible when it's at the slideware stage.

[John Drake] Are you discussing NTIP? 

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge
> exists, is yet to arrive to a definition of this interface. More
contributions are
> solicited to better understand its need and applications. Given that, I'd
like to
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5
> messages were posted to the mailing list and mostly from authors of the
OLI requirements
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.

[Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been talking to view this as a very healthy and competitive approach to have a scalable and robust solution(s). Traffic Engineering an IP network (the only application where RSVP-TE is deployed today) is a very narrow segment of the MPLS/GMPLS applications market.

Bilel.
 

------_=_NextPart_001_01C11546.95F91E70-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:08:28 -0700 From: Andre Fredette To: Bilel Jamoussi Cc: 'John Drake' , Osama Aboul-Magd , "'ccamp@ops.ietf.org'" Message-Id: <5.1.0.14.2.20010725160047.03c08e98@mailbox> Date: Wed, 25 Jul 2001 16:05:24 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_25363020==_.ALT" --=====================_25363020==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bilel, In my experience, the market prefers a single standard with competing implementations. To quote Yakov from a recent post to the MPLS list, "The fact that in the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is a bug, and not a feature.", and "The same applies for MPLS signalling (CR-LDP vs RSVP)." Andre At 03:55 PM 7/25/2001 -0400, Bilel Jamoussi wrote: Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The market prefers competing solutions to get the best of breed. --=====================_25363020==_.ALT Content-Type: text/html; charset="us-ascii" Bilel,

In my experience, the market prefers a single standard with competing implementations.

To quote Yakov from a recent post to the MPLS list, "The fact that in the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is a bug, and not a feature.", and "The same applies for MPLS signalling (CR-LDP vs RSVP)."

Andre

At 03:55 PM 7/25/2001 -0400, Bilel Jamoussi wrote:
Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The market prefers competing solutions to get the best of breed.
--=====================_25363020==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:07:28 -0700 Message-ID: From: "Bilel Jamoussi" To: "'Jonathan Lang'" , "Osama Aboul-Magd" , "'Andre Fredette'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 16:04:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11545.091FCBD0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11545.091FCBD0 Content-Type: text/plain; charset="iso-8859-1" > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. [Bilel Jamoussi] The model can be very flexible when it's at the slideware stage. > - To link with other standards bodies, as far as I know T1X1, where the optical knowledge > exists, is yet to arrive to a definition of this interface. More contributions are > solicited to better understand its need and applications. Given that, I'd like to > understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 > messages were posted to the mailing list and mostly from authors of the OLI requirements > draft. > - I don't see harm in having two protocols. The market made its decisions on the examples > you mentioned, and I am sure it will happen again in this case. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Bilel Jamoussi] There is no fiasco -- The ISPs and carriers I have been talking to view this as a very healthy and competitive approach to have a scalable and robust solution(s). Traffic Engineering an IP network (the only application where RSVP-TE is deployed today) is a very narrow segment of the MPLS/GMPLS applications market. Bilel. ------_=_NextPart_001_01C11545.091FCBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

> - The issue is not really LMP vs TCP. NTIP and = LMP-WDM differ in the model
itself. Your
> choice to use LMP to run LMP-WDM on top of it = forced you to treat the PXC
and LS as peers.
> NTIP treats PXC-LS relationship as = master-slave. Non peer relationship
suits this
> interface better.
I understand this limitation works for your product, = but other WDM vendors
have requested a more flexible model.

[Bilel Jamoussi] The model can be very flexible when = it's at the slideware stage.


> - To link with other standards bodies, as far as = I know T1X1, where the
optical knowledge
> exists, is yet to arrive to a definition of = this interface. More
contributions are
> solicited to better understand its need and = applications. Given that, I'd
like to
> understand the rationale for the "rough = consensus" reached at CCAMP
mailing list. Only 4-5
> messages were posted to the mailing list and = mostly from authors of the
OLI requirements
> draft.
> - I don't see harm in having two protocols. The = market made its decisions
on the examples > you mentioned, and I am sure it = will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly = stated by the ADs and
Working Group chairs in Minnesota that only one = protocol will progress in
the IETF.

[Bilel Jamoussi] There is no fiasco -- The ISPs and = carriers I have been talking to view this as a very healthy and = competitive approach to have a scalable and robust solution(s). Traffic = Engineering an IP network (the only application where RSVP-TE is = deployed today) is a very narrow segment of the MPLS/GMPLS applications = market.

Bilel.
 

------_=_NextPart_001_01C11545.091FCBD0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 13:06:00 -0700 From: Andre Fredette To: Hamid Ould-Brahim Cc: Osama Aboul-Magd , Jonathan Lang , ccamp Message-Id: <5.1.0.14.2.20010725154949.0309cd88@mailbox> Date: Wed, 25 Jul 2001 15:59:14 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24992897==_.ALT" --=====================_24992897==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote: Andre, Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. We went through that before and the WG has decided to make explicit the clarification that the issue is just between LMP-WDM and NTIP and not between LMP and NTIP. The whole point of LMP-WDM is to use an existing protocol to solve a new problem rather than create a new protocol just for the sake of creating a new one. If there is a technical argument against using LMP for this problem, let's hear it! Besides that I think that some of the arguments advanced are: 1. The issue is not how many protocols need to be advanced. This is a significant issue. 2. The choice of advancing a given protocol should be influenced by whether it is deployed or likely to be widely deployed. And this applies even in the case of one single protocol. 3. No matter what protocol(s) is/are selected, it is the market who makes the final decision. Hamid. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre --=====================_24992897==_.ALT Content-Type: text/html; charset="us-ascii" At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:
Andre,
 
Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.
 
Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.
 
We went through that before and the WG has decided to make
explicit the clarification that the issue is just between
LMP-WDM and NTIP and not between LMP and NTIP.

The whole point of LMP-WDM is to use an existing protocol to solve a new problem rather than create a new protocol just for the sake of creating a new one.  If there is a technical argument against using LMP for this problem, let's hear it!

 
Besides that I think that some of the arguments
advanced are:
 
1. The issue is not how many protocols need to be advanced.

This is a significant issue.

 
2. The choice of advancing a given protocol should be
   influenced by whether it is deployed or likely to be
   widely deployed. And this applies even in the case
   of one single protocol.
 
3. No matter what protocol(s) is/are selected,
   it is the market who makes the final decision.
 
Hamid.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
--=====================_24992897==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:58:11 -0700 Message-ID: From: "Bilel Jamoussi" To: "'John Drake'" , "Osama Aboul-Magd" , "'Andre Fredette'" , "'ccamp@ops.ietf.org'" Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 15:55:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11543.B1EA29B0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11543.B1EA29B0 Content-Type: text/plain; charset="iso-8859-1" [Osama] - I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case. [John Drake] The market has settled on RSVP-TE, so there's clearly an existence proof that that the market prefers a single solution [Bilel Jamoussi] John, you seem to have a very narrow view of MPLS applications. The market has settled on RSVP-TE in ONE of the many MPLS applications -- namely Traffic Engineering of an IP network -- The (I)SPs that deployed it did not have a choice from their vendors. Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The market prefers competing solutions to get the best of breed. Bilel. ------_=_NextPart_001_01C11543.B1EA29B0 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
[Osama]  - I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case.
[John Drake] The market has settled on RSVP-TE, so there's clearly an existence proof that that the market prefers a single solution 

[Bilel Jamoussi] John, you seem to have a very narrow view of MPLS applications. The market has settled on RSVP-TE in ONE of the many MPLS applications -- namely Traffic Engineering of an IP network -- The (I)SPs that deployed it did not have a choice from their vendors.

Also, the market has 2 routing protocols in the IGP: OSPF and IS-IS -- The market prefers competing solutions to get the best of breed.

Bilel.

 

------_=_NextPart_001_01C11543.B1EA29B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:52:01 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubt related to AdminStatus Object in GMPLS extentions to RSVP-TE Date: Wed, 25 Jul 2001 12:49:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a doubt related to recently included AdminStatus object in GMPLS drafts. It states two reasons for including this object. In Ist case, the usage of this object by ingress node in non-refresh path message or by transit or egress node in the notify message before deleting the LSP is fine. Is this to supress the alarm generation by optical nodes as loss of light will propagate faster than the tear down signalling messages (Path/Resv Tear? Can someone please explain me other reason to include this object in PATH/RESV messages ? Is the use of this procedure only applicable prior to LSP deletion ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:48:56 -0700 From: Andre Fredette To: Osama Aboul-Magd Cc: Jonathan Lang , ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010725153449.030ecb38@mailbox> Date: Wed, 25 Jul 2001 15:46:34 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24232704==_.ALT" --=====================_24232704==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Comments inline. At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote: Andre, This is a misrepresentation of my argument. My argument is: - LMP is at best optional. This is your opinion. The members of the CCAMP working group have decided that LMP is useful and needs to be specified. Not everyone is going to implement it. - Let's not try to force it on everyone. The way I read this is that you don't plan to implement LMP, so you want to make it harder for those that do? Therefore your argument to use LMP is not reasonable. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Wednesday, July 25, 2001 2:11 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre --=====================_24232704==_.ALT Content-Type: text/html; charset="us-ascii" Comments inline.

At 02:51 PM 7/25/2001 -0400, Osama Aboul-Magd wrote:
Andre,

This is a misrepresentation of my argument.
My argument is:
- LMP is at best optional.

This is your opinion.  The members of the CCAMP working group have decided that LMP is useful and needs to be specified.

Not everyone is going to implement it.
- Let's not try to force it on everyone.

The way I read this is that you don't plan to implement LMP, so you want to make it harder for those that do?


Therefore your argument to use LMP is not reasonable.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:

        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.

Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
--=====================_24232704==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:45:55 -0700 From: "Hamid Ould-Brahim" To: Andre Fredette , "Osama Aboul-Magd" Cc: Jonathan Lang , ccamp Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 15:40:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C11520.31C95760" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C11520.31C95760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Andre, Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. We went through that before and the WG has decided to make explicit the clarification that the issue is just between LMP-WDM and NTIP and not between LMP and NTIP. Besides that I think that some of the arguments advanced are: 1. The issue is not how many protocols need to be advanced. 2. The choice of advancing a given protocol should be influenced by whether it is deployed or likely to be widely deployed. And this applies even in the case of one single protocol. 3. No matter what protocol(s) is/are selected, it is the market who makes the final decision. Hamid. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------=_NextPart_000_003F_01C11520.31C95760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andre,
 
Osama,

[Note: I tried to trim this note down to the = key=20 arguments so that it is easier to follow.]

My main argument = (and I=20 believe it is shared by the rest of the LMP-WDM co-authors) is as=20 follows:
1. LMP exists.
2. LMP solves most of the OLI problems, =
3.=20 Therefore, let's use LMP. 
 
Osama's main argument is:
1. I don't think LMP should = exist. 
2. Therefore let's create a new protocol.

Given that the = members=20 of the working group have decided that LMP will be developed, I don't = think=20 Osama's argument is reasonable. 
 
We went through that before and the WG has decided to make=20
explicit the clarification that the = issue is just=20 between
LMP-WDM and NTIP and not=20 between LMP and NTIP. 
 
Besides that I think that some of the = arguments=20
advanced are:
 
1. The issue is not how many protocols=20 need to be advanced.
 
2. The choice of advancing a given protocol = should be=20
   influenced by = whether it is=20 deployed or likely to be
   widely = deployed. And=20 this applies even in the case
   of one single=20 protocol. 
 
3. No matter what protocol(s) is/are=20 selected,
   it is the = market who=20 makes the final decision.
 
Hamid. 

At 10:41 = AM=20 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what=20 is the limitation here? Are you saying having a simple design is a = limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the=20 master-slave model.  Also, the claim that NTIP is simple is = an=20 explicit assertion and you seem to be trying to make an implicit = assertion=20 that LMP is complex.

On the master-slave issue.  There is clearly some=20 information that the line system does not need.  For example, I = don't=20 expect the Link Characteristics need to be advertised from OXC to = OLS.  I=20 think this works fine within the context of LMP.

You have made = claims=20 of complexity, but have never been able to back them up with = fact.


Given the CR-LDP fiasco in MPLS, it was clearly stated by the = ADs=20 and
Working Group chairs in Minnesota that only one protocol will = progress=20 in
the IETF.=20
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been = brought to=20 this discussion. This is a completely different situation. LMP = hasn't seen=20 the  wide deployment that RSVP-TE has. The example is=20 inadequate. =

[Jonathan] CR-LDP and RSVP-TE were both being developed prior = to=20 either one of them being widely deployed.  The effort = involved in=20 developing 2 protocols concurrently to do the same thing is widely = perceived as being counter productive. =

Given the choice between specifying and implementing two=20 protocols that do basically the same thing and one, I think the choice = should=20 be clear.

Andre
------=_NextPart_000_003F_01C11520.31C95760-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:27:05 -0700 From: "manoj juneja" To: eric.gray@sandburst.com, skatukam@cisco.com Cc: ccamp@ops.ietf.org, Eric.Mannie@ebone.com Bcc: Subject: Re: Label Set and Suggested Label Date: Wed, 25 Jul 2001 12:26:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Please ignore the previous mail (because of some typo errors). Is label set really useful in TDM domain ? I think if the upstream node wants to select only one label in the label set, it can very well use the explicit label control procedure. What are other benefits of having label set in TDM domain ? I can very well understand the use of label set for LSC and FSC interfaces where label ranges make sense. Do label ranges make sense in TDM domain ? Regards, manoj. >From: Eric Gray >To: Suresh Katukam >CC: ccamp@ops.ietf.org >Subject: Re: Label Set and Suggested Label >Date: Mon, 02 Jul 2001 09:44:00 -0400 > >Suresh, > > Unfortunately, the current wording is: > >"There are four cases where a Label Set is useful in the optical domain." > >It is arguable that your examples are more properly in the TDM domain, >but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not >seem to leave much room for generalizing the label set in this way. It >should probably say either that these are examples that apply to the >optical domain (other uses may exist for other domains) or - better - >still it should simply state these as a few examples and leave it at that. > > There is nothing to be gained by guessing what the authors meant - >they must make it clear. > >-- >Eric Gray > >You wrote: > > > Manoj, > > > > > In the GMPLS drafts, it is mentioned that the use of label set > > > is in the following cases : > > > > > > a) End equipment is only capable of transmitting and > > > receiving on a small set of wavelengths. > > > b) There are sequence of interfaces which can't support > > > wavelength conversion. > > > c) It is desireable to limit the amount of wavelength > > > conversion to reduce the distortion on the optical > > > signals. > > > d) Two ends of a link support different sets of >wavelengths. > > > > > > All the above four points are valid only in case LSP encoding type is > > > lambda. Does this mean if a label set is received in cases where LSP > > > encoding type is other than Lambda, it should be ignored or considered > > > protocol error ? > > > > I am not sure whether it is the intention of GMPLS authors to list > > all possible scenerios under which a label set is used. There are > > other scenerios under which label set can be used. In TDM, for example, > > one may want to use same time slot (for BLSRs) assigned along the > > entire BLSR segment. In such a scenerio, BLSR headend lists all >available > > labels and forwards the PATH message. Each node in BLSR knows what > > label to use when it receives a RESV message. > > > > There may be other reasons too. In anycase, you should not consider > > that to be a protocol error. > > > > Thanks, > > Suresh > > > > > > What about the suggested Label ? Is it also defined to take care of > > > specific LSP encoding type ? > > > > > > Please Clarify. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:09:35 -0700 From: "manoj juneja" To: eric.gray@sandburst.com, skatukam@cisco.com Cc: ccamp@ops.ietf.org, Eric.Mannie@ebone.com Bcc: Subject: Re: Label Set and Suggested Label Date: Wed, 25 Jul 2001 12:08:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Is label set realy useful in TDM domain ? I think if the upstream node wants to select only one label in the label set, it can very well use the explicit label control procedure. What are other benefits of having label set in TDM domain ? I can very understand the use of label set for LSC and FSC interfaces where label ranges make sense. Regards, manoj. >From: Eric Gray >To: Suresh Katukam >CC: ccamp@ops.ietf.org >Subject: Re: Label Set and Suggested Label >Date: Mon, 02 Jul 2001 09:44:00 -0400 > >Suresh, > > Unfortunately, the current wording is: > >"There are four cases where a Label Set is useful in the optical domain." > >It is arguable that your examples are more properly in the TDM domain, >but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not >seem to leave much room for generalizing the label set in this way. It >should probably say either that these are examples that apply to the >optical domain (other uses may exist for other domains) or - better - >still it should simply state these as a few examples and leave it at that. > > There is nothing to be gained by guessing what the authors meant - >they must make it clear. > >-- >Eric Gray > >You wrote: > > > Manoj, > > > > > In the GMPLS drafts, it is mentioned that the use of label set > > > is in the following cases : > > > > > > a) End equipment is only capable of transmitting and > > > receiving on a small set of wavelengths. > > > b) There are sequence of interfaces which can't support > > > wavelength conversion. > > > c) It is desireable to limit the amount of wavelength > > > conversion to reduce the distortion on the optical > > > signals. > > > d) Two ends of a link support different sets of >wavelengths. > > > > > > All the above four points are valid only in case LSP encoding type is > > > lambda. Does this mean if a label set is received in cases where LSP > > > encoding type is other than Lambda, it should be ignored or considered > > > protocol error ? > > > > I am not sure whether it is the intention of GMPLS authors to list > > all possible scenerios under which a label set is used. There are > > other scenerios under which label set can be used. In TDM, for example, > > one may want to use same time slot (for BLSRs) assigned along the > > entire BLSR segment. In such a scenerio, BLSR headend lists all >available > > labels and forwards the PATH message. Each node in BLSR knows what > > label to use when it receives a RESV message. > > > > There may be other reasons too. In anycase, you should not consider > > that to be a protocol error. > > > > Thanks, > > Suresh > > > > > > What about the suggested Label ? Is it also defined to take care of > > > specific LSP encoding type ? > > > > > > Please Clarify. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 12:00:27 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04453138@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: John Drake , "'Andre Fredette'" Cc: Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 14:58:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1153B.D908C950" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1153B.D908C950 Content-Type: text/plain; charset="iso-8859-1" John, I think it is unacceptable to misrepresent private conversations. Please stick to the issues. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, July 25, 2001 2:37 PM To: 'Andre Fredette'; Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface As an aside, the LMP-WDM and NTIP authors did have several phone conferences prior to the last IETF, and the NTIP authors indicated that folding the contents of LMP-WDM draft into the NTIP draft would be an acceptable solution to them. Presumably this would allow it to be called NTIP. Since then, they've also indicated that the LMP-WDM protocol is fine, but it can't have the letters LMP in its name. Thanks, John -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 11:11 AM To: 'Osama Aboul-Magd' Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C1153B.D908C950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

J= ohn,

<= ![if = !supportEmptyParas]> 

=

I= think it is unacceptable to misrepresent private conversations. Please stick to = the issues.

<= ![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: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, July = 25, 2001 2:37 PM
To: 'Andre Fredette'; = Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

 

As an aside, the LMP-WDM and = NTIP authors did have several phone conferences prior to the last IETF, and the NTIP = authors indicated that folding the contents of LMP-WDM draft into the NTIP = draft would be an acceptable solution to them.  Presumably this would allow it = to be called NTIP.

 Since then, they've also = indicated that the LMP-WDM protocol is fine, but it can't have the letters LMP in = its name.

Thanks,=

John =

-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July = 25, 2001 11:11 AM
To: 'Osama = Aboul-Magd'
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it = is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will = be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: =

     &nb= sp;  [Osama] what is the limitation here? Are you saying having = a simple design is a limitation? Not everything has to be complex. =

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an = explicit assertion and you seem to be trying to make an implicit assertion that = LMP is complex.


On the master-slave issue.  There is clearly some information that = the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think = this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back = them up with fact.



Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs = and

Working Group chairs in Minnesota that only one protocol will progress = in

the IETF. = =

     &nb= sp; 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this = discussion. This is a completely different situation. LMP hasn't seen the  = wide deployment that RSVP-TE has. The example is = inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed = prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely = perceived as being counter productive. =


Given the choice between specifying and implementing two protocols that = do basically the same thing and one, I think the choice should be = clear.

Andre

------_=_NextPart_001_01C1153B.D908C950-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:56:08 -0700 content-class: urn:content-classes:message Subject: RE: Queries regarding LMP. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jul 2001 14:55:14 -0400 Message-ID: Thread-Topic: Queries regarding LMP. Thread-Index: AcEVJ72uRbsPRECxSDmI7JM+rxRHqQAEplDg From: "Martin Dubuc" To: "Zhi-Wei Lin" Cc: , , , Zhi-Wei, As soon as there are O-O-O nodes (all optical) inside the network, there needs to be a procedure for fault isolation, regardless if there are OEO nodes at the edge. LMP provides such fault isolation mechanism. If the fault isolation procedure in LMP is not used, the vendor has to come up with its own proprietary mechanism. For SONET gears, as you point out, there is no need for this procedure since this technology has mechanisms to deal with fault isolation. Martin -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, July 25, 2001 12:35 PM To: Martin Dubuc Cc: rajesh@tejasnetworks.com; mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; azinin@cisco.com; ccamp@ops.ietf.org Subject: Re: Queries regarding LMP. Hi Martin, comments in-line Martin Dubuc wrote: >=20 > Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of > control and data link health. To determine whether LMP is useful or not, > one has to look at the operational aspect of product deployment and > maintenance, i.e. what tools the vendor wants to implement to facilitate > provisioning and maintenance of their customers network. In a small > network, a vendor may be able to get away with manual configuration of > links. In an opaque network, it is also easy to pinpoint link failures. > However, in a truly optical network, there needs to be mechanisms to > isolate faults (which LMP provides). When you say "truly optical network", do you mean a network that has no O/E/O (no 3R) at all? or is there some 3R at the edge? As for mechanisms to isolate faults, I think this capability is already part of networks. For example, SONET has mechanisms such as trace identifiers, AIS/RDI signals, and tandem connection points for doing this. OTN (G.709) also has these defined. In addition, OTN has defined 6 flexible layers for TCM and 2 fixed layer for TCM (section and path).=20 I think LMP is not necessary for fault isolation, but it could be another mechanism that may be used (if one so chooses).=20 >=20 > Usefulness of LMP is not directly tied to use of link bundles. Link > bundles are mostly used to reduce the flooding of link information > generated by the routing protocol. >=20 > Q3) Destination address can be multicast or any valid IP address of > destination node (most likely the NodeID of the destination node). >=20 > -----Original Message----- > From: rajesh [mailto:rajesh@tejasnetworks.com] > Sent: Wednesday, July 25, 2001 1:59 AM > To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; > azinin@cisco.com > Subject: Queries regarding LMP. >=20 > Hi, >=20 > Have a few queries regd LMP. >=20 > Q1) Regd the applicability of LMP... >=20 > draft-many-gmpls-architecture-00.txt states that >=20 > " For instance, the traditional IP routing model assumes the > establishment of a routing adjacency over each link connecting two > adjacent nodes. Having such a large number of adjacencies is not > scalable at all. Each node needs to maintain each of its adjacencies > one by one, and link state routing information must be flooded in > the topology for each link. >=20 > To solve this issue the concept of bundling was introduced. > Moreover, the manual configuration and control of these links, even > if they are unnumbered, becomes totally impractical. The Link > Management Protocol (LMP) was specified to solve these problems. " >=20 > a) Can one assume that LMP makes sense ONLY in the case of a large > number of parallel links and link bundling... >=20 > and an implementation of GMPLS neednot have LMP if no link > bundling is used ?? >=20 > The above maybe the case when using lower end SONET ADM, > DXCs... >=20 > b) Under what other conditions would one require LMP (ie other than > link bundling) ? >=20 > Q2) Suppose one does NOT need to use LMP but then one needs to use > OSPF extensions to support TE > (draft-kompella-ospf-gmpls-extensions-01.txt) , >=20 > then one may need to do a correlation of Link Ids between 2 > TE nodes. >=20 > a) Is there a standard recommended way to do this correlation ?? >=20 > E.g OSPF - Link Local Signaling > or OSPF - link scope LSA ? >=20 > Q3) Section 9 of draft-ietf-mpls-lmp-02.txt says that LMP messages > are encoded as IP packets and also suggests protocol number > 140. >=20 > What would be the destination IP address of an LMP packet ?? >=20 > A multicast or is it got from an IGP ?? >=20 > Q4) In LMP, if a Link Id correlation has been done, and If the link ids >=20 > on one of the ends or both change... How is this change taken > into > account ?? >=20 > Eg for i =3D 1,2 > Port i, Node 1 connected to Port i, Node 2 >=20 > If one interchanges the connection then one has to recorrelate >=20 > the Link Id mappings.. >=20 > Thanks in advance, > Rajesh Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:55:47 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D02204040198240F@mail1.tellium.com> From: Bala Rajagopalan To: "'lyndon_ong@eudoramail.com'" Cc: rajesh@tejasnetworks.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Queries regarding LMP. Date: Wed, 25 Jul 2001 14:54:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello, > -----Original Message----- > From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com] > Hi, > >> By the same token, is there really a need for fast keep-alive > for all situations, esp. for in-band DCC control channels > where there is a link layer protocol in use that can monitor > control link health? Keep-alive is just further overhead in > that situation, especially when there may be hellos in the > signaling and routing protocols going on at the same time. For in-band DCC, the SONET/SDH procedures can help in detecting link down situation. However, a keep-alive also tells if the neighbor discovery process running is up or down. Perhaps the neighbor discovery Hello messages can be sent over a coarser time period. W.r.t routing protocols, the idea is not to create an IGP adjacency over each link (and hence no IGP hello over each link). Regards, Bala Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:53:17 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04453126@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Andre Fredette Cc: Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 14:51:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1153A.CFFD3950" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1153A.CFFD3950 Content-Type: text/plain; charset="iso-8859-1" Andre, This is a misrepresentation of my argument. My argument is: - LMP is at best optional. Not everyone is going to implement it. - Let's not try to force it on everyone. Therefore your argument to use LMP is not reasonable. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 2:11 PM To: Aboul-Magd, Osama [CAR:1A00:EXCH] Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C1153A.CFFD3950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A= ndre,

<= ![if = !supportEmptyParas]> 

=

T= his is a misrepresentation of my argument. My argument = is:

<= ![if = !supportEmptyParas]> 

=

-= LMP is at best optional. Not everyone is going to implement it. =

-= Let's not try to force it on everyone.

<= ![if !supportEmptyParas]> 

T= herefore your argument to use LMP is not = reasonable.

<= ![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: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July = 25, 2001 2:11 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

 

Osama,

[Note: I tried to trim this note down to the key arguments so that it = is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will = be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:=

     &nb= sp;  [Osama] what is the limitation here? Are you saying having = a simple design is a limitation? Not everything has to be complex. =

[Jonathan]  Other DWDM vendors are not happy with the = master-slave model.  Also, the claim that NTIP is simple is an explicit = assertion and you seem to be trying to make an implicit assertion that LMP is = complex. =


On the master-slave issue.  There is clearly some information that = the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think = this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back = them up with fact.



Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs = and

Working Group chairs in Minnesota that only one protocol will progress = in

the IETF. = =

     &nb= sp; 

[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this = discussion. This is a completely different situation. LMP hasn't seen the  = wide deployment that RSVP-TE has. The example is = inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed = prior to either one of them being widely deployed.  The effort involved in = developing 2 protocols concurrently to do the same thing is widely perceived as = being counter productive.


Given the choice between specifying and implementing two protocols that = do basically the same thing and one, I think the choice should be = clear.

Andre

------_=_NextPart_001_01C1153A.CFFD3950-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:38:21 -0700 Message-ID: From: John Drake To: 'Andre Fredette' , 'Osama Aboul-Magd' Cc: Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 11:36:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11538.C3719FC0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11538.C3719FC0 Content-Type: text/plain; charset="iso-8859-1" As an aside, the LMP-WDM and NTIP authors did have several phone conferences prior to the last IETF, and the NTIP authors indicated that folding the contents of LMP-WDM draft into the NTIP draft would be an acceptable solution to them. Presumably this would allow it to be called NTIP. Since then, they've also indicated that the LMP-WDM protocol is fine, but it can't have the letters LMP in its name. Thanks, John -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Wednesday, July 25, 2001 11:11 AM To: 'Osama Aboul-Magd' Cc: Jonathan Lang; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre ------_=_NextPart_001_01C11538.C3719FC0 Content-Type: text/html; charset="iso-8859-1"

As an aside, the LMP-WDM and NTIP authors did have several phone conferences prior to the last IETF, and the NTIP authors indicated that folding the contents of LMP-WDM draft into the NTIP draft would be an acceptable solution to them.  Presumably this would allow it to be called NTIP.

 Since then, they've also indicated that the LMP-WDM protocol is fine, but it can't have the letters LMP in its name.

Thanks,

John 

-----Original Message-----
From: Andre Fredette [mailto:fredette@photonex.com]
Sent: Wednesday, July 25, 2001 11:11 AM
To: 'Osama Aboul-Magd'
Cc: Jonathan Lang; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.


Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
------_=_NextPart_001_01C11538.C3719FC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:38:15 -0700 To: "Martin Dubuc" , "Zhi-Wei Lin" Date: Wed, 25 Jul 2001 11:36:49 -0700 From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 Cc: rajesh@tejasnetworks.com, mpls@UU.NET, jplang@calient.net, kireeti@juniper.net, azinin@cisco.com, ccamp@ops.ietf.org Reply-To: lyndon_ong@eudoramail.com Subject: Re: Queries regarding LMP. Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Length: 5126 Content-Transfer-Encoding: 7bit Hi, I thought that this was why the fault localization piece of LMP was made negotiable, since it was not necessary to support this in opaque networks. By the same token, is there really a need for fast keep-alive for all situations, esp. for in-band DCC control channels where there is a link layer protocol in use that can monitor control link health? Keep-alive is just further overhead in that situation, especially when there may be hellos in the signaling and routing protocols going on at the same time. Cheers, Lyndon -- On Wed, 25 Jul 2001 12:34:38 Zhi-Wei Lin wrote: >Hi Martin, comments in-line > > >Martin Dubuc wrote: >> >> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of >> control and data link health. To determine whether LMP is useful or not, >> one has to look at the operational aspect of product deployment and >> maintenance, i.e. what tools the vendor wants to implement to facilitate >> provisioning and maintenance of their customers network. In a small >> network, a vendor may be able to get away with manual configuration of >> links. In an opaque network, it is also easy to pinpoint link failures. >> However, in a truly optical network, there needs to be mechanisms to >> isolate faults (which LMP provides). > >When you say "truly optical network", do you mean a network that has no >O/E/O (no 3R) at all? or is there some 3R at the edge? > >As for mechanisms to isolate faults, I think this capability is already >part of networks. For example, SONET has mechanisms such as trace >identifiers, AIS/RDI signals, and tandem connection points for doing >this. OTN (G.709) also has these defined. In addition, OTN has defined 6 >flexible layers for TCM and 2 fixed layer for TCM (section and path). > >I think LMP is not necessary for fault isolation, but it could be >another mechanism that may be used (if one so chooses). > >> >> Usefulness of LMP is not directly tied to use of link bundles. Link >> bundles are mostly used to reduce the flooding of link information >> generated by the routing protocol. >> >> Q3) Destination address can be multicast or any valid IP address of >> destination node (most likely the NodeID of the destination node). >> >> -----Original Message----- >> From: rajesh [mailto:rajesh@tejasnetworks.com] >> Sent: Wednesday, July 25, 2001 1:59 AM >> To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; >> azinin@cisco.com >> Subject: Queries regarding LMP. >> >> Hi, >> >> Have a few queries regd LMP. >> >> Q1) Regd the applicability of LMP... >> >> draft-many-gmpls-architecture-00.txt states that >> >> " For instance, the traditional IP routing model assumes the >> establishment of a routing adjacency over each link connecting two >> adjacent nodes. Having such a large number of adjacencies is not >> scalable at all. Each node needs to maintain each of its adjacencies >> one by one, and link state routing information must be flooded in >> the topology for each link. >> >> To solve this issue the concept of bundling was introduced. >> Moreover, the manual configuration and control of these links, even >> if they are unnumbered, becomes totally impractical. The Link >> Management Protocol (LMP) was specified to solve these problems. " >> >> a) Can one assume that LMP makes sense ONLY in the case of a large >> number of parallel links and link bundling... >> >> and an implementation of GMPLS neednot have LMP if no link >> bundling is used ?? >> >> The above maybe the case when using lower end SONET ADM, >> DXCs... >> >> b) Under what other conditions would one require LMP (ie other than >> link bundling) ? >> >> Q2) Suppose one does NOT need to use LMP but then one needs to use >> OSPF extensions to support TE >> (draft-kompella-ospf-gmpls-extensions-01.txt) , >> >> then one may need to do a correlation of Link Ids between 2 >> TE nodes. >> >> a) Is there a standard recommended way to do this correlation ?? >> >> E.g OSPF - Link Local Signaling >> or OSPF - link scope LSA ? >> >> Q3) Section 9 of draft-ietf-mpls-lmp-02.txt says that LMP messages >> are encoded as IP packets and also suggests protocol number >> 140. >> >> What would be the destination IP address of an LMP packet ?? >> >> A multicast or is it got from an IGP ?? >> >> Q4) In LMP, if a Link Id correlation has been done, and If the link ids >> >> on one of the ends or both change... How is this change taken >> into >> account ?? >> >> Eg for i = 1,2 >> Port i, Node 1 connected to Port i, Node 2 >> >> If one interchanges the connection then one has to recorrelate >> >> the Link Id mappings.. >> >> Thanks in advance, >> Rajesh > > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 11:12:21 -0700 From: Andre Fredette To: 'Osama Aboul-Magd' Cc: Jonathan Lang , ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010725134726.02478188@mailbox> Date: Wed, 25 Jul 2001 14:10:46 -0400 Subject: RE: Optical Link Interface Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18484599==_.ALT" --=====================_18484599==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Osama, [Note: I tried to trim this note down to the key arguments so that it is easier to follow.] My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows: 1. LMP exists. 2. LMP solves most of the OLI problems, 3. Therefore, let's use LMP. Osama's main argument is: 1. I don't think LMP should exist. 2. Therefore let's create a new protocol. Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable. At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote: [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. On the master-slave issue. There is clearly some information that the line system does not need. For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS. I think this works fine within the context of LMP. You have made claims of complexity, but have never been able to back them up with fact. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear. Andre --=====================_18484599==_.ALT Content-Type: text/html; charset="us-ascii" Osama,

[Note: I tried to trim this note down to the key arguments so that it is easier to follow.]

My main argument (and I believe it is shared by the rest of the LMP-WDM co-authors) is as follows:
1. LMP exists.
2. LMP solves most of the OLI problems,
3. Therefore, let's use LMP.

Osama's main argument is:
1. I don't think LMP should exist.
2. Therefore let's create a new protocol.

Given that the members of the working group have decided that LMP will be developed, I don't think Osama's argument is reasonable.

At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.
[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex.

On the master-slave issue.  There is clearly some information that the line system does not need.  For example, I don't expect the Link Characteristics need to be advertised from OXC to OLS.  I think this works fine within the context of LMP.

You have made claims of complexity, but have never been able to back them up with fact.


Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive.

Given the choice between specifying and implementing two protocols that do basically the same thing and one, I think the choice should be clear.

Andre
--=====================_18484599==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 10:48:04 -0700 Message-ID: From: Jonathan Lang To: 'Osama Aboul-Magd' , Jonathan Lang , Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 10:41:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11531.00FBFE60" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11531.00FBFE60 Content-Type: text/plain; charset="iso-8859-1" Osama, Please see inline comments. Thanks, Jonathan -----Original Message----- From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] Sent: Wednesday, July 25, 2001 10:21 AM To: Jonathan Lang; Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Jonathan, Comments are inline. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Jonathan Lang [ mailto:jplang@calient.net ] Sent: Wednesday, July 25, 2001 11:53 AM To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, Please see inline comments. Thanks, Jonathan >-----Original Message----- >From: Osama Aboul-Magd [ mailto:osama@nortelnetworks.com ] >Sent: Wednesday, July 25, 2001 8:15 AM >To: Andre Fredette; ccamp@ops.ietf.org >Subject: RE: Optical Link Interface > > >Andre, >Obviously I disagree with you in your conclusion. There are number of factors that should > be considered: >- While LMP has been in STANDARD process for some time, there hasn't been much deployment, > if any, of it. Furthermore the reality of optical networks today is that same vendor > equipment is deployed in a single span. Implementation of LMP in this case is at best > optional. One may choose not to implement LMP at all. IMHO tying this important interface > to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. > - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. I'm glad you brought this up. TCP greatly complicates the fault recovery procedure and fault recovery is an essential aspect for this interface. [Osama] I am not sure I follow. > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. [Jonathan] Other DWDM vendors are not happy with the master-slave model. Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. > - To link with other standards bodies, as far as I know T1X1, where the optical knowledge > exists, is yet to arrive to a definition of this interface. More contributions are > solicited to better understand its need and applications. Given that, I'd like to > understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 > messages were posted to the mailing list and mostly from authors of the OLI requirements > draft. > - I don't see harm in having two protocols. The market made its decisions on the examples > you mentioned, and I am sure it will happen again in this case. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. [Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed. The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. > Regards; > Osama Aboul-Magd > Nortel Networks > P.O. Box 3511, Station "C" > Ottawa, ON, Canada > K1Y - 4H7 > Tel: 613-763-5827 > e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre ------_=_NextPart_001_01C11531.00FBFE60 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
Osama,
  Please see inline comments.
 
Thanks,
Jonathan
-----Original Message-----
From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 10:21 AM
To: Jonathan Lang; Andre Fredette; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Jonathan,

Comments are inline.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Jonathan Lang [mailto:jplang@calient.net]
Sent:   Wednesday, July 25, 2001 11:53 AM
To:     Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org
Subject:        RE: Optical Link Interface

Osama,
  Please see inline comments.

Thanks,
Jonathan

>-----Original Message-----
>From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
>Sent: Wednesday, July 25, 2001 8:15 AM
>To: Andre Fredette; ccamp@ops.ietf.org
>Subject: RE: Optical Link Interface
>
>
>Andre,
>Obviously I disagree with you in your conclusion. There are number of
factors that should
> be considered:
>- While LMP has been in STANDARD process for some time, there hasn't been
much deployment,
> if any, of it. Furthermore the reality of optical networks today is that
same vendor
> equipment is deployed in a single span. Implementation of LMP in this case
is at best
> optional. One may choose not to implement LMP at all. IMHO tying this
important interface
> to the fate of LMP is not the way to proceed. How long LMP been at the
IETF is irrelevant.
> - NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP.
I'm glad you brought this up.  TCP greatly complicates the fault recovery
procedure and fault recovery is an essential aspect for this interface.

        [Osama] I am not sure I follow.

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers.
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.  

[Jonathan]  Other DWDM vendors are not happy with the master-slave model.  Also, the claim that NTIP is simple is an explicit assertion and you seem to be trying to make an implicit assertion that LMP is complex. 

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge
> exists, is yet to arrive to a definition of this interface. More
contributions are
> solicited to better understand its need and applications. Given that, I'd
like to
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5
> messages were posted to the mailing list and mostly from authors of the
OLI requirements
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate. 

[Jonathan] CR-LDP and RSVP-TE were both being developed prior to either one of them being widely deployed.  The effort involved in developing 2 protocols concurrently to do the same thing is widely perceived as being counter productive. 

> Regards;
> Osama Aboul-Magd
> Nortel Networks
> P.O. Box 3511, Station "C"
> Ottawa, ON, Canada
> K1Y - 4H7
> Tel: 613-763-5827
> e.mail: osama@nortelnetworks.com
 -----Original Message-----
From:   Andre Fredette [mailto:fredette@photonex.com]
Sent:   Monday, July 23, 2001 10:01 PM
To:     ccamp@ops.ietf.org
Subject:        Optical Link Interface
Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London because
meaningful technical discussion cannot occur in the time allocated during
the meeting.
There have been two proposals in the IETF to satisfy the OLI requirements:
1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).
and
2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:
1. [LMP-WDM] satisfies the OLI Requirements.
2. The extensions to LMP are quite natural and fit within the spirit of the
LMP protocol.
3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.
4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)
5. Using the same protocol simplifies both implementation and management on
devices, such as optical cross-connects and routers, that may need to use
both simultaneously.
While there is no doubt in my mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should be the solution
chosen by the CCAMP working group due to the reasons outlined above.
Comments please!
Regards,
Andre

------_=_NextPart_001_01C11531.00FBFE60-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 10:22:46 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04453040@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Jonathan Lang , Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 13:21:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1152E.2C90CA90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1152E.2C90CA90 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Comments are inline. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Wednesday, July 25, 2001 11:53 AM To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Osama, Please see inline comments. Thanks, Jonathan >-----Original Message----- >From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] >Sent: Wednesday, July 25, 2001 8:15 AM >To: Andre Fredette; ccamp@ops.ietf.org >Subject: RE: Optical Link Interface > > >Andre, >Obviously I disagree with you in your conclusion. There are number of factors that should > be considered: >- While LMP has been in STANDARD process for some time, there hasn't been much deployment, > if any, of it. Furthermore the reality of optical networks today is that same vendor > equipment is deployed in a single span. Implementation of LMP in this case is at best > optional. One may choose not to implement LMP at all. IMHO tying this important interface > to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. > - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. I'm glad you brought this up. TCP greatly complicates the fault recovery procedure and fault recovery is an essential aspect for this interface. [Osama] I am not sure I follow. > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex. > - To link with other standards bodies, as far as I know T1X1, where the optical knowledge > exists, is yet to arrive to a definition of this interface. More contributions are > solicited to better understand its need and applications. Given that, I'd like to > understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 > messages were posted to the mailing list and mostly from authors of the OLI requirements > draft. > - I don't see harm in having two protocols. The market made its decisions on the examples > you mentioned, and I am sure it will happen again in this case. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. [Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the wide deployment that RSVP-TE has. The example is inadequate. > Regards; > Osama Aboul-Magd > Nortel Networks > P.O. Box 3511, Station "C" > Ottawa, ON, Canada > K1Y - 4H7 > Tel: 613-763-5827 > e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre ------_=_NextPart_001_01C1152E.2C90CA90 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface

Jonathan,

Comments are inline.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Jonathan Lang [mailto:jplang@calient.net]
Sent:   Wednesday, July 25, 2001 11:53 AM
To:     Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org
Subject:        RE: Optical Link Interface

Osama,
  Please see inline comments.

Thanks,
Jonathan

>-----Original Message-----
>From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
>Sent: Wednesday, July 25, 2001 8:15 AM
>To: Andre Fredette; ccamp@ops.ietf.org
>Subject: RE: Optical Link Interface
>
>
>Andre,
>Obviously I disagree with you in your conclusion. There are number of
factors that should
> be considered:
>- While LMP has been in STANDARD process for some time, there hasn't been
much deployment,
> if any, of it. Furthermore the reality of optical networks today is that
same vendor
> equipment is deployed in a single span. Implementation of LMP in this case
is at best
> optional. One may choose not to implement LMP at all. IMHO tying this
important interface
> to the fate of LMP is not the way to proceed. How long LMP been at the
IETF is irrelevant.
> - NTIP is a new TCP application in the same way as LMP-WDM is a NEW
application for LMP.
I'm glad you brought this up.  TCP greatly complicates the fault recovery
procedure and fault recovery is an essential aspect for this interface.

        [Osama] I am not sure I follow.

> - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model
itself. Your
> choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC
and LS as peers.
> NTIP treats PXC-LS relationship as master-slave. Non peer relationship
suits this
> interface better.
I understand this limitation works for your product, but other WDM vendors
have requested a more flexible model.

        [Osama] what is the limitation here? Are you saying having a simple design is a limitation? Not everything has to be complex.

> - To link with other standards bodies, as far as I know T1X1, where the
optical knowledge
> exists, is yet to arrive to a definition of this interface. More
contributions are
> solicited to better understand its need and applications. Given that, I'd
like to
> understand the rationale for the "rough consensus" reached at CCAMP
mailing list. Only 4-5
> messages were posted to the mailing list and mostly from authors of the
OLI requirements
> draft.
> - I don't see harm in having two protocols. The market made its decisions
on the examples > you mentioned, and I am sure it will happen again in this
case.
Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and
Working Group chairs in Minnesota that only one protocol will progress in
the IETF.
       
[Osama] I don't understand why CR-LDP and RSVP-TE have been brought to this discussion. This is a completely different situation. LMP hasn't seen the  wide deployment that RSVP-TE has. The example is inadequate.

> Regards;
> Osama Aboul-Magd
> Nortel Networks
> P.O. Box 3511, Station "C"
> Ottawa, ON, Canada
> K1Y - 4H7
> Tel: 613-763-5827
> e.mail: osama@nortelnetworks.com
 -----Original Message-----
From:   Andre Fredette [mailto:fredette@photonex.com]
Sent:   Monday, July 23, 2001 10:01 PM
To:     ccamp@ops.ietf.org
Subject:        Optical Link Interface
Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London because
meaningful technical discussion cannot occur in the time allocated during
the meeting.
There have been two proposals in the IETF to satisfy the OLI requirements:
1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).
and
2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt
LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:
1. [LMP-WDM] satisfies the OLI Requirements.
2. The extensions to LMP are quite natural and fit within the spirit of the
LMP protocol.
3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.
4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)
5. Using the same protocol simplifies both implementation and management on
devices, such as optical cross-connects and routers, that may need to use
both simultaneously.
While there is no doubt in my mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should be the solution
chosen by the CCAMP working group due to the reasons outlined above.
Comments please!
Regards,
Andre

------_=_NextPart_001_01C1152E.2C90CA90-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 10:22:03 -0700 Message-ID: From: Jonathan Lang To: 'Martin Dubuc' , rajesh@tejasnetworks.com, mpls@UU.NET, Jonathan Lang , kireeti@juniper.net, azinin@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: Queries regarding LMP. Date: Wed, 25 Jul 2001 10:17:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Following up on Martin's comments... > -----Original Message----- > From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com] > Sent: Wednesday, July 25, 2001 8:59 AM > To: rajesh@tejasnetworks.com; mpls@UU.NET; jplang@calient.net; > kireeti@juniper.net; azinin@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: Queries regarding LMP. > > > Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of > control and data link health. To determine whether LMP is useful or not, > one has to look at the operational aspect of product deployment and > maintenance, i.e. what tools the vendor wants to implement to facilitate > provisioning and maintenance of their customers network. In a small > network, a vendor may be able to get away with manual configuration of > links. In an opaque network, it is also easy to pinpoint link failures. > However, in a truly optical network, there needs to be mechanisms to > isolate faults (which LMP provides). > > Usefulness of LMP is not directly tied to use of link bundles. Link > bundles are mostly used to reduce the flooding of link information > generated by the routing protocol. To add further, when GMPLS labels map to physical resources (i.e., ports or fibers), LMP can be used to exchange these labels so that there is a common understanding of the mapping. Even if man ual configuration is used, LMP provides a mechanism to verify the accuracy (it is not uncommon for manual configuration to be in error...). > > Q3) Destination address can be multicast or any valid IP address of > destination node (most likely the NodeID of the destination node). Note that the protocol Id suggestion of 140 has been removed in the latest version as this value MUST be assigned by IANA. 140 has been used in interops for the time being, but this shouldn't be considered as the final protocol id. Q4) Recorrelation of Link Ids can be done by reverifying the link and/or resending the LinkSummary message. Thanks, Jonathan > > -----Original Message----- > From: rajesh [mailto:rajesh@tejasnetworks.com] > Sent: Wednesday, July 25, 2001 1:59 AM > To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; > azinin@cisco.com > Subject: Queries regarding LMP. > > > Hi, > > Have a few queries regd LMP. > > Q1) Regd the applicability of LMP... > > draft-many-gmpls-architecture-00.txt states that > > " For instance, the traditional IP routing model assumes the > establishment of a routing adjacency over each link connecting two > adjacent nodes. Having such a large number of adjacencies is not > scalable at all. Each node needs to maintain each of its > adjacencies > one by one, and link state routing information must be flooded in > the topology for each link. > > To solve this issue the concept of bundling was introduced. > Moreover, the manual configuration and control of these links, even > if they are unnumbered, becomes totally impractical. The Link > Management Protocol (LMP) was specified to solve these problems. " > > a) Can one assume that LMP makes sense ONLY in the case of a large > number of parallel links and link bundling... > > and an implementation of GMPLS neednot have LMP if no link > bundling is used ?? > > The above maybe the case when using lower end SONET ADM, > DXCs... > > b) Under what other conditions would one require LMP (ie other than > link bundling) ? > > Q2) Suppose one does NOT need to use LMP but then one needs to use > OSPF extensions to support TE > (draft-kompella-ospf-gmpls-extensions-01.txt) , > > then one may need to do a correlation of Link Ids between 2 > TE nodes. > > a) Is there a standard recommended way to do this > correlation ?? > > E.g OSPF - Link Local Signaling > or OSPF - link scope LSA ? > > Q3) Section 9 of draft-ietf-mpls-lmp-02.txt says that LMP messages > are encoded as IP packets and also suggests protocol number > 140. > > What would be the destination IP address of an LMP packet ?? > > A multicast or is it got from an IGP ?? > > Q4) In LMP, if a Link Id correlation has been done, and If > the link ids > > on one of the ends or both change... How is this change taken > into > account ?? > > Eg for i = 1,2 > Port i, Node 1 connected to Port i, Node 2 > > If one interchanges the connection then one has to > recorrelate > > the Link Id mappings.. > > Thanks in advance, > Rajesh > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 09:38:28 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04452FE5@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: John Drake , Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 12:37:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11528.0FEA6820" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11528.0FEA6820 Content-Type: text/plain; charset="iso-8859-1" Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, July 25, 2001 11:47 AM To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface -----Original Message----- From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] Sent: Wednesday, July 25, 2001 8:15 AM To: Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Obviously I disagree with you in your conclusion. There are number of factors that should be considered: - While LMP has been in STANDARD process for some time, there hasn't been much deployment, if any, of it. Furthermore the reality of optical networks today is that same vendor equipment is deployed in a single span. Implementation of LMP in this case is at best optional. One may choose not to implement LMP at all. IMHO tying this important interface to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. [John Drake] You're first arguing that if the interface is based upon LMP it's not needed, and then arguing that if it's not based upon LMP that it's critical - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. [John Drake] Assertion not supported by the facts - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this interface better. [John Drake] Assertion not supported by the facts - To link with other standards bodies, as far as I know T1X1, where the optical knowledge exists, is yet to ar rive to a definition of this interface. More contributions are solicited to better understand its need and applications. Given that, I'd like to understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 messages were posted to the mailing list and mostly from authors of the OLI requirements draft. [John Drake] I'm sure that there's a point here - I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case. [John Drake] The market has settled on RSVP-TE, so there's clearly an existence proof that that the market prefers a single solution [Osama] totally a different situation. Please let me know how much LMP installed base is out there today? However you seem to agree with me that we can trust the market to make the decision. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre ------_=_NextPart_001_01C11528.0FEA6820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

<= ![if = !supportEmptyParas]> 

=

<= ![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: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, July = 25, 2001 11:47 AM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Andre Fredette; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

 <= /p>

 <= /p>

-----Original Message-----
From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
Sent: Wednesday, July = 25, 2001 8:15 AM
To: Andre Fredette; ccamp@ops.ietf.org
Subject: RE: Optical = Link Interface

Andre,

Obviously I disagree with you in = your conclusion. There are number of factors that should be = considered: <= /p>

- While LMP has been in STANDARD = process for some time, there hasn't been much deployment, if any, of it. = Furthermore the reality of optical networks today is that same vendor equipment is = deployed in a single span. Implementation of LMP in this case is at best = optional. One may choose not to implement LMP at all. IMHO tying this important = interface to the fate of LMP is not the way to proceed. How long LMP been at the = IETF is irrelevant.
[John Drake] <= /p>

You're first = arguing that if the interface is based upon LMP it's not needed, and then arguing = that if it's not based upon LMP that it's critical <= /p>

- NTIP is a new TCP application = in the same way as LMP-WDM is a NEW application for LMP.
[John Drake] <= /p>

Assertion not = supported by the facts 

- The issue is not really LMP vs = TCP. NTIP and LMP-WDM differ in the model itself. Your choice to use LMP to run = LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP treats = PXC-LS relationship as master-slave. Non peer relationship suits this interface better.
[John Drake] <= /p>

Assertion not = supported by the facts 

- To link with other standards = bodies, as far as I know T1X1, where the optical knowledge exists, is yet to = ar rive to a definition of this interface. More contributions are solicited to = better understand its need and applications. Given that, I'd like to = understand the rationale for the "rough consensus" reached at CCAMP mailing = list. Only 4-5 messages were posted to the mailing list and mostly from = authors of the OLI requirements draft.
[John Drake] <= /p>

I'm sure that = there's a point here 

- I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, = and I am sure it will happen again in this case.
[John Drake] <= /p>

The market has = settled on RSVP-TE, so there's clearly an existence proof that that the = market prefers a single solution 

<= span style=3D'mso-tab-count:2'>       &nbs= p;           &nbs= p;    [Osama] totally a different situation. Please let me know how much LMP = installed base is out there today? However you seem to agree with me that we can trust = the market to make the decision.

Regards;

Osama = Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original = Message-----
From:   Andre Fredette [mailto:fredette@photonex.com]
Sent:   Monday, July 23, 2001 10:01 = PM
To:     = ccamp@ops.ietf.org
Subject:        Optical = Link Interface = <= /p>

Last month, the "Optical = Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-= reqts-00.txt
was discussed on the ccamp mailing list and achieved = "rough consensus"
according to our working group co-chairs.  Given = this, we'd like to make
some progress on the protocol specification.  I'd = like to generate some
discussion on this mailing list before the IETF meeting in = London because =
meaningful technical discussion cannot occur in the time = allocated during =
the meeting.

There have been two proposals in = the IETF to satisfy the OLI requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-0= 2.txt
(note, this updated document was submitted Friday, so it = should show up =
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for = Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-cca= mp-ntip-00.txt <= /p>

LMP-WDM proposes extensions to = LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the = LMP approach is best
because: <= /p>

1. [LMP-WDM] satisfies the OLI Requirements. <= /p>

2. The extensions to LMP are = quite natural and fit within the spirit of the
LMP protocol.

3. LMP is a reasonably mature = IETF protocol specification:
     - It has been in the works for = well over a year. =
     - It is an official working group document. =

4. It is better to have one = protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. = IS-IS) <= /p>

5. Using the same protocol = simplifies both implementation and management on
devices, such as optical cross-connects and routers, that = may need to use =
both simultaneously.

While there is no doubt in my = mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should = be the solution =
chosen by the CCAMP working group due to the reasons = outlined above. = <= /p>

Comments = please! <= /p>

Regards,
Andre <= /p>

------_=_NextPart_001_01C11528.0FEA6820-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 09:36:33 -0700 Message-ID: <3B5EF51E.B6FBC137@lucent.com> Date: Wed, 25 Jul 2001 12:34:38 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: Martin Dubuc CC: rajesh@tejasnetworks.com, mpls@UU.NET, jplang@calient.net, kireeti@juniper.net, azinin@cisco.com, ccamp@ops.ietf.org Subject: Re: Queries regarding LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Martin, comments in-line Martin Dubuc wrote: > > Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of > control and data link health. To determine whether LMP is useful or not, > one has to look at the operational aspect of product deployment and > maintenance, i.e. what tools the vendor wants to implement to facilitate > provisioning and maintenance of their customers network. In a small > network, a vendor may be able to get away with manual configuration of > links. In an opaque network, it is also easy to pinpoint link failures. > However, in a truly optical network, there needs to be mechanisms to > isolate faults (which LMP provides). When you say "truly optical network", do you mean a network that has no O/E/O (no 3R) at all? or is there some 3R at the edge? As for mechanisms to isolate faults, I think this capability is already part of networks. For example, SONET has mechanisms such as trace identifiers, AIS/RDI signals, and tandem connection points for doing this. OTN (G.709) also has these defined. In addition, OTN has defined 6 flexible layers for TCM and 2 fixed layer for TCM (section and path). I think LMP is not necessary for fault isolation, but it could be another mechanism that may be used (if one so chooses). > > Usefulness of LMP is not directly tied to use of link bundles. Link > bundles are mostly used to reduce the flooding of link information > generated by the routing protocol. > > Q3) Destination address can be multicast or any valid IP address of > destination node (most likely the NodeID of the destination node). > > -----Original Message----- > From: rajesh [mailto:rajesh@tejasnetworks.com] > Sent: Wednesday, July 25, 2001 1:59 AM > To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; > azinin@cisco.com > Subject: Queries regarding LMP. > > Hi, > > Have a few queries regd LMP. > > Q1) Regd the applicability of LMP... > > draft-many-gmpls-architecture-00.txt states that > > " For instance, the traditional IP routing model assumes the > establishment of a routing adjacency over each link connecting two > adjacent nodes. Having such a large number of adjacencies is not > scalable at all. Each node needs to maintain each of its adjacencies > one by one, and link state routing information must be flooded in > the topology for each link. > > To solve this issue the concept of bundling was introduced. > Moreover, the manual configuration and control of these links, even > if they are unnumbered, becomes totally impractical. The Link > Management Protocol (LMP) was specified to solve these problems. " > > a) Can one assume that LMP makes sense ONLY in the case of a large > number of parallel links and link bundling... > > and an implementation of GMPLS neednot have LMP if no link > bundling is used ?? > > The above maybe the case when using lower end SONET ADM, > DXCs... > > b) Under what other conditions would one require LMP (ie other than > link bundling) ? > > Q2) Suppose one does NOT need to use LMP but then one needs to use > OSPF extensions to support TE > (draft-kompella-ospf-gmpls-extensions-01.txt) , > > then one may need to do a correlation of Link Ids between 2 > TE nodes. > > a) Is there a standard recommended way to do this correlation ?? > > E.g OSPF - Link Local Signaling > or OSPF - link scope LSA ? > > Q3) Section 9 of draft-ietf-mpls-lmp-02.txt says that LMP messages > are encoded as IP packets and also suggests protocol number > 140. > > What would be the destination IP address of an LMP packet ?? > > A multicast or is it got from an IGP ?? > > Q4) In LMP, if a Link Id correlation has been done, and If the link ids > > on one of the ends or both change... How is this change taken > into > account ?? > > Eg for i = 1,2 > Port i, Node 1 connected to Port i, Node 2 > > If one interchanges the connection then one has to recorrelate > > the Link Id mappings.. > > Thanks in advance, > Rajesh Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 09:01:01 -0700 content-class: urn:content-classes:message Subject: RE: Queries regarding LMP. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jul 2001 11:58:31 -0400 Message-ID: Thread-Topic: Queries regarding LMP. Thread-Index: AcEUzv8oQDe7d+VTQXKqdTvHaG/QKQAUIDNQ From: "Martin Dubuc" To: , , , , Cc: Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of control and data link health. To determine whether LMP is useful or not, one has to look at the operational aspect of product deployment and maintenance, i.e. what tools the vendor wants to implement to facilitate provisioning and maintenance of their customers network. In a small network, a vendor may be able to get away with manual configuration of links. In an opaque network, it is also easy to pinpoint link failures. However, in a truly optical network, there needs to be mechanisms to isolate faults (which LMP provides). Usefulness of LMP is not directly tied to use of link bundles. Link bundles are mostly used to reduce the flooding of link information generated by the routing protocol. Q3) Destination address can be multicast or any valid IP address of destination node (most likely the NodeID of the destination node). -----Original Message----- From: rajesh [mailto:rajesh@tejasnetworks.com] Sent: Wednesday, July 25, 2001 1:59 AM To: mpls@UU.NET; jplang@calient.net; kireeti@juniper.net; azinin@cisco.com Subject: Queries regarding LMP. Hi, Have a few queries regd LMP. Q1) Regd the applicability of LMP... draft-many-gmpls-architecture-00.txt states that " For instance, the traditional IP routing model assumes the establishment of a routing adjacency over each link connecting two adjacent nodes. Having such a large number of adjacencies is not scalable at all. Each node needs to maintain each of its adjacencies one by one, and link state routing information must be flooded in the topology for each link. To solve this issue the concept of bundling was introduced. Moreover, the manual configuration and control of these links, even if they are unnumbered, becomes totally impractical. The Link Management Protocol (LMP) was specified to solve these problems. " a) Can one assume that LMP makes sense ONLY in the case of a large number of parallel links and link bundling... and an implementation of GMPLS neednot have LMP if no link bundling is used ?? The above maybe the case when using lower end SONET ADM, DXCs... b) Under what other conditions would one require LMP (ie other than link bundling) ? Q2) Suppose one does NOT need to use LMP but then one needs to use OSPF extensions to support TE (draft-kompella-ospf-gmpls-extensions-01.txt) , then one may need to do a correlation of Link Ids between 2 TE nodes. a) Is there a standard recommended way to do this correlation ?? E.g OSPF - Link Local Signaling or OSPF - link scope LSA ? Q3) Section 9 of draft-ietf-mpls-lmp-02.txt says that LMP messages are encoded as IP packets and also suggests protocol number 140. What would be the destination IP address of an LMP packet ?? A multicast or is it got from an IGP ?? Q4) In LMP, if a Link Id correlation has been done, and If the link ids on one of the ends or both change... How is this change taken into account ?? Eg for i =3D 1,2 Port i, Node 1 connected to Port i, Node 2 If one interchanges the connection then one has to recorrelate the Link Id mappings.. Thanks in advance, Rajesh Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 08:59:24 -0700 Message-ID: From: Jonathan Lang To: 'Osama Aboul-Magd' , Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 08:53:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Osama, Please see inline comments. Thanks, Jonathan >-----Original Message----- >From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] >Sent: Wednesday, July 25, 2001 8:15 AM >To: Andre Fredette; ccamp@ops.ietf.org >Subject: RE: Optical Link Interface > > >Andre, >Obviously I disagree with you in your conclusion. There are number of factors that should > be considered: >- While LMP has been in STANDARD process for some time, there hasn't been much deployment, > if any, of it. Furthermore the reality of optical networks today is that same vendor > equipment is deployed in a single span. Implementation of LMP in this case is at best > optional. One may choose not to implement LMP at all. IMHO tying this important interface > to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. > - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. I'm glad you brought this up. TCP greatly complicates the fault recovery procedure and fault recovery is an essential aspect for this interface. > - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your > choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. > NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this > interface better. I understand this limitation works for your product, but other WDM vendors have requested a more flexible model. > - To link with other standards bodies, as far as I know T1X1, where the optical knowledge > exists, is yet to arrive to a definition of this interface. More contributions are > solicited to better understand its need and applications. Given that, I'd like to > understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 > messages were posted to the mailing list and mostly from authors of the OLI requirements > draft. > - I don't see harm in having two protocols. The market made its decisions on the examples > you mentioned, and I am sure it will happen again in this case. Given the CR-LDP fiasco in MPLS, it was clearly stated by the ADs and Working Group chairs in Minnesota that only one protocol will progress in the IETF. > Regards; > Osama Aboul-Magd > Nortel Networks > P.O. Box 3511, Station "C" > Ottawa, ON, Canada > K1Y - 4H7 > Tel: 613-763-5827 > e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 08:48:43 -0700 Message-ID: From: John Drake To: 'Osama Aboul-Magd' , Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 08:46:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11520.FFB62B30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11520.FFB62B30 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] Sent: Wednesday, July 25, 2001 8:15 AM To: Andre Fredette; ccamp@ops.ietf.org Subject: RE: Optical Link Interface Andre, Obviously I disagree with you in your conclusion. There are number of factors that should be considered: - While LMP has been in STANDARD process for some time, there hasn't been much deployment, if any, of it. Furthermore the reality of optical networks today is that same vendor equipment is deployed in a single span. Implementation of LMP in this case is at best optional. One may choose not to implement LMP at all. IMHO tying this important interface to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. [John Drake] You're first arguing that if the interface is based upon LMP it's not needed, and then arguing that if it's not based upon LMP that it's critical - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. [John Drake] Assertion not supported by the facts - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this interface better. [John Drake] Assertion not supported by the facts - To link with other standards bodies, as far as I know T1X1, where the optical knowledge exists, is yet to ar rive to a definition of this interface. More contributions are solicited to better understand its need and applications. Given that, I'd like to understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 messages were posted to the mailing list and mostly from authors of the OLI requirements draft. [John Drake] I'm sure that there's a point here - I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case. [John Drake] The market has settled on RSVP-TE, so there's clearly an existence proof that that the market prefers a single solution Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [ mailto:fredette@photonex.com ] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre ------_=_NextPart_001_01C11520.FFB62B30 Content-Type: text/html; charset="iso-8859-1" RE: Optical Link Interface
 
-----Original Message-----
From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
Sent: Wednesday, July 25, 2001 8:15 AM
To: Andre Fredette; ccamp@ops.ietf.org
Subject: RE: Optical Link Interface

Andre,

Obviously I disagree with you in your conclusion. There are number of factors that should be considered:

- While LMP has been in STANDARD process for some time, there hasn't been much deployment, if any, of it. Furthermore the reality of optical networks today is that same vendor equipment is deployed in a single span. Implementation of LMP in this case is at best optional. One may choose not to implement LMP at all. IMHO tying this important interface to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant.
[John Drake] 

You're first arguing that if the interface is based upon LMP it's not needed, and then arguing that if it's not based upon LMP that it's critical 

- NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP.
[John Drake] 

Assertion not supported by the facts 

- The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this interface better.
[John Drake] 

Assertion not supported by the facts 

- To link with other standards bodies, as far as I know T1X1, where the optical knowledge exists, is yet to ar rive to a definition of this interface. More contributions are solicited to better understand its need and applications. Given that, I'd like to understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 messages were posted to the mailing list and mostly from authors of the OLI requirements draft.
[John Drake] 

I'm sure that there's a point here 

- I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case.
[John Drake] 

The market has settled on RSVP-TE, so there's clearly an existence proof that that the market prefers a single solution 

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Andre Fredette [mailto:fredette@photonex.com]
Sent:   Monday, July 23, 2001 10:01 PM
To:     ccamp@ops.ietf.org
Subject:        Optical Link Interface

Last month, the "Optical Link Interface (OLI) Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
was discussed on the ccamp mailing list and achieved "rough consensus"
according to our working group co-chairs.  Given this, we'd like to make
some progress on the protocol specification.  I'd like to generate some
discussion on this mailing list before the IETF meeting in London because
meaningful technical discussion cannot occur in the time allocated during
the meeting.

There have been two proposals in the IETF to satisfy the OLI requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt
(note, this updated document was submitted Friday, so it should show up
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt

LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while
NTIP proposes a new protocol.  We believe that the LMP approach is best
because:

1. [LMP-WDM] satisfies the OLI Requirements.

2. The extensions to LMP are quite natural and fit within the spirit of the
LMP protocol.

3. LMP is a reasonably mature IETF protocol specification:
     - It has been in the works for well over a year.
     - It is an official working group document.

4. It is better to have one protocol, than two for a given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS)

5. Using the same protocol simplifies both implementation and management on
devices, such as optical cross-connects and routers, that may need to use
both simultaneously.

While there is no doubt in my mind that NTIP could be made to satisfy the
OLI requirements, It is my strong opinion that LMP should be the solution
chosen by the CCAMP working group due to the reasons outlined above.

Comments please!

Regards,
Andre

------_=_NextPart_001_01C11520.FFB62B30-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 08:18:48 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04452F38@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Andre Fredette , ccamp@ops.ietf.org Subject: RE: Optical Link Interface Date: Wed, 25 Jul 2001 11:15:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1151C.937F5DF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1151C.937F5DF0 Content-Type: text/plain; charset="iso-8859-1" Andre, Obviously I disagree with you in your conclusion. There are number of factors that should be considered: - While LMP has been in STANDARD process for some time, there hasn't been much deployment, if any, of it. Furthermore the reality of optical networks today is that same vendor equipment is deployed in a single span. Implementation of LMP in this case is at best optional. One may choose not to implement LMP at all. IMHO tying this important interface to the fate of LMP is not the way to proceed. How long LMP been at the IETF is irrelevant. - NTIP is a new TCP application in the same way as LMP-WDM is a NEW application for LMP. - The issue is not really LMP vs TCP. NTIP and LMP-WDM differ in the model itself. Your choice to use LMP to run LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP treats PXC-LS relationship as master-slave. Non peer relationship suits this interface better. - To link with other standards bodies, as far as I know T1X1, where the optical knowledge exists, is yet to arrive to a definition of this interface. More contributions are solicited to better understand its need and applications. Given that, I'd like to understand the rationale for the "rough consensus" reached at CCAMP mailing list. Only 4-5 messages were posted to the mailing list and mostly from authors of the OLI requirements draft. - I don't see harm in having two protocols. The market made its decisions on the examples you mentioned, and I am sure it will happen again in this case. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Monday, July 23, 2001 10:01 PM To: ccamp@ops.ietf.org Subject: Optical Link Interface Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre ------_=_NextPart_001_01C1151C.937F5DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical Link Interface

Andre,

Obviously I disagree with you in your conclusion. = There are number of factors that should be considered:

- While LMP has been in STANDARD process for some = time, there hasn't been much deployment, if any, of it. Furthermore the = reality of optical networks today is that same vendor equipment is = deployed in a single span. Implementation of LMP in this case is at = best optional. One may choose not to implement LMP at all. IMHO tying = this important interface to the fate of LMP is not the way to proceed. = How long LMP been at the IETF is irrelevant.

- NTIP is a new TCP application in the same way as = LMP-WDM is a NEW application for LMP.

- The issue is not really LMP vs TCP. NTIP and = LMP-WDM differ in the model itself. Your choice to use LMP to run = LMP-WDM on top of it forced you to treat the PXC and LS as peers. NTIP = treats PXC-LS relationship as master-slave. Non peer relationship suits = this interface better.

- To link with other standards bodies, as far as I = know T1X1, where the optical knowledge exists, is yet to arrive to a = definition of this interface. More contributions are solicited to = better understand its need and applications. Given that, I'd like to = understand the rationale for the "rough consensus" reached at = CCAMP mailing list. Only 4-5 messages were posted to the mailing list = and mostly from authors of the OLI requirements draft.

- I don't see harm in having two protocols. The = market made its decisions on the examples you mentioned, and I am sure = it will happen again in this case.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Andre Fredette [mailto:fredette@photonex.com] =
Sent:   Monday, July 23, 2001 10:01 = PM
To:     = ccamp@ops.ietf.org
Subject:        = Optical Link Interface

Last month, the "Optical Link Interface (OLI) = Requirements" document
http://search.ietf.org/internet-drafts/draft-many-oli-= reqts-00.txt
was discussed on the ccamp mailing list and achieved = "rough consensus"
according to our working group co-chairs.  = Given this, we'd like to make
some progress on the protocol specification.  = I'd like to generate some
discussion on this mailing list before the IETF = meeting in London because
meaningful technical discussion cannot occur in the = time allocated during
the meeting.

There have been two proposals in the IETF to satisfy = the OLI requirements:

1. [LMP-WDM]:
"Link Management Protocol (LMP) for DWDM = Optical Line Systems"
http://www.photonex.com/other/draft-fredette-lmp-wdm-0= 2.txt
(note, this updated document was submitted Friday, = so it should show up
on the official website soon).

and

2. [NTIP]:
"Network Transport Interface Protocol (NTIP) = for Photonic Cross Connects"
(PXC) http://search.ietf.org/internet-drafts/draft-sahay-cca= mp-ntip-00.txt

LMP-WDM proposes extensions to LMP to satisfy the OLI = requirements, while
NTIP proposes a new protocol.  We believe that = the LMP approach is best
because:

1. [LMP-WDM] satisfies the OLI Requirements.

2. The extensions to LMP are quite natural and fit = within the spirit of the
LMP protocol.

3. LMP is a reasonably mature IETF protocol = specification:
     - It has been in the works = for well over a year.
     - It is an official working = group document.

4. It is better to have one protocol, than two for a = given function
(remember CR-LDP vs. RSVP-TE, and OSPF vs. = IS-IS)

5. Using the same protocol simplifies both = implementation and management on
devices, such as optical cross-connects and routers, = that may need to use
both simultaneously.

While there is no doubt in my mind that NTIP could be = made to satisfy the
OLI requirements, It is my strong opinion that LMP = should be the solution
chosen by the CCAMP working group due to the reasons = outlined above.

Comments please!

Regards,
Andre

------_=_NextPart_001_01C1151C.937F5DF0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 07:44:53 -0700 Message-ID: <47D99458148BD411BE2E0090276155790228CAC8@njc240po04.mt.att.com> From: "Brungard, Deborah A, ALCTA" To: "'manoj juneja'" , ccamp@ops.ietf.org Subject: RE: Latest SONET Specification Date: Wed, 25 Jul 2001 10:20:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The latest version is available via the T1X1.5 files as T1X1.5/2001-062: ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC Regards, Deborah Brungard AT&T -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Tuesday, July 24, 2001 9:09 PM To: ccamp@ops.ietf.org Subject: Latest SONET Specification Hi All, Where can I find the latest SONET specs (which explains the SONET multiplexing structure) SONET ANSI T1.105-2000 ? Is it published ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jul 2001 05:59:02 -0700 Message-ID: From: "Mannie, Eric" To: 'Heiles Juergen' , 'Maarten Vissers' , ccamp Cc: "t1x1.5" , q11/15 Subject: ARE: [T1X1.5] arbitrary contiguous concatenation question Date: Wed, 25 Jul 2001 14:55:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Juergen and Maarten, I don't understand the relationship between draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that you are = talking about. In addition, the IETF is not specifying any SDH/SONET interoperability = (Not at all in the GMPLS scope). Also, I am not sure to understand why the abstract (B, A) notation of = G.707 (used to have a clearer specification, and not used (transported) in = any protocol as far as I know) could imply that contiguous time-slots are = not contiguous anymore ? The "Arbitrary" concatenation that you are speaking about is a = contiguous concatenation, time-slots are physically contiguous. I don't understand = the relevance of the SDH (B, A) notation in relationship with SONET in the context of the IETF. Anyway, contiguous time-slots will stay physically contiguous even if you see an issue with the SDH G.707 (B, A) notation applied to SONET. Also, "flexible arbitrary concatenation" (whatever it is - everybody = seems to have a different understanding) is not part of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt. I guess also that this discussion is relevant for the ITU-T and/or = T1X1, not for the ccamp mailing list (of the IETF). Kind regards, Eric -----Original Message----- From: Heiles Juergen [mailto: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 = have 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 >=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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jul 2001 18:11:52 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Latest SONET Specification Date: Tue, 24 Jul 2001 18:09:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Where can I find the latest SONET specs (which explains the SONET multiplexing structure) SONET ANSI T1.105-2000 ? Is it published ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jul 2001 13:46:01 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: lberger@movaz.com, Eric.Mannie@ebone.com Bcc: Subject: Fwd: RE: {SUKLM} numbering scheme Date: Tue, 24 Jul 2001 13:44:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric and Lou, The new GMPLS signalling drafts still distinguish between different SDH and SONET version of specifications (like 2000, 1995 etc.). Eric, As u said earlier that we will be having only one value for SDH and one for SONET LSP encoding type. please see the mail below for further information. I want to know that whether this has been done intentionally or it is just a bug that still need to be removed. Please clarify. Regards, manoj. >From: "Mannie, Eric" >To: 'manoj juneja' , ccamp@ops.ietf.org >CC: "'lberger@movaz.com'" >Subject: RE: {SUKLM} numbering scheme >Date: Thu, 28 Jun 2001 21:38:10 +0200 > >Hello Manoj, > >The label is the same of course. > >The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a >small bug coming from an old version. That should be removed by Lou. We >should have only one SDH LSP encoding type value for SDH (same for SONET). > >Lou: thanks to correct it. > >For the conversion table, Maarten should still have it. > >Kind regards, > >Eric > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Thursday, June 28, 2001 8:28 PM >To: ccamp@ops.ietf.org >Subject: {SUKLM} numbering scheme > > >Hi All, > I have a doubt regarding {SUKLM} numbering scheme. If I >allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be >different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH >ITU-T G.707 2000 ? > >Eric, on the ipo u and marteen once exchanged the conversion table for >EDCBA and SU, If that table is correct, can u please tell me the >formula from which u derived that table ? > >Regards, >manoj. > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jul 2001 12:17:53 -0700 Message-Id: <4.3.2.7.2.20010724133052.00e69100@mo-ex1> Date: Tue, 24 Jul 2001 15:14:18 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: new gmpls signaling drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed FYI - New versions of the GMPLS signaling drafts have been submitted. We attempted to cover the major last call issues. For those who don't want to wait, the drafts are available at: http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-05.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-04.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-04.txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jul 2001 07:49:16 -0700 Message-ID: From: Heiles Juergen To: "'Maarten Vissers'" , ccamp Cc: "t1x1.5" , q11/15 Subject: AW: [T1X1.5] arbitrary contiguous concatenation question Date: Tue, 24 Jul 2001 16:28:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten, good point. Lets hear what the supporters of arbitrary concatenation = have 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 >=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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 23 Jul 2001 19:06:42 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010723141353.054510b0@mailbox> Date: Mon, 23 Jul 2001 22:00:46 -0400 Subject: Optical Link Interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Last month, the "Optical Link Interface (OLI) Requirements" document http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt was discussed on the ccamp mailing list and achieved "rough consensus" according to our working group co-chairs. Given this, we'd like to make some progress on the protocol specification. I'd like to generate some discussion on this mailing list before the IETF meeting in London because meaningful technical discussion cannot occur in the time allocated during the meeting. There have been two proposals in the IETF to satisfy the OLI requirements: 1. [LMP-WDM]: "Link Management Protocol (LMP) for DWDM Optical Line Systems" http://www.photonex.com/other/draft-fredette-lmp-wdm-02.txt (note, this updated document was submitted Friday, so it should show up on the official website soon). and 2. [NTIP]: "Network Transport Interface Protocol (NTIP) for Photonic Cross Connects" (PXC) http://search.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt LMP-WDM proposes extensions to LMP to satisfy the OLI requirements, while NTIP proposes a new protocol. We believe that the LMP approach is best because: 1. [LMP-WDM] satisfies the OLI Requirements. 2. The extensions to LMP are quite natural and fit within the spirit of the LMP protocol. 3. LMP is a reasonably mature IETF protocol specification: - It has been in the works for well over a year. - It is an official working group document. 4. It is better to have one protocol, than two for a given function (remember CR-LDP vs. RSVP-TE, and OSPF vs. IS-IS) 5. Using the same protocol simplifies both implementation and management on devices, such as optical cross-connects and routers, that may need to use both simultaneously. While there is no doubt in my mind that NTIP could be made to satisfy the OLI requirements, It is my strong opinion that LMP should be the solution chosen by the CCAMP working group due to the reasons outlined above. Comments please! Regards, Andre Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 18:05:55 -0700 From: "manoj juneja" To: eric.gray@sandburst.com Cc: swallow@cisco.com, ccamp@ops.ietf.org Bcc: Subject: Re: Bi-directional LSPs Incompatibility Date: Fri, 20 Jul 2001 18:03:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric, I was going through the OIF Signallng working group mail archive. I found one mail related to making the RESVCONF message mandatory. There were mails exchanged in OIF on 2nd July related to this thread. Fong Liaw mentioned some advantages of keeping the RESVCONF message. Fong stated the following text : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "One reason for not pre-program the cross-connect in the forward direction is to prevent misbehaved (destination) client taking advantages of the pre-programmed cross-connect, send traffic and then reject the connection to avoid billing. This was a big problem for voice calls and I also heard Curtis raised the concern of pre-programming at one of the OIF meeting." p.s. The ResvConf message is really an advisory message. There are other ways to find out if the cross-connect has been programmed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Even Osama Aboul-Magd of Nortel has agreed to put this type of 3-way handshake in LDP. Osama defined new status code "reservation confirmed" in the notification message. So, I think it will not going to be removed. So, probably GMPLS has to add this in the new revision. Please comment. Regards, manoj. >From: Eric Gray >To: manoj juneja >CC: swallow@cisco.com, ccamp@ops.ietf.org >Subject: Re: Bi-directional LSPs Incompatibility >Date: Thu, 19 Jul 2001 10:58:02 -0400 > >Manoj , > > George's point is that strict alignment does not need to be a goal. >If you look at the O-UNI as a user of GMPLS services, there is no >reason to expect this user to use all available services. > >-- >Eric Gray > >You wrote: > > > Hi George, > > As long as both the documents are not aligned, we can say >there > > is some incompatibility. I think one can argue it in both ways. Is it a > > incompatibility or a feature that GMPLS offers but UNI is unable to make >use > > of it ? > > > > Regards, > > manoj. > > > > >From: George Swallow > > >To: "manoj juneja" > > >CC: ccamp@ops.ietf.org, swallow@cisco.com > > >Subject: Re: Bi-directional LSPs Incompatibility > > >Date: Wed, 18 Jul 2001 18:23:39 -0400 > > > > > > > Hi All, > > > > There is some incompatibility in documents of OIF > > > > (oif2000.125.5) and IETF >(draft-ietf-mpls-generalized-rsvp-te-03.txt) > > > > related to bidirectional LSPs. OIF's O-UNI document says [docId > > > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must > > > > insert a RESV_CONFIRM object in the RESV message and should wait for > > > > ResvConf message before start transmitting data. > > > > But, the IETF document says the terminator node process path message > > > > as usual with the exception that the upstream label can immediately >be > > > > used to transport data traffic associated with the LSP upstream >towards > > > > the initiator. > > > > > > > > Please Help. > > > > > > > > Regards, > > > > manoj. > > > > > >I don't see a problem in this case. Having the two ends more > > >constrained than the middle as to when a circuit can be considered in > > >service doesn't seem to present a problem. > > > > > >But my personal opinion is that the RESV Conf should be optional for > > >the UNI. > > > > > >...George > > > > > >================================================================== > > >George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 14:28:59 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590A21B4B@MILAN> From: bhaskara@turinnetworks.com To: jplang@calient.net, adnan@varros.com, ccamp@ops.ietf.org Cc: saibal@varros.com Subject: RE: LMP questions Date: Fri, 20 Jul 2001 14:27:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11162.B9212970" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11162.B9212970 Content-Type: text/plain; charset="iso-8859-1" Hi Jonathan, How does LMP respond to adjacent link failures? i.e., how does lmp converge on adjacent data link failures for fault location identification? this case has not been discussed in the draft. rgds bhaskara -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Friday, July 20, 2001 2:11 PM To: 'Adnan Ahmed'; Jonathan Lang; ccamp@ops.ietf.org Cc: Saibal Das Subject: RE: LMP questions Adnan, In your example, you need to run an LMP control channel between B and C. This control channel could be tunneled through A. Thanks, Jonathan > -----Original Message----- > From: Adnan Ahmed [mailto:adnan@varros.com] > Sent: Friday, July 20, 2001 4:02 PM > To: Jonathan Lang; ccamp@ops.ietf.org > Cc: Saibal Das > Subject: Re: LMP questions > > > Jonathan: > > I have a follow up question related to your response: > > "Assuming that the control channels utilize an out-of-band > network (such > as Ethernet) will the control channel topology i.e. the physical > infrastructure used to realize the CCs, match the fiber topology? > [Jonathan] The control channel topology does not need to > match the fiber > technology." > > Consider this scenario involving three OXCs where: > > - OXCs A, B and C are connected to each other through fiber > - Control channel CC-1 is setup b/w A & B and a control > channel CC-2 is > setup b/w A & C. > > Does your response above imply that it is possible to setup > TE/data bearing > links between OXCs B and C by utilizing CC-1 and CC-2 without a direct > control channel between them? > > Thank you for your help. > -- Adnan > > > ----- Original Message ----- > From: "Jonathan Lang" > To: "'Adnan Ahmed'" ; > Cc: "Saibal Das" > Sent: Friday, July 20, 2001 1:38 PM > Subject: RE: LMP questions > > > > Adnan, > > Please see inline comments. > > > > Thanks, > > Jonathan > > > > -----Original Message----- > > From: Adnan Ahmed [mailto:adnan@varros.com] > > Sent: Friday, July 20, 2001 10:59 AM > > To: ccamp@ops.ietf.org > > Cc: Saibal Das > > Subject: LMP questions > > > > > > Hello: > > > > I have some questions regarding LMP: > > > > 1. What mechanism is used to automatically setup control > channels b/w two > > nodes? Will the user or managing application update the > lmpNbrTable with > > neighbouring nodes before a node initiates control channel > setup, or is a > > node required to incoporate some sort of "ping" to discover > noeghbours and > > then initiate CC setup? > > [Jonathan] Currently, the draft doesn't specify a mechanism to > automatically > > setup control channels. There has been some work done in > the OIF to do > > this. > > > > 2. Assuming that the control channels utilize an > out-of-band network (such > > as Ethernet) will the control channel topology i.e. the physical > > infrastructure used to realize the CCs, match the fiber topology? > > [Jonathan] The control channel topology does not need to > match the fiber > > technology. > > > > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or > are LMP TE links > > only between adjacent elements? > > [Jonathan] As LMP is currently defined, it is only between adjacent > > elements. > > > > 4. The current LMP draft does not specify how TE links > formed by LMP are > > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this > > information from LMP? > > [Jonathan] This is implementation dependent. > > > > > > Regards, > > ==== > > Adnan Ahmed > > [V] 972.503.8881 x222 [F] 972.503.8885 > > > > > > > ------_=_NextPart_001_01C11162.B9212970 Content-Type: text/html; charset="iso-8859-1" RE: LMP questions

Hi Jonathan,

How does LMP respond to adjacent link failures? i.e., how does
lmp converge on adjacent data link failures for fault location
identification? this case has not been discussed in the draft.

rgds
bhaskara

-----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Friday, July 20, 2001 2:11 PM
To: 'Adnan Ahmed'; Jonathan Lang; ccamp@ops.ietf.org
Cc: Saibal Das
Subject: RE: LMP questions


Adnan,
  In your example, you need to run an LMP control channel between B and C.
This control channel could be tunneled through A.

Thanks,
Jonathan

> -----Original Message-----
> From: Adnan Ahmed [mailto:adnan@varros.com]
> Sent: Friday, July 20, 2001 4:02 PM
> To: Jonathan Lang; ccamp@ops.ietf.org
> Cc: Saibal Das
> Subject: Re: LMP questions
>
>
> Jonathan:
>
> I have a follow up question related to your response:
>
> "Assuming that the control channels utilize an out-of-band
> network (such
> as Ethernet) will the control channel topology i.e. the physical
> infrastructure used to realize the CCs, match the fiber topology?
> [Jonathan] The control channel topology does not need to
> match the fiber
> technology."
>
> Consider this scenario involving three OXCs where:
>
> - OXCs A, B and C are connected to each other through fiber
> - Control channel CC-1 is setup b/w A & B and a control
> channel CC-2 is
> setup b/w A & C.
>
> Does your response above imply that it is possible to setup
> TE/data bearing
> links between OXCs B and C by utilizing CC-1 and CC-2 without a direct
> control channel between them?
>
> Thank you for your help.
> -- Adnan
>
>
> ----- Original Message -----
> From: "Jonathan Lang" <jplang@calient.net>
> To: "'Adnan Ahmed'" <adnan@varros.com>; <ccamp@ops.ietf.org>
> Cc: "Saibal Das" <saibal@varros.com>
> Sent: Friday, July 20, 2001 1:38 PM
> Subject: RE: LMP questions
>
>
> > Adnan,
> >   Please see inline comments.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Adnan Ahmed [mailto:adnan@varros.com]
> > Sent: Friday, July 20, 2001 10:59 AM
> > To: ccamp@ops.ietf.org
> > Cc: Saibal Das
> > Subject: LMP questions
> >
> >
> > Hello:
> >
> > I have some questions regarding LMP:
> >
> > 1. What mechanism is used to automatically setup control
> channels b/w two
> > nodes? Will the user or managing application update the
> lmpNbrTable with
> > neighbouring nodes before a node initiates control channel
> setup, or is a
> > node required to incoporate some sort of "ping" to discover
> noeghbours and
> > then initiate CC setup?
> > [Jonathan] Currently, the draft doesn't specify a mechanism to
> automatically
> > setup control channels.  There has been some work done in
> the OIF to do
> > this.
> >
> > 2. Assuming that the control channels utilize an
> out-of-band network (such
> > as Ethernet) will the control channel topology i.e. the physical
> > infrastructure used to realize the CCs, match the fiber topology?
> > [Jonathan] The control channel topology does not need to
> match the fiber
> > technology.
> >
> > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or
> are LMP TE links
> > only between adjacent elements?
> > [Jonathan] As LMP is currently defined, it is only between adjacent
> > elements.
> >
> > 4. The current LMP draft does not specify how TE links
> formed by LMP are
> > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this
> > information from LMP?
> > [Jonathan] This is implementation dependent.
> >
> >
> > Regards,
> > ====
> > Adnan Ahmed
> > [V] 972.503.8881 x222            [F] 972.503.8885
> >
> >
> >
>

------_=_NextPart_001_01C11162.B9212970-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 14:15:28 -0700 Message-ID: From: Jonathan Lang To: 'Adnan Ahmed' , Jonathan Lang , ccamp@ops.ietf.org Cc: Saibal Das Subject: RE: LMP questions Date: Fri, 20 Jul 2001 14:10:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Adnan, In your example, you need to run an LMP control channel between B and C. This control channel could be tunneled through A. Thanks, Jonathan > -----Original Message----- > From: Adnan Ahmed [mailto:adnan@varros.com] > Sent: Friday, July 20, 2001 4:02 PM > To: Jonathan Lang; ccamp@ops.ietf.org > Cc: Saibal Das > Subject: Re: LMP questions > > > Jonathan: > > I have a follow up question related to your response: > > "Assuming that the control channels utilize an out-of-band > network (such > as Ethernet) will the control channel topology i.e. the physical > infrastructure used to realize the CCs, match the fiber topology? > [Jonathan] The control channel topology does not need to > match the fiber > technology." > > Consider this scenario involving three OXCs where: > > - OXCs A, B and C are connected to each other through fiber > - Control channel CC-1 is setup b/w A & B and a control > channel CC-2 is > setup b/w A & C. > > Does your response above imply that it is possible to setup > TE/data bearing > links between OXCs B and C by utilizing CC-1 and CC-2 without a direct > control channel between them? > > Thank you for your help. > -- Adnan > > > ----- Original Message ----- > From: "Jonathan Lang" > To: "'Adnan Ahmed'" ; > Cc: "Saibal Das" > Sent: Friday, July 20, 2001 1:38 PM > Subject: RE: LMP questions > > > > Adnan, > > Please see inline comments. > > > > Thanks, > > Jonathan > > > > -----Original Message----- > > From: Adnan Ahmed [mailto:adnan@varros.com] > > Sent: Friday, July 20, 2001 10:59 AM > > To: ccamp@ops.ietf.org > > Cc: Saibal Das > > Subject: LMP questions > > > > > > Hello: > > > > I have some questions regarding LMP: > > > > 1. What mechanism is used to automatically setup control > channels b/w two > > nodes? Will the user or managing application update the > lmpNbrTable with > > neighbouring nodes before a node initiates control channel > setup, or is a > > node required to incoporate some sort of "ping" to discover > noeghbours and > > then initiate CC setup? > > [Jonathan] Currently, the draft doesn't specify a mechanism to > automatically > > setup control channels. There has been some work done in > the OIF to do > > this. > > > > 2. Assuming that the control channels utilize an > out-of-band network (such > > as Ethernet) will the control channel topology i.e. the physical > > infrastructure used to realize the CCs, match the fiber topology? > > [Jonathan] The control channel topology does not need to > match the fiber > > technology. > > > > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or > are LMP TE links > > only between adjacent elements? > > [Jonathan] As LMP is currently defined, it is only between adjacent > > elements. > > > > 4. The current LMP draft does not specify how TE links > formed by LMP are > > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this > > information from LMP? > > [Jonathan] This is implementation dependent. > > > > > > Regards, > > ==== > > Adnan Ahmed > > [V] 972.503.8881 x222 [F] 972.503.8885 > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 14:04:45 -0700 Message-ID: <001d01c11170$0646d800$171010ac@adnan> From: "Adnan Ahmed" To: "Jonathan Lang" , Cc: "Saibal Das" Subject: Re: LMP questions Date: Fri, 20 Jul 2001 16:02:15 -0700 Organization: Varros Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jonathan: I have a follow up question related to your response: "Assuming that the control channels utilize an out-of-band network (such as Ethernet) will the control channel topology i.e. the physical infrastructure used to realize the CCs, match the fiber topology? [Jonathan] The control channel topology does not need to match the fiber technology." Consider this scenario involving three OXCs where: - OXCs A, B and C are connected to each other through fiber - Control channel CC-1 is setup b/w A & B and a control channel CC-2 is setup b/w A & C. Does your response above imply that it is possible to setup TE/data bearing links between OXCs B and C by utilizing CC-1 and CC-2 without a direct control channel between them? Thank you for your help. -- Adnan ----- Original Message ----- From: "Jonathan Lang" To: "'Adnan Ahmed'" ; Cc: "Saibal Das" Sent: Friday, July 20, 2001 1:38 PM Subject: RE: LMP questions > Adnan, > Please see inline comments. > > Thanks, > Jonathan > > -----Original Message----- > From: Adnan Ahmed [mailto:adnan@varros.com] > Sent: Friday, July 20, 2001 10:59 AM > To: ccamp@ops.ietf.org > Cc: Saibal Das > Subject: LMP questions > > > Hello: > > I have some questions regarding LMP: > > 1. What mechanism is used to automatically setup control channels b/w two > nodes? Will the user or managing application update the lmpNbrTable with > neighbouring nodes before a node initiates control channel setup, or is a > node required to incoporate some sort of "ping" to discover noeghbours and > then initiate CC setup? > [Jonathan] Currently, the draft doesn't specify a mechanism to automatically > setup control channels. There has been some work done in the OIF to do > this. > > 2. Assuming that the control channels utilize an out-of-band network (such > as Ethernet) will the control channel topology i.e. the physical > infrastructure used to realize the CCs, match the fiber topology? > [Jonathan] The control channel topology does not need to match the fiber > technology. > > 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE links > only between adjacent elements? > [Jonathan] As LMP is currently defined, it is only between adjacent > elements. > > 4. The current LMP draft does not specify how TE links formed by LMP are > updated into OSPF. Is this LMPs responsiblity or will OSPF pull this > information from LMP? > [Jonathan] This is implementation dependent. > > > Regards, > ==== > Adnan Ahmed > [V] 972.503.8881 x222 [F] 972.503.8885 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 13:43:54 -0700 Message-ID: From: Jonathan Lang To: 'Adnan Ahmed' , ccamp@ops.ietf.org Cc: Saibal Das Subject: RE: LMP questions Date: Fri, 20 Jul 2001 13:38:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Adnan, Please see inline comments. Thanks, Jonathan -----Original Message----- From: Adnan Ahmed [mailto:adnan@varros.com] Sent: Friday, July 20, 2001 10:59 AM To: ccamp@ops.ietf.org Cc: Saibal Das Subject: LMP questions Hello: I have some questions regarding LMP: 1. What mechanism is used to automatically setup control channels b/w two nodes? Will the user or managing application update the lmpNbrTable with neighbouring nodes before a node initiates control channel setup, or is a node required to incoporate some sort of "ping" to discover noeghbours and then initiate CC setup? [Jonathan] Currently, the draft doesn't specify a mechanism to automatically setup control channels. There has been some work done in the OIF to do this. 2. Assuming that the control channels utilize an out-of-band network (such as Ethernet) will the control channel topology i.e. the physical infrastructure used to realize the CCs, match the fiber topology? [Jonathan] The control channel topology does not need to match the fiber technology. 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE links only between adjacent elements? [Jonathan] As LMP is currently defined, it is only between adjacent elements. 4. The current LMP draft does not specify how TE links formed by LMP are updated into OSPF. Is this LMPs responsiblity or will OSPF pull this information from LMP? [Jonathan] This is implementation dependent. Regards, ==== Adnan Ahmed [V] 972.503.8881 x222 [F] 972.503.8885 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 09:04:33 -0700 Message-ID: <006d01c11145$aedbcaa0$171010ac@adnan> From: "Adnan Ahmed" To: Cc: "Saibal Das" Subject: LMP questions Date: Fri, 20 Jul 2001 10:59:11 -0700 Organization: Varros Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C1110B.01BF6F00" This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C1110B.01BF6F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello: I have some questions regarding LMP: 1. What mechanism is used to automatically setup control channels b/w = two nodes? Will the user or managing application update the lmpNbrTable = with neighbouring nodes before a node initiates control channel setup, = or is a node required to incoporate some sort of "ping" to discover = noeghbours and then initiate CC setup? 2. Assuming that the control channels utilize an out-of-band network = (such as Ethernet) will the control channel topology i.e. the physical = infrastructure used to realize the CCs, match the fiber topology? 3. Can LMP TE links span multiple OXCs (as FA-LSPs do) or are LMP TE = links only between adjacent elements? 4. The current LMP draft does not specify how TE links formed by LMP are = updated into OSPF. Is this LMPs responsiblity or will OSPF pull this = information from LMP? Regards, =3D=3D=3D=3D Adnan Ahmed [V] 972.503.8881 x222 [F] 972.503.8885 ------=_NextPart_000_006A_01C1110B.01BF6F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello:
 
I have some questions regarding = LMP:
 
1. What mechanism is used to = automatically setup=20 control channels b/w two nodes? Will the user or managing application = update the=20 lmpNbrTable with neighbouring nodes before a node initiates control = channel=20 setup, or is a node required to incoporate some sort of "ping" to = discover=20 noeghbours and then initiate CC setup?
 
2. Assuming that the control channels = utilize an=20 out-of-band network (such as Ethernet) will the control channel topology = i.e.=20 the physical infrastructure used to realize the CCs, match the fiber=20 topology?
 
3. Can LMP TE links span multiple = OXCs (as=20 FA-LSPs do) or are LMP TE links only between adjacent = elements?
 
4. The current LMP draft does not = specify how TE=20 links formed by LMP are updated into OSPF. Is this LMPs responsiblity or = will=20 OSPF pull this information from LMP?
 

Regards,
=3D=3D=3D=3D
Adnan = Ahmed
[V] 972.503.8881=20 x222            = [F]=20 972.503.8885
 
 
------=_NextPart_000_006A_01C1110B.01BF6F00-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jul 2001 07:52:39 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F04405DC9@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: ccamp@ops.ietf.org Subject: draft-tempest-mpls-ccamp-rsvp-resync-00.txt Date: Fri, 20 Jul 2001 10:48:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1112A.FC7E0360" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1112A.FC7E0360 Content-Type: text/plain; charset="iso-8859-1" The draft "draft-tempest-mpls-ccamp-rsvp-resync-00.txt" has been submitted http://search.ietf.org/internet-drafts/draft-tempest-mpls-ccamp-rsvp-resync- 00.txt Abstract: This draft describes a mechanism for recovery after control channel failure in RSVP-TE. The draft introduces a procedure for state re-synchronization between two neighboring LSRs. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com ------_=_NextPart_001_01C1112A.FC7E0360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-tempest-mpls-ccamp-rsvp-resync-00.txt

The = draft "draft-tempest-mpls-ccamp-rsvp-resync-00.txt" has been = submitted

http://search.ietf.org/internet-drafts/draft-tempest-m= pls-ccamp-rsvp-resync-00.txt

Abstract:

This draft describes a mechanism for recovery after control = channel failure in RSVP-TE.  The draft introduces a procedure for = state re-synchronization between two neighboring LSRs.   =

Regards;

Osama Aboul-Magd

Nortel = Networks

P.O. = Box 3511, Station "C"

Ottawa, = ON, Canada

K1Y - = 4H7

Tel: = 613-763-5827

e.mail: = osama@nortelnetworks.com

------_=_NextPart_001_01C1112A.FC7E0360-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jul 2001 14:47:29 -0700 Message-ID: <002501c110a6$63d259b0$a13d2c42@tpidl6z5ynrc41> From: "S Kalipatnapu" To: "Eric Gray" , "manoj juneja" Cc: , Subject: Re: Bi-directional LSPs Incompatibility Date: Thu, 19 Jul 2001 18:58:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, MPLS Label Switched Paths are inherently uni-directional, while GMPLS lambda swithed paths are inherently bi-directional. Given that the two approaches in establishing/reserving resources for a path in the network need not be strictly the same. Regards, --Sitaram ----- Original Message ----- From: "Eric Gray" To: "manoj juneja" Cc: ; Sent: Thursday, July 19, 2001 10:58 AM Subject: Re: Bi-directional LSPs Incompatibility > Manoj , > > George's point is that strict alignment does not need to be a goal. > If you look at the O-UNI as a user of GMPLS services, there is no > reason to expect this user to use all available services. > > -- > Eric Gray > > You wrote: > > > Hi George, > > As long as both the documents are not aligned, we can say there > > is some incompatibility. I think one can argue it in both ways. Is it a > > incompatibility or a feature that GMPLS offers but UNI is unable to make use > > of it ? > > > > Regards, > > manoj. > > > > >From: George Swallow > > >To: "manoj juneja" > > >CC: ccamp@ops.ietf.org, swallow@cisco.com > > >Subject: Re: Bi-directional LSPs Incompatibility > > >Date: Wed, 18 Jul 2001 18:23:39 -0400 > > > > > > > Hi All, > > > > There is some incompatibility in documents of OIF > > > > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) > > > > related to bidirectional LSPs. OIF's O-UNI document says [docId > > > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must > > > > insert a RESV_CONFIRM object in the RESV message and should wait for > > > > ResvConf message before start transmitting data. > > > > But, the IETF document says the terminator node process path message > > > > as usual with the exception that the upstream label can immediately be > > > > used to transport data traffic associated with the LSP upstream towards > > > > the initiator. > > > > > > > > Please Help. > > > > > > > > Regards, > > > > manoj. > > > > > >I don't see a problem in this case. Having the two ends more > > >constrained than the middle as to when a circuit can be considered in > > >service doesn't seem to present a problem. > > > > > >But my personal opinion is that the RESV Conf should be optional for > > >the UNI. > > > > > >...George > > > > > >================================================================== > > >George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jul 2001 07:59:52 -0700 Message-ID: <3B56F57A.8F8E1AA1@sandburst.com> Date: Thu, 19 Jul 2001 10:58:02 -0400 From: Eric Gray MIME-Version: 1.0 To: manoj juneja Cc: swallow@cisco.com, ccamp@ops.ietf.org Subject: Re: Bi-directional LSPs Incompatibility Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj , George's point is that strict alignment does not need to be a goal. If you look at the O-UNI as a user of GMPLS services, there is no reason to expect this user to use all available services. -- Eric Gray You wrote: > Hi George, > As long as both the documents are not aligned, we can say there > is some incompatibility. I think one can argue it in both ways. Is it a > incompatibility or a feature that GMPLS offers but UNI is unable to make use > of it ? > > Regards, > manoj. > > >From: George Swallow > >To: "manoj juneja" > >CC: ccamp@ops.ietf.org, swallow@cisco.com > >Subject: Re: Bi-directional LSPs Incompatibility > >Date: Wed, 18 Jul 2001 18:23:39 -0400 > > > > > Hi All, > > > There is some incompatibility in documents of OIF > > > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) > > > related to bidirectional LSPs. OIF's O-UNI document says [docId > > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must > > > insert a RESV_CONFIRM object in the RESV message and should wait for > > > ResvConf message before start transmitting data. > > > But, the IETF document says the terminator node process path message > > > as usual with the exception that the upstream label can immediately be > > > used to transport data traffic associated with the LSP upstream towards > > > the initiator. > > > > > > Please Help. > > > > > > Regards, > > > manoj. > > > >I don't see a problem in this case. Having the two ends more > >constrained than the middle as to when a circuit can be considered in > >service doesn't seem to present a problem. > > > >But my personal opinion is that the RESV Conf should be optional for > >the UNI. > > > >...George > > > >================================================================== > >George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jul 2001 04:09:42 -0700 Message-Id: <200107191104.HAA27928@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-li-shared-mesh-restoration-00.txt Date: Thu, 19 Jul 2001 07:04:48 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RSVP-TE Extensions For Shared-Mesh Restoration in Transport Networks Author(s) : G. Li et al. Filename : draft-li-shared-mesh-restoration-00.txt Pages : 17 Date : 18-Jul-01 Efficient techniques for rapid restoration must be addressed within GMPLS. This document describes extensions to GMPLS and RSVP-TE signaling in support of shared mesh restoration. Shared mesh restoration describes restoration plans in which restoration capacity is shared across multiple independent failures. In particular, this document proposes extensions enabling reservation of restoration capacity, LSP restoration, LSP reversion and LSP deletion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-li-shared-mesh-restoration-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-li-shared-mesh-restoration-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010718142039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-li-shared-mesh-restoration-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-li-shared-mesh-restoration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142039.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jul 2001 17:00:13 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C901AF2684@main.mahinetworks.com> From: Abhimanyu Das To: 'Giora Unger' Cc: "'ccamp@ops.ietf.org'" Subject: RE: GMPLS questions Date: Wed, 18 Jul 2001 16:58:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Hi, Just replying to your first question about forcing explicit lambdas, along with explicit route for an LSP. Couldnt the Explicit Label Control subobject (mentioned in the GMPLS signaling functional description, draft-ietf-mpls-generalized-signaling-04.txt sec 6), within the explicit route object be used for this purpose. It seems to me that thats the reason the explicit label control subobject was introduced. Regards, Abhimanyu > > The questions: > > 1. Given such an LSR, can we FORCE it to switch between a two specific > lambdas ? Two mechanisms described in the document imply that > it's possible, > but both are not clear-cut: > > a. "Explicit Route" - in section 9.13. As far as I > understood, if we define > the Explicit Route with a list of "strict Simple Abstract > Nodes", and in > case that the "abstract node" concept can also express a > specific lambda, we > can achieve the above. > Am I correct ? How is the Label Restriction mechanism (below) > related to > this mechanism ? > > The main doubt was raised due the following line (in 9.13): > "Note also that an explicit route is altered by intermediate > LSRs during its > progression towards the destination." > Does it mean we can't define an Explicit Route that would be > obeyed all > along the -being-established path ? > > b. "Label Restriction by the Upstream Node" - in section 9.8 > it is implied > that such a restriction is possible to a set of lambdas. Can > "set" be also > interpreted as a single lambda to be forced ? > Additionally - in the last paragraph of section 9.8, it's written: > "A Label Set may be present across multiple hops. In this > case each node > generates its own outgoing Label Set, possibly based on the > incoming Label > Set and the node's hardware capabilities." > Hence, is it possible to force specific lambdas in all the > LSRs along the > path, according to decisions that are not subject to > manipulations by the > LSR along the way ? > > > specification a "Time To > Live" and a message to disconnect an LSP. However, we didn't > find such a > mechanism in CR-LDP. > Which mechanism should be employed in order to disconnect an > LSP in GMPLS ? > > > ------------------------------------------- > Giora Unger > Orika Optical Networks Ltd. > www.orikanetworks.com > Phone: +972-3-6091665 ext. 29 > Fax: +972-3-6091667 > E-mail: giora@orikanetworks.com > ------------------------------------------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jul 2001 15:47:30 -0700 From: "manoj juneja" To: swallow@cisco.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Bi-directional LSPs Incompatibility Date: Wed, 18 Jul 2001 15:46:38 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi George, As long as both the documents are not aligned, we can say there is some incompatibility. I think one can argue it in both ways. Is it a incompatibility or a feature that GMPLS offers but UNI is unable to make use of it ? Regards, manoj. >From: George Swallow >To: "manoj juneja" >CC: ccamp@ops.ietf.org, swallow@cisco.com >Subject: Re: Bi-directional LSPs Incompatibility >Date: Wed, 18 Jul 2001 18:23:39 -0400 > > > Hi All, > > There is some incompatibility in documents of OIF > > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) > > related to bidirectional LSPs. OIF's O-UNI document says [docId > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must > > insert a RESV_CONFIRM object in the RESV message and should wait for > > ResvConf message before start transmitting data. > > But, the IETF document says the terminator node process path message > > as usual with the exception that the upstream label can immediately be > > used to transport data traffic associated with the LSP upstream towards > > the initiator. > > > > Please Help. > > > > Regards, > > manoj. > >I don't see a problem in this case. Having the two ends more >constrained than the middle as to when a circuit can be considered in >service doesn't seem to present a problem. > >But my personal opinion is that the RESV Conf should be optional for >the UNI. > >...George > >================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jul 2001 15:24:32 -0700 Message-Id: <200107182223.SAA12472@telescope.cisco.com> To: "manoj juneja" cc: ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Bi-directional LSPs Incompatibility Date: Wed, 18 Jul 2001 18:23:39 -0400 From: George Swallow > Hi All, > There is some incompatibility in documents of OIF > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) > related to bidirectional LSPs. OIF's O-UNI document says [docId > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must > insert a RESV_CONFIRM object in the RESV message and should wait for > ResvConf message before start transmitting data. > But, the IETF document says the terminator node process path message > as usual with the exception that the upstream label can immediately be > used to transport data traffic associated with the LSP upstream towards > the initiator. > > Please Help. > > Regards, > manoj. I don't see a problem in this case. Having the two ends more constrained than the middle as to when a circuit can be considered in service doesn't seem to present a problem. But my personal opinion is that the RESV Conf should be optional for the UNI. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jul 2001 15:09:28 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Difference in IETF and OIF Signal Type Values Date: Wed, 18 Jul 2001 15:06:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There is some mismatch in signal type values supported in OIF and IETF. As per Service discovery procedure of LMP, it supports SDH signal types as VC-3, VC-3 via AU-3, VC-4 etc. It does not support VC-11/VC-12/VC-2 etc. The OIF document support the LOVCs only by means of hierarchical LSPs where the HOVCs are established as forwarding adjacency (FA). But GMPLS ccamp-gmpls-sdh-sonet-01.txt draft supports these LOVCs (VC-11/VC-12 etc) without even supporting hierarchical LSPs. Please Help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jul 2001 15:07:49 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bi-directional LSPs Incompatibility Date: Wed, 18 Jul 2001 15:02:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There is some incompatibility in documents of OIF (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) related to bidirectional LSPs. OIF's O-UNI document says [docId oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must insert a RESV_CONFIRM object in the RESV message and should wait for ResvConf message before start transmitting data. But, the IETF document says the terminator node process path message as usual with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. Please Help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jul 2001 10:25:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 10:24:22 -0700 Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jul 2001 10:25:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 10:24:43 -0700 Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jul 2001 06:59:01 -0700 Message-ID: From: Jimmy Gendron To: "'ccamp@ops.ietf.org'" Subject: UNI Generalized label Date: Tue, 17 Jul 2001 09:56:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a question regarding the Generalized label. For example, if I have an LSR with 2 OC-192c line cards connected with a SONET equipment and that the ports between are mapped. If I want to connect to another LSR connected to the same optical network with 2 OC-192c line cards, I use RSVP to do it. I request a G-label, for continuous concatenation. When the connection is created throught the optical network, do the ingress LSR receive a G-label...? And does it need to use that label to send packets over that interface or the interface is just set to up and running and advertised in a routing protocol as a TE link? Thank you very much, Jimmy Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jul 2001 03:56:37 -0700 Message-Id: <200107171052.GAA10366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ip-optical@lists.bell-labs.com, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-many-ical-ski-04.txt Date: Tue, 17 Jul 2001 06:52:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SKiCal - an extension of iCalendar Author(s) : G. FitzPatrick, P. Lannero, N. Hjelm Filename : draft-many-ical-ski-04.txt Pages : 76 Date : 16-Jul-01 This Memo defines the SKiCal format. SKiCal is a machine-readable format for the interchange of enhanced yellow-page directory listings. SkiCal expands the traditional property-set of name, address, telephone number and business category, adding structured information about people, places, things, activities and the conditions and terms for interaction with resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-ical-ski-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-many-ical-ski-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-many-ical-ski-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010716153701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-many-ical-ski-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-many-ical-ski-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153701.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jul 2001 10:48:09 -0700 Reply-To: From: "Mohan Verma" To: "'Giora Unger'" , Cc: Subject: RE: GMPLS questions Date: Mon, 16 Jul 2001 22:58:28 +1000 Message-Id: <000501c10df7$02a474e0$1f06140a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Hi unger, My comments are inline and are to my best-- -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Giora Unger Sent: Tuesday, July 17, 2001 12:45 AM To: 'ccamp@ops.ietf.org' Cc: 'tnadeau@cisco.com' Subject: GMPLS questions Hi everybody, It's going to be a long one. Sorry, but I couldn't contain everything I don't understand in a shorter message :-) After reading the GMPLS architecture draft, there are still some issues regarding GMPLS that I'd like to clarify. I'll start with the background, such that you'll have better understanding of my questions: We're working in the domain of wavelength switching networks (LSC interfaces in the GMPLS terminology). Lets examine (briefly) such a network; Multiple optical switches are distributed in the network. They are GMPLS LSRs, which contain LSC interfaces, capable of switching between an incoming lambda and an outgoing lambda. Those LSRs can be manufactured by various vendors, and the only thing one can be sure about them is the fact that they claim to support GMPLS. We'd like to build a system in which a centralized entity decides which switching operations are to be performed in each of those LSRs, and further would see to it that those switching operations were actually executed. We're well aware that GMPLS is distributed in nature, and that we're taking it to the centralized direction. However, we'd like to verify that we're not missing anything. The questions: 1. Given such an LSR, can we FORCE it to switch between a two specific lambdas ? Two mechanisms described in the document imply that it's possible, but both are not clear-cut: a. "Explicit Route" - in section 9.13. As far as I understood, if we define the Explicit Route with a list of "strict Simple Abstract Nodes", and in case that the "abstract node" concept can also express a specific lambda, we can achieve the above. Am I correct ? How is the Label Restriction mechanism (below) related to this mechanism ? The main doubt was raised due the following line (in 9.13): "Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination." Does it mean we can't define an Explicit Route that would be obeyed all along the -being-established path ? b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied that such a restriction is possible to a set of lambdas. Can "set" be also interpreted as a single lambda to be forced ? Additionally - in the last paragraph of section 9.8, it's written: "A Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities." Hence, is it possible to force specific lambdas in all the LSRs along the path, according to decisions that are not subject to manipulations by the LSR along the way ? mohan>The two ways you mentioned will work. 2. Lets assume that our centralized entity decided to create a lightpath between two Edge Nodes, A and B. Must the GMPLS messages actually creating the LSP be sent from A along the actual path, or can that centralized entity function as the sender ? In other words - can the messages for actual LSP creation be sent not along the physical path of the LSP ? mohan>I suppose you can do with the help of out of band control channel but one has to make sure of the cross connect updations at each LSR. 3. We understood that there is no problem with having uni-directional LSPs also in GMPLS wavelength switching environments. We'd like to verify we didn't miss anything. mohan>We also thought the same way... 4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To Live" and a message to disconnect an LSP. However, we didn't find such a mechanism in CR-LDP. Which mechanism should be employed in order to disconnect an LSP in GMPLS ? mohan>In CRLDP you can send either abort message in response awaited state or Release message in established state to tear down the tunnel, however the trigger should be from the manager. 5. Do you see any flaws in the general scheme I described above ? That is - in utilizing GMPLS optical switches (LSRs) as relatively dumb entities which practically obey the commands of a centralized entity. mohan>I think we can talk of the same pros and cons of centralized vs distributed..The only claim of GMPLS is to provide automatic provision switching and traffic engineering which needs better restoration and resilence properties..Hence people prefer distributed.. Thanks a lot and sorry for the flood of questions ;-) ------------------------------------------- Giora Unger Orika Optical Networks Ltd. www.orikanetworks.com Phone: +972-3-6091665 ext. 29 Fax: +972-3-6091667 E-mail: giora@orikanetworks.com ------------------------------------------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jul 2001 10:43:32 -0700 Reply-To: From: "Vishal Sharma" To: "Giora Unger" , Cc: Subject: RE: GMPLS questions Date: Mon, 16 Jul 2001 10:41:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hi Giora, I'll take a first stab at clarifying some of your doubts. I am sure others will expand on what I say. Please see some responses below. Thanks, -Vishal >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >Behalf Of Giora Unger >Sent: Monday, July 16, 2001 7:45 AM >To: 'ccamp@ops.ietf.org' >Cc: 'tnadeau@cisco.com' >Subject: GMPLS questions > > >Hi everybody, > >It's going to be a long one. Sorry, but I couldn't contain everything I >don't understand in a shorter message :-) > >After reading the GMPLS architecture draft, there are still some issues >regarding GMPLS that I'd like to clarify. >I'll start with the background, such that you'll have better understanding >of my questions: >We're working in the domain of wavelength switching networks (LSC >interfaces >in the GMPLS terminology). > >Lets examine (briefly) such a network; >Multiple optical switches are distributed in the network. They are GMPLS >LSRs, which contain LSC interfaces, capable of switching between >an incoming >lambda and an outgoing lambda. >Those LSRs can be manufactured by various vendors, and the only thing one >can be sure about them is the fact that they claim to support GMPLS. >We'd like to build a system in which a centralized entity decides which >switching operations are to be performed in each of those LSRs, and further >would see to it that those switching operations were actually executed. >We're well aware that GMPLS is distributed in nature, and that we're taking >it to the centralized direction. However, we'd like to verify that >we're not >missing anything. > >The questions: > >1. Given such an LSR, can we FORCE it to switch between a two specific >lambdas ? Two mechanisms described in the document imply that it's >possible, >but both are not clear-cut: > >a. "Explicit Route" - in section 9.13. As far as I understood, if we define >the Explicit Route with a list of "strict Simple Abstract Nodes", and in >case that the "abstract node" concept can also express a specific >lambda, we >can achieve the above. >Am I correct ? How is the Label Restriction mechanism (below) related to >this mechanism ? The abstract node will be able to represent an individual lambda if each lambda is explicitly identified as an "interface" in the routing protocol. For example, with an IP address (which would be wasteful) or using router ID and unnumbered links (possibly as described in draft http://search.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-01.txt; which would help to conserve IP addresses). If you are using link bundling, however, it may be more difficult to force the selection of a particular wavelength at each hop, since the choice of which wavelength to use would be a local decision. Actually, even in this case, perhaps the label set can be used to restrict the choice of the wavelength at each hop in the following way. The first node (or central entity) picks the desired wavelength and encodes it into the label set (which would be a singleton in this case). At each subsequent hop, when making a local wavelength selection decision, the node would ensure that it honored the restrictions in the label set. This would guarantee that each node picked the same wavelength for the lightpath. >The main doubt was raised due the following line (in 9.13): >"Note also that an explicit route is altered by intermediate LSRs >during its >progression towards the destination." >Does it mean we can't define an Explicit Route that would be obeyed all >along the -being-established path ? I am not entirely sure what the above sentence means. Perhaps it alludes to the fact that the abstract nodes are deleted from the list in the explicit route as the setup message progresses towards the destination. Or it may refer to the fact that in some cases an abstract node may have to be expanded (by the node preceding the abstract node or by the first node in the abstract node) to determine the exact sequence of nodes that the message is to pass through. In any case, however, if the exact sequence of LSRs that the lightpath is to pass through is known to the central entity, then it should be possible to define an explicit route that is obeyed all along the being-established path (in the sense that the message will pass through the exact sequence of nodes specified; whether it will use the same wavelength at each hop may be determined either with the label set or bundling considerations). >b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied >that such a restriction is possible to a set of lambdas. Can "set" be also >interpreted as a single lambda to be forced ? Yes, the "set" may contain a single element. >Additionally - in the last paragraph of section 9.8, it's written: >"A Label Set may be present across multiple hops. In this case each node >generates its own outgoing Label Set, possibly based on the incoming Label >Set and the node's hardware capabilities." >Hence, is it possible to force specific lambdas in all the LSRs along the >path, according to decisions that are not subject to manipulations by the >LSR along the way ? If the LSRs in question have no wavelength conversion capabilities then simply selecting the desired wavelength and putting it in the label set at the starting LSR will force the selection of the same wavelength at all hops along the path (or the rejection of the lightpath, if that wavelength is unavailable). If, however, the intermediate nodes are capable of wavlength conversion, then it is possible that a wavelength conversion capable intermediate node may select a different outgoing wavelength if the desired wavelength is unavailable but a different one is available, and possibily drop the label set completely or leave it unchanged, or change it to the outgoing wavelength that it selected (depending on the implementation). I am not sure off hand how one would force the choice of a specific wavelength in that case. > >2. Lets assume that our centralized entity decided to create a lightpath >between two Edge Nodes, A and B. Must the GMPLS messages actually creating >the LSP be sent from A along the actual path, or can that >centralized entity >function as the sender ? >In other words - can the messages for actual LSP creation be sent not along >the physical path of the LSP ? Not sure what you mean here. Do you mean you still want to use RSVP-TE or CR-LDP for path setup, but you want the messages to emanate from the central entity as opposed to the head end LSR? If so, you could, technically, simply embed the specific protocol messages into whatever protocol the central entity uses to "talk" to each LSR along the lightpath, and let the LSR interpret those protocol messages as it would if they had been received on an interface connected to an upstream LSR along that lightpath. Another option would be for the central entity to issue a "setup" command to the head end LSR, together with the explicit route (and wavelength chosen), and let the head end initiate the ligthpath setup. >3. We understood that there is no problem with having uni-directional LSPs >also in GMPLS wavelength switching environments. We'd like to verify we >didn't miss anything. Don't think unidirectional lightpaths should be a problem. >4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To >Live" and a message to disconnect an LSP. However, we didn't find such a >mechanism in CR-LDP. >Which mechanism should be employed in order to disconnect an LSP in GMPLS ? >5. Do you see any flaws in the general scheme I described above ? That is - >in utilizing GMPLS optical switches (LSRs) as relatively dumb >entities which >practically obey the commands of a centralized entity. Not really, except that the GMPLS switches wouldn't be operating in a truly distributed way, so that you may not derive some of the benefits that come from doing that. Also, you'd have to worry about the reliability of the central entity and of its communication path to the individual LSRs in your network. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jul 2001 06:45:42 -0700 Message-ID: <200353E89AB7BD43BC64A5EA078A8E7408F627@orika-srv.ORIKANETWORKS.NET> From: Giora Unger To: "'ccamp@ops.ietf.org'" Cc: "'tnadeau@cisco.com'" Subject: GMPLS questions Date: Mon, 16 Jul 2001 16:45:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Hi everybody, It's going to be a long one. Sorry, but I couldn't contain everything I don't understand in a shorter message :-) After reading the GMPLS architecture draft, there are still some issues regarding GMPLS that I'd like to clarify. I'll start with the background, such that you'll have better understanding of my questions: We're working in the domain of wavelength switching networks (LSC interfaces in the GMPLS terminology). Lets examine (briefly) such a network; Multiple optical switches are distributed in the network. They are GMPLS LSRs, which contain LSC interfaces, capable of switching between an incoming lambda and an outgoing lambda. Those LSRs can be manufactured by various vendors, and the only thing one can be sure about them is the fact that they claim to support GMPLS. We'd like to build a system in which a centralized entity decides which switching operations are to be performed in each of those LSRs, and further would see to it that those switching operations were actually executed. We're well aware that GMPLS is distributed in nature, and that we're taking it to the centralized direction. However, we'd like to verify that we're not missing anything. The questions: 1. Given such an LSR, can we FORCE it to switch between a two specific lambdas ? Two mechanisms described in the document imply that it's possible, but both are not clear-cut: a. "Explicit Route" - in section 9.13. As far as I understood, if we define the Explicit Route with a list of "strict Simple Abstract Nodes", and in case that the "abstract node" concept can also express a specific lambda, we can achieve the above. Am I correct ? How is the Label Restriction mechanism (below) related to this mechanism ? The main doubt was raised due the following line (in 9.13): "Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination." Does it mean we can't define an Explicit Route that would be obeyed all along the -being-established path ? b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied that such a restriction is possible to a set of lambdas. Can "set" be also interpreted as a single lambda to be forced ? Additionally - in the last paragraph of section 9.8, it's written: "A Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities." Hence, is it possible to force specific lambdas in all the LSRs along the path, according to decisions that are not subject to manipulations by the LSR along the way ? 2. Lets assume that our centralized entity decided to create a lightpath between two Edge Nodes, A and B. Must the GMPLS messages actually creating the LSP be sent from A along the actual path, or can that centralized entity function as the sender ? In other words - can the messages for actual LSP creation be sent not along the physical path of the LSP ? 3. We understood that there is no problem with having uni-directional LSPs also in GMPLS wavelength switching environments. We'd like to verify we didn't miss anything. 4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To Live" and a message to disconnect an LSP. However, we didn't find such a mechanism in CR-LDP. Which mechanism should be employed in order to disconnect an LSP in GMPLS ? 5. Do you see any flaws in the general scheme I described above ? That is - in utilizing GMPLS optical switches (LSRs) as relatively dumb entities which practically obey the commands of a centralized entity. Thanks a lot and sorry for the flood of questions ;-) ------------------------------------------- Giora Unger Orika Optical Networks Ltd. www.orikanetworks.com Phone: +972-3-6091665 ext. 29 Fax: +972-3-6091667 E-mail: giora@orikanetworks.com ------------------------------------------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jul 2001 04:04:48 -0700 Message-Id: <200107161059.GAA10061@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-shared-fastreroute-00.txt Date: Mon, 16 Jul 2001 06:59:43 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Signaling Extensions for Shared Fast Rerouting Author(s) : A. Iwata Filename : draft-iwata-mpls-shared-fastreroute-00.txt Pages : 17 Date : 13-Jul-01 This document proposes an enhanced scheme for fast rerouting which provides means of quickly repairing LSPs in cases of link/node failures. It also provides for the sharing of backup LSPs and their resources and thus allows minimization of requirements for backup resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-shared-fastreroute-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010713124106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-shared-fastreroute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-shared-fastreroute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124106.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 Jul 2001 07:16:09 -0700 From: "Torsten Mueller" To: ccamp@ops.ietf.org Message-ID: <80256A88.004D9B44.00@marconicomms.com> Date: Fri, 13 Jul 2001 16:12:12 +0200 Subject: splicing in draft-ietf-ccamp-gmpls-architecture-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hallo, draft-ietf-ccamp-gmpls-architecture-00.txt mentions in 9.13 Explicit Routing and Explicit Label Control In particular, the explicit label control in the explicit route allows terminating an LSP on a particular outgoing port to an egress node. This can also be used when it is desirable to "splice" two LSPs together, i.e. where the tail of the first LSP would be "spliced" into the head of the second LSP. Does this mean, that it is possible to splice different types of LSP into each other? E.g., could I terminate a PSC LSP, then use a SDH LSP and finally, again, a PSC LSP instead of using the hierarchical approach? If not, what is the intent of "splicing"? Thanks, Torsten Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 12 Jul 2001 12:07:04 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bi-directional LSPs Incompatibility Date: Thu, 12 Jul 2001 12:05:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There is some incompatibility in documents of OIF(oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt) related to bidirectional LSPs. OIF's O-UNI document says [docId oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must insert a RESV_CONFIRM object in the RESV message and should wait for ResvConf message before start transmitting data. But, the IETF document says the terminator node process path message as usual with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jul 2001 23:05:45 -0700 Reply-To: From: "Srikanth" To: Subject: Associating an Entity with a non-PSC interface Date: Thu, 12 Jul 2001 11:13:48 +0530 Message-Id: <000a01c10a95$9f9c25a0$3006140a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, In the case of Generalized Cr-Ldp running between two routers, connected by a non-PSC interface, LDP session should be present between the two for establishment of tunnels. However, draft-ietf-mpls-ldp-mib-07.txt mentions only PSC Parameters. Then, how do we associate an Entity with a non-PSC Interface? Thanks in advance, Srikanth Narayanan. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jul 2001 14:45:08 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Difference in IETF and OIF Signal Type Values Date: Wed, 11 Jul 2001 14:42:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There is some mismatch in signal type values supported in OIF and IETF. As per Service discovery procedure of LMP, it supports SDH signal types as VC-3, VC-3 via AU-3, VC-4 etc. It does not support VC- 11/VC-12/VC-2 etc. But GMPLS ccamp-gmpls-sdh-sonet-01.txt draft supports these LOVCs (VC-11/VC-12 etc). Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 10 Jul 2001 08:38:24 -0700 Cc: ccamp , "t1x1.5" , q11/15 Message-ID: <3B4B2112.19EC16F5@lucent.com> Date: Tue, 10 Jul 2001 17:36:50 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Malcolm Betts Original-CC: ccamp , "t1x1.5" , q11/15 Subject: Re: arbitrary contiguous concatenation question Content-Type: multipart/mixed; boundary="------------529A60BC86E4E9B37CA97F7E" This is a multi-part message in MIME format. --------------529A60BC86E4E9B37CA97F7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Malcolm, I agree with you, and that's why I wrote the email. I hadn't noticed this issue of "STS-1 concatenation" until this morning unfortunately. As the draft-ietf-ccamp-gmpls-sonet-sdh-01.txt document isn't approved yet, it isn't too late to correct... Some background for you. IETF is defining signalling support for concatenated STS/VC signals, which are not defined in T1.105 or G.707. One of those is "arbitrary contiguous concatenation" of STS-1 signals: STS-Xc, with X > 1 (e.g. 2,3,4,5,6,7,8,...). Refer to appendix 3 of http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt Some background for other readers. In G.707 AU-3 concatenation has never been defined, only AU-4 concatenation (G.707 1996 AU-4-2c, AU-4-3c, etc). In T1.105 1995 STS concatenation has been defined for STS-Nc with N restricted to 3,6,9,12,15,etc, but not for any other value of N. Essentially this is equal to AU-4 concatenation. Both G.707 and T1.105 have restricted this concatenation in their 2000 versions to AU-4-4c/STS-12c, AU-4-16c/STS-48c, etc. Arbitrary contiguous concatenation of STS-1 signals (STS-Xc, X>1) hasn't been defined up to so far in any transport plane standard. And if we would define it as true "contiguous" concatenation then an STS-Xc would use STS-1/AU-3 timeslots TSi, TSi+1, .., TSi+X. This would imply that the STS-1-3c and the STS-3c are not transported via the same timeslots. Same for STS-1-6c and STS-3c-2c, etc. The text in appendix 3 of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt should in this case not mix AU-4 with STS-1. AU-4-Xc and STS-3c-Xc are equivalent. STS-1-Xc and AU-3-Xc are equivalent. STS-1-(3X)c and STS-3c-Xc are NOT equivalent. Note that the STS SPEs associated with STS-1-(3X)c and STS-3c-Xc are the same. Those are simply STS-(3X)c SPE signals. As I wasn't involved from the start in this work, I do not know what the supporters of arbitrary contiguous concatenation of STS-1 signals intended to define. I am looking forward to more input from those. Regards, Maarten > Malcolm Betts wrote: > > Maarten, the term "contiguous" may be confusing when applied in the context of > the two stage multiplexing of AU-3's into an AUG (to occupy the same "space" > as a AU-4) then into a STM-N (with N>1). The three STS-1 (AU-3) pointers for > an STS-3c (VC-4) payload are adjacent (contiguous) within the OC-3N (STM-N) > frame. For AU-4N (or STS-3N) and above concatenation, the pointers and > payloads are contiguous (adjacent) within the STM-N frame. > > This is well know and has been in existence since about 1988 - the vintage of > the first versions of the SONET standard T1.105 and the original SDH standards > G.707, G.708 and G.709 - with numerous examples of interworking between SONET > and SDH and between vendors. > > Malcolm Betts > > Advanced Network Technology > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > FAX: +1 613 763 6608 (ESN 393) > email: betts01@nortelnetworks.com > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, July 10, 2001 5:14 AM > To: ccamp > Cc: t1x1.5; q11/15 > Subject: arbitrary contiguous concatenation question > > All, > > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling support for > arbitrary > contiguous concatenation in appendix 3. Looking a bit more into this arbitrary > > concatenation from the transport plane, I came across a question with respect > to > the definition of "contiguous STS-1/AU-3 timeslots". Let me introduce this > question: > > Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within an STM-4) as > follows > > Time 111 > Slot 123456789012123456789 > > B 123412341234123412341... > A 111122223333111122223... > > AU-3 timeslots have a TimeSlot number and a (B,A) number, with TS1 associated > with (1,1) and TS12 associated with (4,3). > > Note - the figure in the pre-published version of G.707 > doesn't show the timeslot numbering in a correct manner. > > and the AU-4 numbering is as follows (figure 7-24/G.707) > > Time > Slot 123412341234123412341 > > B 123412341234123412341... > A 000000000000000000000... > > An AU-4 [STS-3c] is as such essentially a "non-contiguous" concatenation of > AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4 (2,0) uses AU-3 > timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)]. > > If we define STS-1 contiguous concatenation, which timeslots are then used for > > e.g. a STS-1-3c: > i) timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or > ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9] > > Similarly, for the case of a STS-1-6c do we use: > i) (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2) > [TS1,TS2,TS3,TS4,TS5,TS6] or > ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3) > [TS1,TS2,TS5,TS6,TS9,TS10] > > And which timeslots do we use for e.g. a STS-1-5c? > > If this detail is not specified, interworking is not possible unless we > include > the list of timeslots as we do with virtual concatenation (and as discussed > for > flexible arbitrary concatenation). > > Regards, > > Maarten --------------529A60BC86E4E9B37CA97F7E Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------529A60BC86E4E9B37CA97F7E-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 10 Jul 2001 04:23:08 -0700 From: "Tissa Senevirathne" To: ppvpn@zephion.net, mpls@UU.NET, ccamp@ops.ietf.org, pwe3@ietf.org Bcc: Subject: Could you comment on ID draft-tsenevir-bgp-l2vpn-00.txt Date: Tue, 10 Jul 2001 11:21:12 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: http://search.ietf.org/internet-drafts/draft-tsenevir-bgp-l2vpn-00.txt The above draft present BGP-MP based approach in providing Layer 2 VPN services. The work presented here extends the 2547bis to provide both Layer 2VPN and Layer 3 VPN. Hence allowing providers to provision both Layer 2 and Layer 3VPN services using a single control protocol. I appreciate if you could review and provide comments and feedback Thanks Tissa _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 10 Jul 2001 02:15:57 -0700 Cc: "t1x1.5" , q11/15 Message-ID: <3B4AC753.6E995AB0@lucent.com> Date: Tue, 10 Jul 2001 11:13:55 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Original-CC: "t1x1.5" , q11/15 Subject: arbitrary contiguous concatenation question Content-Type: multipart/mixed; boundary="------------D14641125D0EB5C8CF91DA1B" This is a multi-part message in MIME format. --------------D14641125D0EB5C8CF91DA1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling support for arbitrary contiguous concatenation in appendix 3. Looking a bit more into this arbitrary concatenation from the transport plane, I came across a question with respect to the definition of "contiguous STS-1/AU-3 timeslots". Let me introduce this question: Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within an STM-4) as follows Time 111 Slot 123456789012123456789 B 123412341234123412341... A 111122223333111122223... AU-3 timeslots have a TimeSlot number and a (B,A) number, with TS1 associated with (1,1) and TS12 associated with (4,3). Note - the figure in the pre-published version of G.707 doesn't show the timeslot numbering in a correct manner. and the AU-4 numbering is as follows (figure 7-24/G.707) Time Slot 123412341234123412341 B 123412341234123412341... A 000000000000000000000... An AU-4 [STS-3c] is as such essentially a "non-contiguous" concatenation of AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4 (2,0) uses AU-3 timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)]. If we define STS-1 contiguous concatenation, which timeslots are then used for e.g. a STS-1-3c: i) timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9] Similarly, for the case of a STS-1-6c do we use: i) (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2) [TS1,TS2,TS3,TS4,TS5,TS6] or ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3) [TS1,TS2,TS5,TS6,TS9,TS10] And which timeslots do we use for e.g. a STS-1-5c? If this detail is not specified, interworking is not possible unless we include the list of timeslots as we do with virtual concatenation (and as discussed for flexible arbitrary concatenation). Regards, Maarten --------------D14641125D0EB5C8CF91DA1B Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------D14641125D0EB5C8CF91DA1B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 09 Jul 2001 23:43:15 -0700 Date: Mon, 9 Jul 2001 23:40:13 -0700 (PDT) From: Kireeti Kompella Message-Id: <200107100640.XAA17856@kummer.juniper.net> To: dguo@turinnetworks.com Subject: RE: draft-ietf-mpls-lmp-02.txt Cc: ccamp@ops.ietf.org > there are two LMP drafts (both -02) at ietf.org website: > 1. URL below (in Kireeti's email); I screwed up. draft-ietf-mpls-lmp-02.txt is the correct one. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 09 Jul 2001 14:35:36 -0700 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt Date: Mon, 09 Jul 2001 14:32:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, You mean to say that hierarchical LSPs can be established in 1st and 2nd case. Are these cases need to be pre-configured at the time STM-N link is configured (i.e. the LOVC link ends at a fabric at both sides etc.) ? Also, in the following example u explained the allocation of VC-11 in VC-11 link connection (3,1). How in signalling how do u specify that I want VC-11 from (3,1) VC-11 link connection ? Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt >Date: Mon, 09 Jul 2001 11:02:00 +0200 > >Manoj, > >manoj juneja wrote: > > > > Hi All, > > > > In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical > > sonet/sdh LSPs has been described. It mentions that the higher order > > sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC > > -3). A lower order SDH/SONET LSP can be established through that higher > > LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all > > labels allocated between two ends of that LSP will have S, U and K set > > to ZERO i.e. non-significant while L and M will be used to indicate the > > signal allocated in that VC-3. > >In my opinion in all cases LOVC/VT connections will have S and U (and when >transported in a VC-3/STS-1 also K) set to zero. This implies that examples >2 to >5 in section 3 of the document present non-existing cases. Also example 1 >is not >correct. Are we misleading the reader here? > > > Please clarify how the higher order LSP will be established ? > >For a HO-VC-3 link connection the following values are applicable (case of >e.g. >VC-3 (4,1) in a STM-4): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ST=5 | RCC=0 | NCC=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NVC=0 | Multiplier (MT)=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transparency (T)=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S=4 | U=1 | K=0 | L=0 | M=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >The above only results in the allocation of VC-3 link conneciton number >(4,1) in >e.g. a STM-4 to a VC-3 connection. There might be many more VC-3 link >connections and VC-3 matrix connections present in the total VC-3 path >between >the VC-3 path termination functions. > > > > > Once the higher order LSP gets established, the lower order signals > > within higher order signals will also gets allocated. > >Once two VC-3 path terminations are interconnected via a series of VC-3 >matrix >connections and VC-3 link connections, there is a LOVC link established. >The >provisioning of the TU pointer processors at both VC-3 path termination >endpoints determines now the LOVC link's substructure (i.e. TU-11, TU-12, >TU-2 >structure). > >Three cases: >1) the LOVC link ends at a fabric at both sides: > Now there are no LOVC signals going over any of the LOVC > link connections in the LOVC link. > >2) the LOVC link ends at VC-11/12/2 termination functions at one side and a >fabric at the other side: > Now LOVC signals are generated at one side and inserted into > the LOVC link connections in the LOVC link. At the other end > these signals end up at the ingress of a Fabric, where the transport > stops until the moment the matrix connections are provisioned > in the fabric. In the other direction, the fabric generates LOVC UNEQ > signals, which will cause LOVC-UNEQ alarms to be raised (unless > alarm reporting is disabled). > >3) the LOVC link ends at VC-11/12/2 termination functions at both sides: > Now LOVC signals are generated at both sides and inserted into > the LOVC link connections in the LOVC link. The creation of the > VC-3 path also has created the set of LOVC paths. Assumption is > that both endpoints have the same set of LOVC path termination > points; otherwise there will be TU-LOP alarms. > > > > Then how can I again allocate the lower order signals ? > >This is only important in cases 1 and 2. Here you have no lower order >signals >flowing, you have only LOVC link connections created which are waiting for >a >LOVC signal to be transported over it. > >Assume you want to transport a VC-11 over VC-11 link connection number >(3,1), >then you will see the following request > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ST=1 | RCC=0 | NCC=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NVC=0 | Multiplier (MT)=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transparency (T)=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S=0 | U=0 | K=0 | L=4 | M=7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >Regards, > >Maarten ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 09 Jul 2001 07:26:00 -0700 Message-ID: <3B49BF43.1D4CC41B@research.att.com> Date: Mon, 09 Jul 2001 10:27:15 -0400 From: Guangzhi Li MIME-Version: 1.0 To: Vijay Gill Cc: ccamp@ops.ietf.org, gli@research.att.com Subject: Re: Agenda Request: IETF Meeting for CCAMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Vijay: Please reserve me 10 ~15 min slot on the agenda for the London IETF meeting. We will submit a new I-D with title "RSVP-TE extensions for shared mesh restoration in transport networks". Thanks, Guangzhi Vijay Gill wrote: > Folks > > Are there any items people would like to put on the > agenda for the London IETF meeting? > > Please send requests to Kireeti and myself. > > kireeti@juniper.net > vijay@umbc.edu > > thanks > > your co-chairs > > kireeti and vijay Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 09 Jul 2001 02:05:55 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B497308.1B258F12@lucent.com> Date: Mon, 09 Jul 2001 11:02:00 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Doubt in ccamp-gmpls-sdh-sonet-01.txt Content-Type: multipart/mixed; boundary="------------96536CF1E01F07425C8CBB94" This is a multi-part message in MIME format. --------------96536CF1E01F07425C8CBB94 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, manoj juneja wrote: > > Hi All, > > In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical > sonet/sdh LSPs has been described. It mentions that the higher order > sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC > -3). A lower order SDH/SONET LSP can be established through that higher > LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all > labels allocated between two ends of that LSP will have S, U and K set > to ZERO i.e. non-significant while L and M will be used to indicate the > signal allocated in that VC-3. In my opinion in all cases LOVC/VT connections will have S and U (and when transported in a VC-3/STS-1 also K) set to zero. This implies that examples 2 to 5 in section 3 of the document present non-existing cases. Also example 1 is not correct. Are we misleading the reader here? > Please clarify how the higher order LSP will be established ? For a HO-VC-3 link connection the following values are applicable (case of e.g. VC-3 (4,1) in a STM-4): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ST=5 | RCC=0 | NCC=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVC=0 | Multiplier (MT)=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transparency (T)=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S=4 | U=1 | K=0 | L=0 | M=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above only results in the allocation of VC-3 link conneciton number (4,1) in e.g. a STM-4 to a VC-3 connection. There might be many more VC-3 link connections and VC-3 matrix connections present in the total VC-3 path between the VC-3 path termination functions. > Once the higher order LSP gets established, the lower order signals > within higher order signals will also gets allocated. Once two VC-3 path terminations are interconnected via a series of VC-3 matrix connections and VC-3 link connections, there is a LOVC link established. The provisioning of the TU pointer processors at both VC-3 path termination endpoints determines now the LOVC link's substructure (i.e. TU-11, TU-12, TU-2 structure). Three cases: 1) the LOVC link ends at a fabric at both sides: Now there are no LOVC signals going over any of the LOVC link connections in the LOVC link. 2) the LOVC link ends at VC-11/12/2 termination functions at one side and a fabric at the other side: Now LOVC signals are generated at one side and inserted into the LOVC link connections in the LOVC link. At the other end these signals end up at the ingress of a Fabric, where the transport stops until the moment the matrix connections are provisioned in the fabric. In the other direction, the fabric generates LOVC UNEQ signals, which will cause LOVC-UNEQ alarms to be raised (unless alarm reporting is disabled). 3) the LOVC link ends at VC-11/12/2 termination functions at both sides: Now LOVC signals are generated at both sides and inserted into the LOVC link connections in the LOVC link. The creation of the VC-3 path also has created the set of LOVC paths. Assumption is that both endpoints have the same set of LOVC path termination points; otherwise there will be TU-LOP alarms. > Then how can I again allocate the lower order signals ? This is only important in cases 1 and 2. Here you have no lower order signals flowing, you have only LOVC link connections created which are waiting for a LOVC signal to be transported over it. Assume you want to transport a VC-11 over VC-11 link connection number (3,1), then you will see the following request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ST=1 | RCC=0 | NCC=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVC=0 | Multiplier (MT)=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transparency (T)=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S=0 | U=0 | K=0 | L=4 | M=7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Maarten --------------96536CF1E01F07425C8CBB94 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------96536CF1E01F07425C8CBB94-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 22:40:48 -0700 Message-ID: <3B46A18C.EADEB625@juniper.net> Date: Fri, 06 Jul 2001 22:43:40 -0700 From: Ping Pan Organization: Juniper Networks MIME-Version: 1.0 To: mpls-list , ccamp-list CC: Yakov Rekhter , Kireeti Kompella , George Swallow , Dimitrios Pendarakis , Fong Liaw Subject: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-00.txt] Content-Type: multipart/mixed; boundary="------------C3A36C92E1B580CFF12E760F" This is a multi-part message in MIME format. --------------C3A36C92E1B580CFF12E760F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Here is a draft on minimizing the negative effects on MPLS traffic caused by LSR's control plane restart. We think this is a valuable feature for the LSR's. Look forward to hear from you. Thanks! - Ping --------------C3A36C92E1B580CFF12E760F Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA11765; Fri, 6 Jul 2001 09:52:02 -0400 (EDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA27430; Fri, 6 Jul 2001 09:52:01 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA24825 for ietf-123-outbound.06@ietf.org; Fri, 6 Jul 2001 09:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23712 for ; Fri, 6 Jul 2001 06:51:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25974 for ; Fri, 6 Jul 2001 06:51:02 -0400 (EDT) Message-Id: <200107061051.GAA25974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;;:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pan-rsvp-te-restart-00.txt Date: Fri, 06 Jul 2001 06:51:01 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Graceful Restart Mechanism for RSVP-TE Author(s) : P. Pan et al. Filename : draft-pan-rsvp-te-restart-00.txt Pages : Date : 05-Jul-01 This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by LSR's control plane restart, and specifically by the restart of its RSVP-TE component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pan-rsvp-te-restart-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pan-rsvp-te-restart-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pan-rsvp-te-restart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pan-rsvp-te-restart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113937.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------C3A36C92E1B580CFF12E760F-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 15:26:10 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: mvissers@lucent.com Bcc: Subject: Doubt in ccamp-gmpls-sdh-sonet-01.txt Date: Fri, 06 Jul 2001 15:24:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In draft ccamp-gmpls-sonet-sdh-01.txt, concept of hierarchical sonet/sdh LSPs has been described. It mentions that the higher order sdh/sonet LSP behaves as a virtual link with a given bandwidth (e.g. VC -3). A lower order SDH/SONET LSP can be established through that higher LSP. For e.g. VC-3 LSP can be advertised as a FA. In this case all labels allocated between two ends of that LSP will have S, U and K set to ZERO i.e. non-significant while L and M will be used to indicate the signal allocated in that VC-3. Please clarify how the higher order LSP will be established ? Once the higher order LSP gets established, the lower order signals within higher order signals will also gets allocated. Then how can I again allocate the lower order signals ? Is this the reason for having bandwidth encdoing parameter in GMPLS signalling (i.e. establishment of hierarchical SDH/SONET LSPs) ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 07:51:23 -0700 Message-Id: <200106261102.HAA27267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt Date: Tue, 26 Jun 2001 07:02:32 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : New TE LSAs to extend OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-00.txt Pages : 36 Date : 25-Jun-01 OSPF is a well established link state routing protocol used for topology discovery and computing forwarding table based on shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) will use criteria different from shortest-path so as to route traffic around congestion paths and meet varying Service Level agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625101030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 07:51:20 -0700 Message-Id: <200107061050.GAA25924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt Date: Fri, 06 Jul 2001 06:50:43 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel Filename : draft-iwata-mpls-crankback-01.txt Pages : 30 Date : 05-Jul-01 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-d Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 05:36:46 -0700 Cc: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Message-ID: <3B45B0A0.560F2663@lucent.com> Date: Fri, 06 Jul 2001 14:35:44 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Diego Caviglia Original-CC: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Subject: Re: Span Definition Content-Type: multipart/mixed; boundary="------------E947154F1FB56A66677FE7EA" This is a multi-part message in MIME format. --------------E947154F1FB56A66677FE7EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diego, An OCh signal represents a single optical signal. It is as such not equivalent to your optical link, which is multi-channel (i.e. multi-signal). OCh_1 OCh_6 |------------------------------------------------------------||--------------- OCh_5 OCh_2 ------------------||---------------------------------------------------------| OCh_4 OCh_3 ------------------||-----------------------------------------| OMSn_a OMSn_b OMSn_c OMSn_d |-----------------||--------------------||-------------------||--------------| OTSn_A OTSn_B OTSn_C OTSn_D OTSn_E OTSn_F OTSn_G OTSn_H OTSn_I OTSn_J |-----||----||----||-------||-----------||-----||-----||-----||------||------| n OCh signals are transported via one OMSn signal. One OMSn signal is transported via one OTSn signal. At the endpoint of an OMSn, all n OCh signals are accessible, and may be connected to another OMSn or terminated (3R regeneration). Note that the termination of OCh signals doesn't have to be performed at the same points in the network as shown in the figure above. Nevertheless, in today's core network it is typical that all OCh signals are terminated at the end of an OMSn section; but in the all-optical network of tomorrow this will not longer be the case. OMSn_a and OMSn_b (etc.) may have different values of n; e.g. OMS80_a and OMS32_b. Up to so far. Allow me to ask a question about the benefits for our telecom industry of introducing a second set of terms to describe the optical transport network. Wouldn't it be more efficient when we just use a single set of terms? Regards, Maarten Diego Caviglia wrote: > > Hi Marteen , > you're right, thank you for your clarification. > Thus accordingly to your mail the Optical Link definition become: > > Optical Link "An Optical Link consist of a number of channels between > two adjacent 3R regeneration sites" > An Optical Link is what in ITU-T is called Och > > Regards. > > Diego. > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modeling > E-mail: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com > > Maarten Vissers on 06/07/2001 10.55.51 > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN > > cc: ling.liu@edgeflow.com, jplang@calient.net, > ccamp@ops.ietf.org > > > > Subject: Re: Span Definition > > > Diego, > > 3R regeneration sites are in the OTN (G.872, G.709, G.798) represented > by the OCh termination point; i.e. when the OCh signal is terminated 3R > processing is performed including section monitoring (OTUk or OTUkV > termination). > The OMS termination point is not associated with 3R processing. It is > only involved with optical multiplexing/demultiplexing (OCh signals are > muxed/demuxed here) and termination of the OMS trail (OMSn_TT and > OMSn/OCh_A functions). For more information on functionality of the OTN > atomic functions you can have a look at draft G.798 version 0.8.1 at > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf > > You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted > in slide 15 of the following OTN/G.709 presentation > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/OTN/g709-intro.ppt > > Regards, > > Maarten > > Diego Caviglia wrote: > > > > Ling-Zhong, Jonathan > > > > Could you please review > your > > definition of span accordingly to the following one? > > > > Span "A span consists of a number of channels between two adjacent > Optical > > Amplification sites, a Span is a part of an Optical Link" > > A Span is what in ITU-T is called OTS > > > > Optical Link "An Optical Link consist of a number of channels between > two > > adjacent 3R regeneration sites" > > An Optical Link is what in ITU-T is called OMS > > > > Regrads > > > > Diego. > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modeling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 0 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com --------------E947154F1FB56A66677FE7EA Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------E947154F1FB56A66677FE7EA-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 03:51:56 -0700 Message-Id: <200107061050.GAA25924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt Date: Fri, 06 Jul 2001 06:50:43 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel Filename : draft-iwata-mpls-crankback-01.txt Pages : 30 Date : 05-Jul-01 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113912.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 03:09:04 -0700 From: "Diego Caviglia" To: Maarten Vissers cc: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Message-ID: <80256A81.00377C40.00@marconicomms.com> Date: Fri, 6 Jul 2001 12:06:10 +0200 Subject: Re: Span Definition Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo" Content-Disposition: inline --0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Marteen , you're right, thank you for your clarification. Thus accordingly to your mail the Optical Link definition become: Optical Link "An Optical Link consist of a number of channels between two adjacent 3R regeneration sites" An Optical Link is what in ITU-T is called Och Regards. Diego. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Maarten Vissers on 06/07/2001 10.55.51 To: Diego Caviglia/MAIN/MC1@MCMAIN cc: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Subject: Re: Span Definition Diego, 3R regeneration sites are in the OTN (G.872, G.709, G.798) represented by the OCh termination point; i.e. when the OCh signal is terminated 3R processing is performed including section monitoring (OTUk or OTUkV termination). The OMS termination point is not associated with 3R processing. It is only involved with optical multiplexing/demultiplexing (OCh signals are muxed/demuxed here) and termination of the OMS trail (OMSn_TT and OMSn/OCh_A functions). For more information on functionality of the OTN atomic functions you can have a look at draft G.798 version 0.8.1 at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted in slide 15 of the following OTN/G.709 presentation ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/OTN/g709-intro.ppt Regards, Maarten Diego Caviglia wrote: > > Ling-Zhong, Jonathan > > Could you please review your > definition of span accordingly to the following one? > > Span "A span consists of a number of channels between two adjacent Optical > Amplification sites, a Span is a part of an Optical Link" > A Span is what in ITU-T is called OTS > > Optical Link "An Optical Link consist of a number of channels between two > adjacent 3R regeneration sites" > An Optical Link is what in ITU-T is called OMS > > Regrads > > Diego. > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modeling > E-mail: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com --0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo Content-type: application/octet-stream; name="mvissers.vcf" Content-Disposition: attachment; filename="mvissers.vcf" Content-transfer-encoding: base64 YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1 DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7 d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K --0__=2JmuBf6BR7uPkGp60ivRcvMQ7P3qj7t8Lf1yjEAHKXiRY8wIYy3c2jLo-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 01:59:23 -0700 To: q11/15 , "t1x1.5" , ccamp Message-ID: <3B457D90.48D17814@lucent.com> Date: Fri, 06 Jul 2001 10:57:52 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: q11/15 , "t1x1.5" , ccamp Subject: [G.707/Y.1322] ITU-T Recommendation G.707/Y.1322 (10/00) - Network node interface for the synchronous digital hierarchy (SDH) Content-Type: multipart/mixed; boundary="------------E755EAB22A204341F844BC52" This is a multi-part message in MIME format. --------------E755EAB22A204341F844BC52 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, Recommendation G.707 (10/2000) is now available as a pre-published document. You can get your copy from http://www.itu.int/itudoc/itu-t/approved/g/g707-y13.html Regards, Maarten http://www.itu.int/itudoc/itu-t/approved/g/g707-y13.html --------------E755EAB22A204341F844BC52 Content-Type: text/html; charset=iso-8859-1; name="g707-y13.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="g707-y13.html" Content-Base: "http://www.itu.int/itudoc/itu-t/approv ed/g/g707-y13.html" Content-Location: "http://www.itu.int/itudoc/itu-t/approv ed/g/g707-y13.html" [G.707/Y.1322]= ITU-T Recommendation G.707/Y.1322 (10/00) - Network node interface for t= he synchronous digital hierarchy (SDH)=
3DITU3DInternati== Fran=E7ais  Espa=F1ol
3DOur3DNews= 3DEvents3DPublications= 3DSite= 3DAbout
Print Version
3DITU=
Office of the
SecretaryGeneral

Radio-
communication<= BR>(ITU-R)

Telecom
Standardiza= tion
(ITU-T)

Telecom
Develo= pment
(ITU-D)

TELECOM
Exh= ibitions and
Forum

Membershi= p

Home Page : Publications
=
[G.707/Y.1322] ITU-T Recommendation G.707/Y.1322 (10/00) - Net= work node interface for the synchronous digital hierarchy (SDH)

 
Availability : Electronic Bookshop  Subscription Service   (ITU-T Recommendations Online) &nb= sp;
Price:73 CHF= (Swiss Francs)

To add item to your shoppi= ng basket click on Add to Cart

View or Download Document

= <= td align=3Dcenter>

3DDownload

<= td colspan=3D2 align=3Dcenter>


Checkout (Pay)
Basket Status

Format

Size=

Posted

E-Bookshop

Subscribers

English 

Word for Windows 2000

1= =2E2 mb

Jul 04 2001

Add to Cart

 

ZIPPED Word for Windows 2000

512.2 kb

Jul 04 2001

Add to Cart

Top = ;-  Feedback=  -  = Privacy -  Copyright =A9 ITU 2001 All Rights Reserved
Con= tact for this page : webmaster@itu.int
Updated : 2001-07-06		 =
--------------E755EAB22A204341F844BC52 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------E755EAB22A204341F844BC52-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 01:57:27 -0700 Cc: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Message-ID: <3B457D17.24A9D931@lucent.com> Date: Fri, 06 Jul 2001 10:55:51 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Diego Caviglia Original-CC: ling.liu@edgeflow.com, jplang@calient.net, ccamp@ops.ietf.org Subject: Re: Span Definition Content-Type: multipart/mixed; boundary="------------BD970029CBAB8023FD4F73AA" This is a multi-part message in MIME format. --------------BD970029CBAB8023FD4F73AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diego, 3R regeneration sites are in the OTN (G.872, G.709, G.798) represented by the OCh termination point; i.e. when the OCh signal is terminated 3R processing is performed including section monitoring (OTUk or OTUkV termination). The OMS termination point is not associated with 3R processing. It is only involved with optical multiplexing/demultiplexing (OCh signals are muxed/demuxed here) and termination of the OMS trail (OMSn_TT and OMSn/OCh_A functions). For more information on functionality of the OTN atomic functions you can have a look at draft G.798 version 0.8.1 at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q9/g798/g798v0_8_1.pdf You can see the allocation of OTSn, OMSn, OCh, OTUk, etc also depicted in slide 15 of the following OTN/G.709 presentation ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/OTN/g709-intro.ppt Regards, Maarten Diego Caviglia wrote: > > Ling-Zhong, Jonathan > > Could you please review your > definition of span accordingly to the following one? > > Span "A span consists of a number of channels between two adjacent Optical > Amplification sites, a Span is a part of an Optical Link" > A Span is what in ITU-T is called OTS > > Optical Link "An Optical Link consist of a number of channels between two > adjacent 3R regeneration sites" > An Optical Link is what in ITU-T is called OMS > > Regrads > > Diego. > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modeling > E-mail: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com --------------BD970029CBAB8023FD4F73AA Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------BD970029CBAB8023FD4F73AA-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jul 2001 00:58:59 -0700 From: "Diego Caviglia" To: ling.liu@edgeflow.com, jplang@calient.net cc: ccamp@ops.ietf.org Message-ID: <80256A81.002B029E.00@marconicomms.com> Date: Fri, 6 Jul 2001 09:49:54 +0200 Subject: Span Definition Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Ling-Zhong, Jonathan Could you please review your definition of span accordingly to the following one? Span "A span consists of a number of channels between two adjacent Optical Amplification sites, a Span is a part of an Optical Link" A Span is what in ITU-T is called OTS Optical Link "An Optical Link consist of a number of channels between two adjacent 3R regeneration sites" An Optical Link is what in ITU-T is called OMS Regrads Diego. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 05 Jul 2001 16:38:01 -0700 Message-ID: <20010705233432.73979.qmail@web13806.mail.yahoo.com> Date: Thu, 5 Jul 2001 16:34:32 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Agenda Request: IETF Meeting for CCAMP To: Vijay Gill , ccamp@ops.ietf.org Cc: pjoseph@jasminenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, We would like 10 to 15 mins to discuss the following draft. Title: New TE LSAs to extend OSPF for Traffic Engineering http URL: draft-srisuresh-ospf-te-00.txt Thanks. regards, suresh --- Vijay Gill wrote: > > Folks > > Are there any items people would like to put on the > agenda for the London IETF meeting? > > Please send requests to Kireeti and myself. > > kireeti@juniper.net > vijay@umbc.edu > > > thanks > > your co-chairs > > kireeti and vijay > > > > ===== __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 05 Jul 2001 08:23:37 -0700 From: wesam.alanqar@mail.sprint.com Date: Thu, 5 Jul 2001 10:19:26 -0500 Message-Id: Subject: RE: Re: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00 MIME-Version: 1.0 TO: k_kompella@yahoo.com CC: ccamp@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Thu, 5 Jul 2001 10:19:25 -0500" Content-Transfer-Encoding: 8bit Hi Kireeti, Thanks for the input. Does this mean that in the GMPLS hierarchal model we will have (PSC or L2SC) over TDM over LSC over FSC layers? Thanks. -Wesam -----Original Message----- From: k.kompella [mailto:k_kompella@yahoo.com] Sent: Wednesday, July 04, 2001 4:05 AM To: wesam.alanqar; ccamp Subject: Re: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00 Hi, PSC is for Layer 3 packets encapsulated in an MPLS header. L2SC is for Layer 2 packets (as you say, ATM and Frame Relay) where the MPLS label reflects the layer 2 address. L2SC is *not* for ATM/Frame transport over MPLS (for that, see the PWE3 WG). Kireeti. PS. Incidentally, L2SC was introduced in the GMPLS *routing* documents, not in the architecture doc. --- wesam.alanqar@mail.sprint.com wrote: > Hi, > > In the original GMPLS architecture, PSC interfaces > were introduced for > the packet layer. Why in this document L2SC > interfaces are introduced? __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jul 2001 06:26:19 -0700 Cc: "'manoj juneja'" , ccamp@ops.ietf.org, "Igor Danilovich (E-mail)" Message-ID: <3B4318EA.B425A4B0@lucent.com> Date: Wed, 04 Jul 2001 15:23:54 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sasha Vainshtein Original-CC: "'manoj juneja'" , ccamp@ops.ietf.org, "Igor Danilovich (E-mail)" Subject: Re: sdh Doubt Content-Type: multipart/mixed; boundary="------------C72F1189578629BE3D686ECC" This is a multi-part message in MIME format. --------------C72F1189578629BE3D686ECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, Sasha, Once you have connected two STM-N (e.g. STM-256) ports together you have created a MSn (e.g. MS256) trail. Such MSn trail supports a HOVC topological link (G.85x terminology). This HOVC link contains a number of HOVC link connections. An STM-256 trail may support the following link connection types: VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c and VC-4-256c. The specific set of HOVC link connections supported by a particular HOVC link is STM-N port pair dependent. This depends on the capabilities supported by the AU pointer processor circuits in these ports and the capabilities supported by the fabrics to which these ports are connected. E.g. STM-256 port A may support AU-4, AU-4-4c and AU-4-16 pointer processing, whereas the STM-256 port B to which it is A is connected may support AU-3, AU-4 and AU-4-4c pointer processing. The STM-256 port pair then supports VC-4 and VC-4-4c link connections within this HOVC topological link. If at time Ta a particular AUG-4 entity within the STM-256 is provisioned to operate as AU-4-4c and transport a VC-4-4c signal, and the associated connection is removed at time Tb, then this AUG-4 bandwidth may be used at Tc > Tb for wither 4 VC-4 connections or 1 VC-4-4c connection. For the former case (4x VC-4) the VC-4-4c link connection supported by AU-4-4c pointer processing must be converted into 4 VC-4 link connections supported by 4x AU-4 pointer processing. The same is applicable if a STM-256 trail supporting a HOVC link with VC-4-256c link connection capability has to transport e.g. a VC-4-64c. The transport of a VC-4-64c is only possible if the VC-4-256c connection is not longer present. If not longer present, the whole HOVC link bandwidth is available for other services, and to support a VC-4-46c the VC-4-256c link connection is replaced by a VC-4-64c link connection (supported by AU-4-64c pointer processing) and the remainder of the bandwidth is set to support e.g. VC-3 link connections. These latter ones will then carry VC-3 UNEQ signals. But any other VC-n level may also be choosen... but both ends of the HOVC link must decide one the same VC-n type; otherwise you get a series of AU-LOP alarms from these endpoints. Note that according G.707 the AUG-X isn't a signal; it is only a means to describe the ordering and multiplex structure of AUs. In reality, you have a mix of AU-3, AU-4, AU-4-4c, AU-4-16c, AU-4-64c or one AU-4-256c processing active. In most equipment you can change this mix when required. Regards, Maarten Sasha Vainshtein wrote: > > Manoj, > AFAIK, the answer is YES. In SDH, once you have performed concatenation, > on a certain stream, you cannot allocate access separate substreams. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > -----Original Message----- > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Sent: Wednesday, June 27, 2001 9:12 PM > > To: ccamp@ops.ietf.org > > Subject: sdh Doubt > > > > > > Hi All, > > AUG-256 may consist of : > > 1. 4 AUG-64 > > 2. 1 AU-4-256c > > > > If AUG-256 consists of 1 AU-4-256c, does this mean it can't > > allocate > > signals of less granularity than this (viz. one VC-4 or > > VC-4-64c or VC-4-16c > > etc) ? > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > --------------C72F1189578629BE3D686ECC Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------C72F1189578629BE3D686ECC-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jul 2001 04:55:09 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B4303C2.F60FF0D7@lucent.com> Date: Wed, 04 Jul 2001 13:53:38 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: SDH/SONET Doubt Content-Type: multipart/mixed; boundary="------------D749F44EDBDB516FB2AA2DA9" This is a multi-part message in MIME format. --------------D749F44EDBDB516FB2AA2DA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, A STM-N signal may contain of a set of HOVC signals. HOVC signals are VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c and VC-4-256c signals. A VC-3 or VC-4 signal may contains a set of LOVC signals. LOVC signals for the case of HO-VC-3 are VC-11, VC-12 and VC-2. LOVC signals for the cae of VC-4 are VC-11, VC-12, VC-2 and VC-3. At STM-N level, you only have visibility in the HOVC signal structure; you don't care about the content of the HOVC signal. At HO-VC-3 and VC-4 level you have visibility in the LOVC signal structure. Regards, Maarten manoj juneja wrote: > > Hi All, > Can the STM-N link consist of mix of VC-4, VC-3, VC-11, VC-12, > VC-2 signals ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------D749F44EDBDB516FB2AA2DA9 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------D749F44EDBDB516FB2AA2DA9-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jul 2001 02:07:14 -0700 Message-ID: <20010704090506.99948.qmail@web13903.mail.yahoo.com> Date: Wed, 4 Jul 2001 02:05:06 -0700 (PDT) From: Kireeti Kompella Subject: Re: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00 To: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, PSC is for Layer 3 packets encapsulated in an MPLS header. L2SC is for Layer 2 packets (as you say, ATM and Frame Relay) where the MPLS label reflects the layer 2 address. L2SC is *not* for ATM/Frame transport over MPLS (for that, see the PWE3 WG). Kireeti. PS. Incidentally, L2SC was introduced in the GMPLS *routing* documents, not in the architecture doc. --- wesam.alanqar@mail.sprint.com wrote: > Hi, > > In the original GMPLS architecture, PSC interfaces > were introduced for > the packet layer. Why in this document L2SC > interfaces are introduced? __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 17:24:14 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Explicit Label Control Date: Tue, 03 Jul 2001 17:23:15 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In GMPLS drafts, the concept of Egress/explicit Label control is described. Is this valid only at egress or intermediate nodes also ? I mean to say whether the Egress Label object will only be at the end of ERO or it can appear in between ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 16:33:21 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: SDH/SONET Doubt Date: Tue, 03 Jul 2001 16:27:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Can the STM-N link consist of mix of VC-4, VC-3, VC-11, VC-12, VC-2 signals ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 12:26:16 -0700 From: wesam.alanqar@mail.sprint.com Date: Tue, 3 Jul 2001 13:39:24 -0500 Message-Id: Subject: doubts about PSC and L2SC in draft-ietf-ccamp-gmpls-architecture-00 MIME-Version: 1.0 TO: ccamp@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 3 Jul 2001 13:39:24 -0500" Content-Transfer-Encoding: 8bit Hi, In the original GMPLS architecture, PSC interfaces were introduced for the packet layer. Why in this document L2SC interfaces are introduced? Why do we need to introduce a new level of hierarchy? In the original GMPLS architecture, we had PSC,TDM, LSC, FSC. In this draft we have L2SC added. Is this to make GMPLS more applicable for ATM and Ethernet "MPLS capable" in addition to IP-based networks. Do we need to use one type of interfaces (PSC or L2SC) above the TDM layer or we could use both? Thanks ----------------------------------------------------- Wesam Alanqar Member of Technical Staff Technology Research Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------ -----Original Message----- From: Internet-Drafts [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 03, 2001 5:56 AM To: IETF-Announce: . Cc: ccamp; Internet-Drafts Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-architecture-00.txt Pages : 48 Date : 02-Jul-01 Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture- 00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 12:05:56 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590AFCF86@MILAN> From: dguo@turinnetworks.com To: jplang@calient.net Cc: dimitri.papadimitriou@alcatel.be, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: draft-ietf-mpls-lmp-02.txt Date: Tue, 3 Jul 2001 12:03:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C103F2.E10E8A40" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C103F2.E10E8A40 Content-Type: text/plain; charset="iso-8859-1" Dear Jonathan, there are two LMP drafts (both -02) at ietf.org website: 1. URL below (in Kireeti's email); 2. URL: http://search.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt URL 1 has an outdatd version. i think someone should remove it to avoid confusion. Dan Guo Turin Networks. Kireeti Kompella wrote: > > Hi All, > > Once upon a time, there was consensus to make the above document > (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) > an MPLS WG document. > > It now falls under the purvey of CCAMP. Question: do you think this > document should be a CCAMP WG document? (You know the drill ....) > > Kireeti & Vijay. ------_=_NextPart_001_01C103F2.E10E8A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-mpls-lmp-02.txt

Dear Jonathan,

there are two LMP drafts (both -02) at ietf.org = website:
  1. URL below (in Kireeti's email);
  2. URL:  http://search.ietf.org/internet-drafts/draft-ietf-mpls= -lmp-02.txt

URL 1 has an outdatd version.
i think someone should remove it to avoid = confusion.
Dan Guo
Turin Networks.

Kireeti Kompella wrote:
>
> Hi All,
>
> Once upon a time, there was consensus to make = the above document
> (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls= -lmp-02.txt )
> an MPLS WG document.
>
> It now falls under the purvey of CCAMP.  = Question: do you think this
> document should be a CCAMP WG document?  = (You know the drill ....)
>
> Kireeti & Vijay.

------_=_NextPart_001_01C103F2.E10E8A40-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 10:19:23 -0700 Message-Id: <200107031713.NAA12820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bellato-ccamp-g709-framework-00.txt Date: Tue, 03 Jul 2001 13:13:08 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : G.709 Optical Transport Networks GMPLS Control Framework Author(s) : A. Bellato et al. Filename : draft-bellato-ccamp-g709-framework-00.txt Pages : 27 Date : 02-Jul-01 Along with the current development of packet over lambda switching (referred to as MPLambdaS), there are considerable developments in optical transport systems based on the ITU-T G.872 [ITUT-G872] and G.709 [ITUT-G709] specification. The Optical Transport Network (OTN) defined in G.872 and G.709 enables ultra-long-haul transmission of various client signal types through the use of Forward Error Correction (FEC) bytes. G.709 specifies the data plane transport structure and allocates overhead bytes for the OTN control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellato-ccamp-g709-framework-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bellato-ccamp-g709-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bellato-ccamp-g709-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010702161501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bellato-ccamp-g709-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bellato-ccamp-g709-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161501.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 07:16:46 -0700 Message-ID: <3B41D31D.CCA3A486@sandburst.com> Date: Tue, 03 Jul 2001 10:13:49 -0400 From: Eric Gray MIME-Version: 1.0 To: Bert Wijnen , Scott Bradner , Kireeti Kompella , George Swallow , Vijay Gill , Vijay Srinivasan Cc: MPLS Mailing List , Common Control and Measurement Protocols Subject: Working Group tasks and charter cleanup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any chance that we will see how the tasks are divided between the MPLS and CCAMP working groups - including cleanup of the group charters, moving Internet Drafts to the right places (and names?), and so on before the next IETF meeting? -- Eric Gray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 05:50:10 -0700 Message-Id: <4.3.2.7.2.20010703085028.0268cbd0@bucket.cisco.com> Date: Tue, 03 Jul 2001 08:52:13 -0400 To: Vijay Gill , kireeti@juniper.net, From: "Thomas D. Nadeau" Subject: Re: Agenda Request: IETF Meeting for CCAMP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Vijay A discussion of which drafts have been kept/added/deleted from the WG as a result of the rest IESG review would be useful. Also, if there are any charter changes, these would be interesting to discuss. --Tom >Are there any items people would like to put on the >agenda for the London IETF meeting? > >Please send requests to Kireeti and myself. > >kireeti@juniper.net >vijay@umbc.edu > > >thanks > >your co-chairs > >kireeti and vijay Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 03:59:25 -0700 Message-Id: <200107031057.GAA23698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fontana-ccamp-gmpls-g709-00.txt Date: Tue, 03 Jul 2001 06:57:16 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : A. Bellato et al. Filename : draft-fontana-ccamp-gmpls-g709-00.txt Pages : 7 Date : 02-Jul-01 This document is a companion to the Generalized MPLS (GMPLS) signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It describes the G.709 technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN) including the so-called pre-OTN developments both described in [G709-FRM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fontana-ccamp-gmpls-g709-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010702161510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fontana-ccamp-gmpls-g709-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-fontana-ccamp-gmpls-g709-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161510.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jul 2001 03:59:21 -0700 Message-Id: <200107031056.GAA22923@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-00.txt Date: Tue, 03 Jul 2001 06:56:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-architecture-00.txt Pages : 48 Date : 02-Jul-01 Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010702161302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161302.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 16:08:40 -0700 Message-ID: <3B40FEE1.D26845BF@lucent.com> Date: Mon, 02 Jul 2001 19:08:18 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org Subject: Re: Bandwidth Encoding Type Doubt ..... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, It seems to me a redundancy. Thanks, Yangguang manoj juneja wrote: > > Hi, > Can someone please tell me the reason for bandwidth encoding > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > will be drived from the signal type field. How the bandwidth > encoding type will be interpreted in case of other LSP encoding types ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 16:04:57 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bandwidth Encoding Type Doubt ..... Date: Mon, 02 Jul 2001 14:41:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can someone please tell me the reason for bandwidth encoding parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated will be drived from the signal type field. How the bandwidth encoding type will be interpreted in case of other LSP encoding types ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 14:06:01 -0700 Date: Mon, 2 Jul 2001 17:02:12 -0400 From: Vijay Gill To: Subject: Agenda Request: IETF Meeting for CCAMP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks Are there any items people would like to put on the agenda for the London IETF meeting? Please send requests to Kireeti and myself. kireeti@juniper.net vijay@umbc.edu thanks your co-chairs kireeti and vijay Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 09:40:05 -0700 From: "Diego Caviglia" To: Yangguang Xu cc: Eric Gray , "ccamp@ops.ietf.org" Message-ID: <80256A7D.005B1196.00@marconicomms.com> Date: Mon, 2 Jul 2001 17:37:14 +0200 Subject: Re: Suggested Label Doubt Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk" Content-Disposition: inline --0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Yangguang, please see my comment in-line. Regards. Diego. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Yangguang Xu on 02/07/2001 16.35.11 To: Eric Gray cc: "ccamp@ops.ietf.org" (bcc: Diego Caviglia/MAIN/MC1) Subject: Re: Suggested Label Doubt --0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable Eric, I was about to keep quite... Because of recent discussions, here is my = comments to your previous example in-lines. I am OK with current suggested label, label set etc. However I want to = figure out the real application in circuit switching network and please help m= e about it. Thanks a lot. [snipped] > > > > > > > Would you please give me an example that what I said is not true? > > > Local significance - not every switch in an optical domain is necessa= rily > capable of performing the same kind of "optical switching". This doe= s not > mean that they cannot interoperate - but it does mean that they may n= ot > interoperate in the way that you expect. Can you give me an "example", I mean a real one? Please specify what ty= pe of circuit switches you are talking about, what's their functions etc. I h= ave heard too many hyperthetical applications that don't exist at all. /[dc] Could you please give us, or at least to me, a definition and so= me examples of "?too many hyperthetical applications that don't exist at a= ll." /[dc] > Under these circumstances, the > choice of "label" may have greater than local significance. Then that's routing constrains and you can specify certain routing cons= trains at the signaling time. Label itself only has local significance. > Moreover, you > cannot end up lambda switching two light beams of the same color into= > a single piece of glass. If you don't have any type of multiplexing mechanisms. It doesn't matte= r they are the same color or not. Otherwise, indeed you can, and it depends on your multiplexing and modu= lation mechanisms (. You are probably only talking about wavelength multiplexi= ng. For that specific case, you may be right. Sorry, this is just a side topic. > > Upstream/Downstream indifference of choice - true in optical networks= (at > least "Normally"), but not particularly relevant. One or the other M= UST > have the final say and the model to-date has been that the final word= is > given by the downstream. Given that there MAY BE a scenario in which= one > or the other has less than complete knowledge, it is necessary to hav= e a > negotiation/arbitration mechanism. > I think the upstream/downstream nodes are symmetric in circuit switchin= g network. I am looking an example to show me that your "MAY BE" is true.= BTW, I have concern about the definition of upstream/downstream. Their definitions in RFC 3031 need modifications for GMPLS. Thanks, Yangguang = --0__=fs3Fe0STMlAUoexo7mVlYw1VdsdZBoEFMK69TtJXgISDiNJRXioGGovk-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 08:07:15 -0700 Message-ID: <3B408D33.FD9D8241@sandburst.com> Date: Mon, 02 Jul 2001 11:03:15 -0400 From: Eric Gray MIME-Version: 1.0 To: Yangguang Xu Cc: Common Control and Measurement Protocols Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang, We should take this discussion off-line. -- Eric Gray You wrote: > Eric, > > I was about to keep quite... Because of recent discussions, here is my comments > to your previous example in-lines. > > I am OK with current suggested label, label set etc. However I want to figure > out the real application in circuit switching network and please help me about > it. Thanks a lot. > > [snipped] > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 08:02:18 -0700 Message-Id: <200107021455.KAA09271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-01.txt Date: Mon, 02 Jul 2001 10:55:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Extensions for SONET and SDH Control Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-sonet-sdh-01.txt Pages : 25 Date : 29-Jun-01 This document is a companion to the Generalized MPLS signaling documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines the SONET/SDH technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-sonet-sdh-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010629141305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010629141305.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 07:57:46 -0700 Message-ID: <3B407E6C.B827D688@lucent.com> Date: Mon, 02 Jul 2001 16:00:12 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja , ccamp Subject: Re: Fwd: RE: {SUKLM} numbering scheme Content-Type: multipart/mixed; boundary="------------796300C60EC73EF388C167C9" This is a multi-part message in MIME format. --------------796300C60EC73EF388C167C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, Eric, Attached is a copy of the SU - EDCBA conversion formula and tables, as it was included in draft-lin-ccamp-ipo-common-label-request-01.txt. It could be made apendix 6 of the GMPLs SOENT/sDH extensions document. We should verify if the recent modifications require changes to the formula and tables. Regards, Maarten --------------796300C60EC73EF388C167C9 Content-Type: text/plain; charset=us-ascii; name="untitled.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="untitled.txt" Appenix 6: Conversion formula for EDCBA <-> SU For the EDCBA to SU conversion, the following formula can be used: S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] + max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1 B U = ceiling[ --- , 0 ] + A B+1 For the SU to EDCBA conversion, the following formula can be used: S E = max[ ceiling[ --- ], 0 ] 64 or 0 {for AU-4-256c & STM-64 or lower} S D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 16 or 0 {for AU-4-64c or above & STM-16 or lower} S C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 4 or 0 {for AU-4-16c or above & STM-4 or lower} B = [ ( S-1 ) modulo 4 ] + 1 or 0 {for AU-4-4c or above & STM-1 or lower} A = U - 1 or 0 (for AU-4 or above) Sample conversion table The following table provides the explicit mapping between the SU and the EDCBA numbering scheme: Conversion table (E,D,C,B,A) (ITU-T G.707) to SU: G.707 EDCBA S U Signal Type ========================================= 00000 1 0 AU-4-256c/STS-768c in STM-256/OC-768 10000 1 0 AU-4-64c/STS-192c in STM-256/OC-768 20000 65 0 AU-4-64c/STS-192c in STM-256/OC-768 30000 129 0 AU-4-64c/STS-192c in STM-256/OC-768 40000 193 0 AU-4-64c/STS-192c in STM-256/OC-768 11000 1 0 AU-4-16c/STS-48c in STM-256/OC-768 12000 17 0 AU-4-16c/STS-48c in STM-256/OC-768 13000 33 0 AU-4-16c/STS-48c in STM-256/OC-768 14000 49 0 AU-4-16c/STS-48c in STM-256/OC-768 21000 65 0 AU-4-16c/STS-48c in STM-256/OC-768 22000 81 0 AU-4-16c/STS-48c in STM-256/OC-768 23000 97 0 AU-4-16c/STS-48c in STM-256/OC-768 24000 113 0 AU-4-16c/STS-48c in STM-256/OC-768 31000 129 0 AU-4-16c/STS-48c in STM-256/OC-768 32000 145 0 AU-4-16c/STS-48c in STM-256/OC-768 33000 161 0 AU-4-16c/STS-48c in STM-256/OC-768 34000 177 0 AU-4-16c/STS-48c in STM-256/OC-768 41000 193 0 AU-4-16c/STS-48c in STM-256/OC-768 42000 209 0 AU-4-16c/STS-48c in STM-256/OC-768 43000 225 0 AU-4-16c/STS-48c in STM-256/OC-768 44000 241 0 AU-4-16c/STS-48c in STM-256/OC-768 11100 1 0 AU-4-4c/STS-12c in STM-256/OC-768 11200 5 0 AU-4-4c/STS-12c in STM-256/OC-768 11300 9 0 AU-4-4c/STS-12c in STM-256/OC-768 11400 13 0 AU-4-4c/STS-12c in STM-256/OC-768 12100 17 0 AU-4-4c/STS-12c in STM-256/OC-768 12200 21 0 AU-4-4c/STS-12c in STM-256/OC-768 12300 25 0 AU-4-4c/STS-12c in STM-256/OC-768 12400 29 0 AU-4-4c/STS-12c in STM-256/OC-768 13100 33 0 AU-4-4c/STS-12c in STM-256/OC-768 13200 37 0 AU-4-4c/STS-12c in STM-256/OC-768 13300 41 0 AU-4-4c/STS-12c in STM-256/OC-768 13400 45 0 AU-4-4c/STS-12c in STM-256/OC-768 14100 49 0 AU-4-4c/STS-12c in STM-256/OC-768 14200 53 0 AU-4-4c/STS-12c in STM-256/OC-768 14300 57 0 AU-4-4c/STS-12c in STM-256/OC-768 14400 61 0 AU-4-4c/STS-12c in STM-256/OC-768 21100 65 0 AU-4-4c/STS-12c in STM-256/OC-768 21200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 21300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 21400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 22100 81 0 AU-4-4c/STS-12c in STM-256/OC-768 22200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 22300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 22400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 23100 97 0 AU-4-4c/STS-12c in STM-256/OC-768 23200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 23300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 23400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 24100 113 0 AU-4-4c/STS-12c in STM-256/OC-768 24200 117 0 AU-4-4c/STS-12c in STM-256/OC-768 24300 121 0 AU-4-4c/STS-12c in STM-256/OC-768 24400 125 0 AU-4-4c/STS-12c in STM-256/OC-768 31100 129 0 AU-4-4c/STS-12c in STM-256/OC-768 31200 133 0 AU-4-4c/STS-12c in STM-256/OC-768 31300 137 0 AU-4-4c/STS-12c in STM-256/OC-768 31400 141 0 AU-4-4c/STS-12c in STM-256/OC-768 32100 145 0 AU-4-4c/STS-12c in STM-256/OC-768 32200 149 0 AU-4-4c/STS-12c in STM-256/OC-768 32300 153 0 AU-4-4c/STS-12c in STM-256/OC-768 32400 157 0 AU-4-4c/STS-12c in STM-256/OC-768 33100 161 0 AU-4-4c/STS-12c in STM-256/OC-768 33200 165 0 AU-4-4c/STS-12c in STM-256/OC-768 33300 169 0 AU-4-4c/STS-12c in STM-256/OC-768 33400 173 0 AU-4-4c/STS-12c in STM-256/OC-768 34100 177 0 AU-4-4c/STS-12c in STM-256/OC-768 34200 181 0 AU-4-4c/STS-12c in STM-256/OC-768 34300 185 0 AU-4-4c/STS-12c in STM-256/OC-768 34400 189 0 AU-4-4c/STS-12c in STM-256/OC-768 41100 193 0 AU-4-4c/STS-12c in STM-256/OC-768 41200 197 0 AU-4-4c/STS-12c in STM-256/OC-768 41300 201 0 AU-4-4c/STS-12c in STM-256/OC-768 41400 205 0 AU-4-4c/STS-12c in STM-256/OC-768 42100 209 0 AU-4-4c/STS-12c in STM-256/OC-768 42200 213 0 AU-4-4c/STS-12c in STM-256/OC-768 42300 217 0 AU-4-4c/STS-12c in STM-256/OC-768 42400 221 0 AU-4-4c/STS-12c in STM-256/OC-768 43100 225 0 AU-4-4c/STS-12c in STM-256/OC-768 43200 229 0 AU-4-4c/STS-12c in STM-256/OC-768 43300 233 0 AU-4-4c/STS-12c in STM-256/OC-768 43400 237 0 AU-4-4c/STS-12c in STM-256/OC-768 44100 241 0 AU-4-4c/STS-12c in STM-256/OC-768 44200 245 0 AU-4-4c/STS-12c in STM-256/OC-768 44300 249 0 AU-4-4c/STS-12c in STM-256/OC-768 44400 253 0 AU-4-4c/STS-12c in STM-256/OC-768 11110 1 1 AU-4/STS-3c in STM-256/OC-768 11120 2 1 AU-4/STS-3c in STM-256/OC-768 11130 3 1 AU-4/STS-3c in STM-256/OC-768 11140 4 1 AU-4/STS-3c in STM-256/OC-768 11210 5 1 AU-4/STS-3c in STM-256/OC-768 11220 6 1 AU-4/STS-3c in STM-256/OC-768 11220 7 1 AU-4/STS-3c in STM-256/OC-768 11220 8 1 AU-4/STS-3c in STM-256/OC-768 11310 9 1 AU-4/STS-3c in STM-256/OC-768 : 11410 13 1 AU-4/STS-3c in STM-256/OC-768 : 12110 17 1 AU-4/STS-3c in STM-256/OC-768 : 12210 21 1 AU-4/STS-3c in STM-256/OC-768 : 12310 25 1 AU-4/STS-3c in STM-256/OC-768 : 12410 29 1 AU-4/STS-3c in STM-256/OC-768 : 13110 33 1 AU-4/STS-3c in STM-256/OC-768 : 13210 37 1 AU-4/STS-3c in STM-256/OC-768 : 13310 41 1 AU-4/STS-3c in STM-256/OC-768 : 13410 45 1 AU-4/STS-3c in STM-256/OC-768 : 14110 49 1 AU-4/STS-3c in STM-256/OC-768 : 14210 53 1 AU-4/STS-3c in STM-256/OC-768 : 14310 57 1 AU-4/STS-3c in STM-256/OC-768 : 14410 61 1 AU-4/STS-3c in STM-256/OC-768 : 21110 65 1 AU-4/STS-3c in STM-256/OC-768 : 21210 69 1 AU-4/STS-3c in STM-256/OC-768 : 21310 73 1 AU-4/STS-3c in STM-256/OC-768 : 21410 77 1 AU-4/STS-3c in STM-256/OC-768 : 22110 81 1 AU-4/STS-3c in STM-256/OC-768 : 22210 85 1 AU-4/STS-3c in STM-256/OC-768 : 22310 89 1 AU-4/STS-3c in STM-256/OC-768 : 22410 93 1 AU-4/STS-3c in STM-256/OC-768 : 23110 97 1 AU-4/STS-3c in STM-256/OC-768 : 23210 101 1 AU-4/STS-3c in STM-256/OC-768 : 23310 105 1 AU-4/STS-3c in STM-256/OC-768 : 23410 109 1 AU-4/STS-3c in STM-256/OC-768 : 24110 113 1 AU-4/STS-3c in STM-256/OC-768 : 24210 117 1 AU-4/STS-3c in STM-256/OC-768 : 24310 121 1 AU-4/STS-3c in STM-256/OC-768 : 24410 125 1 AU-4/STS-3c in STM-256/OC-768 : 31110 129 1 AU-4/STS-3c in STM-256/OC-768 : 31210 133 1 AU-4/STS-3c in STM-256/OC-768 : 31310 137 1 AU-4/STS-3c in STM-256/OC-768 : 31410 141 1 AU-4/STS-3c in STM-256/OC-768 : 32110 145 1 AU-4/STS-3c in STM-256/OC-768 : 32210 149 1 AU-4/STS-3c in STM-256/OC-768 : 32310 153 1 AU-4/STS-3c in STM-256/OC-768 : 32410 157 1 AU-4/STS-3c in STM-256/OC-768 : 33110 161 1 AU-4/STS-3c in STM-256/OC-768 : 33210 165 1 AU-4/STS-3c in STM-256/OC-768 : 33310 169 1 AU-4/STS-3c in STM-256/OC-768 : 33410 173 1 AU-4/STS-3c in STM-256/OC-768 : 34110 177 1 AU-4/STS-3c in STM-256/OC-768 : 34210 181 1 AU-4/STS-3c in STM-256/OC-768 : 34310 185 1 AU-4/STS-3c in STM-256/OC-768 : 34410 189 1 AU-4/STS-3c in STM-256/OC-768 : 41110 193 1 AU-4/STS-3c in STM-256/OC-768 : 41210 197 1 AU-4/STS-3c in STM-256/OC-768 : 41310 201 1 AU-4/STS-3c in STM-256/OC-768 : 41410 205 1 AU-4/STS-3c in STM-256/OC-768 : 42110 209 1 AU-4/STS-3c in STM-256/OC-768 : 42210 213 1 AU-4/STS-3c in STM-256/OC-768 : 42310 217 1 AU-4/STS-3c in STM-256/OC-768 : 42410 221 1 AU-4/STS-3c in STM-256/OC-768 : 43110 225 1 AU-4/STS-3c in STM-256/OC-768 : 43210 229 1 AU-4/STS-3c in STM-256/OC-768 : 43310 233 1 AU-4/STS-3c in STM-256/OC-768 : 43410 237 1 AU-4/STS-3c in STM-256/OC-768 : 44110 241 1 AU-4/STS-3c in STM-256/OC-768 : 44210 245 1 AU-4/STS-3c in STM-256/OC-768 : 44310 249 1 AU-4/STS-3c in STM-256/OC-768 : 44410 253 1 AU-4/STS-3c in STM-256/OC-768 44420 254 1 AU-4/STS-3c in STM-256/OC-768 44430 255 1 AU-4/STS-3c in STM-256/OC-768 44440 256 1 AU-4/STS-3c in STM-256/OC-768 11111 1 2 AU-3/STS-1 in STM-256/OC-768 11112 1 3 AU-3/STS-1 in STM-256/OC-768 11113 1 4 AU-3/STS-1 in STM-256/OC-768 11121 2 2 AU-3/STS-1 in STM-256/OC-768 11122 2 3 AU-3/STS-1 in STM-256/OC-768 11123 2 4 AU-3/STS-1 in STM-256/OC-768 : 11131 3 2 AU-3/STS-1 in STM-256/OC-768 : 11141 4 2 AU-3/STS-1 in STM-256/OC-768 : 11211 5 2 AU-3/STS-1 in STM-256/OC-768 : 11311 9 2 AU-3/STS-1 in STM-256/OC-768 : 11411 13 2 AU-3/STS-1 in STM-256/OC-768 : 12111 17 2 AU-3/STS-1 in STM-256/OC-768 : 12211 21 2 AU-3/STS-1 in STM-256/OC-768 : 12311 25 2 AU-3/STS-1 in STM-256/OC-768 : 12411 29 2 AU-3/STS-1 in STM-256/OC-768 : 13111 33 2 AU-3/STS-1 in STM-256/OC-768 : 13211 37 2 AU-3/STS-1 in STM-256/OC-768 : 13311 41 2 AU-3/STS-1 in STM-256/OC-768 : 13411 45 2 AU-3/STS-1 in STM-256/OC-768 : 14111 49 2 AU-3/STS-1 in STM-256/OC-768 : 14211 53 2 AU-3/STS-1 in STM-256/OC-768 : 14311 57 2 AU-3/STS-1 in STM-256/OC-768 : 14411 61 2 AU-3/STS-1 in STM-256/OC-768 : 21111 65 2 AU-3/STS-1 in STM-256/OC-768 : 21211 69 2 AU-3/STS-1 in STM-256/OC-768 : 21311 73 2 AU-3/STS-1 in STM-256/OC-768 : 21411 77 2 AU-3/STS-1 in STM-256/OC-768 : 22111 81 2 AU-3/STS-1 in STM-256/OC-768 : 22211 85 2 AU-3/STS-1 in STM-256/OC-768 : 22311 89 2 AU-3/STS-1 in STM-256/OC-768 : 22411 93 2 AU-3/STS-1 in STM-256/OC-768 : 23111 97 2 AU-3/STS-1 in STM-256/OC-768 : 23211 101 2 AU-3/STS-1 in STM-256/OC-768 : 23311 105 2 AU-3/STS-1 in STM-256/OC-768 : 23411 109 2 AU-3/STS-1 in STM-256/OC-768 : 24111 113 2 AU-3/STS-1 in STM-256/OC-768 : 24211 117 2 AU-3/STS-1 in STM-256/OC-768 : 24311 121 2 AU-3/STS-1 in STM-256/OC-768 : 24411 125 2 AU-3/STS-1 in STM-256/OC-768 : 31111 129 2 AU-3/STS-1 in STM-256/OC-768 : 31211 133 2 AU-3/STS-1 in STM-256/OC-768 : 31311 137 2 AU-3/STS-1 in STM-256/OC-768 : 31411 141 2 AU-3/STS-1 in STM-256/OC-768 : 32111 145 2 AU-3/STS-1 in STM-256/OC-768 : 32211 149 2 AU-3/STS-1 in STM-256/OC-768 : 32311 153 2 AU-3/STS-1 in STM-256/OC-768 : 32411 157 2 AU-3/STS-1 in STM-256/OC-768 : 33111 161 2 AU-3/STS-1 in STM-256/OC-768 : 33211 165 2 AU-3/STS-1 in STM-256/OC-768 : 33311 169 2 AU-3/STS-1 in STM-256/OC-768 : 33411 173 2 AU-3/STS-1 in STM-256/OC-768 : 34111 177 2 AU-3/STS-1 in STM-256/OC-768 : 34211 181 2 AU-3/STS-1 in STM-256/OC-768 : 34311 185 2 AU-3/STS-1 in STM-256/OC-768 : 34411 189 2 AU-3/STS-1 in STM-256/OC-768 : 41111 193 2 AU-3/STS-1 in STM-256/OC-768 : 41211 197 2 AU-3/STS-1 in STM-256/OC-768 : 41311 211 2 AU-3/STS-1 in STM-256/OC-768 : 41411 215 2 AU-3/STS-1 in STM-256/OC-768 : 42111 219 2 AU-3/STS-1 in STM-256/OC-768 : 42211 213 2 AU-3/STS-1 in STM-256/OC-768 : 42311 217 2 AU-3/STS-1 in STM-256/OC-768 : 42411 221 2 AU-3/STS-1 in STM-256/OC-768 : 43111 225 2 AU-3/STS-1 in STM-256/OC-768 : 43211 229 2 AU-3/STS-1 in STM-256/OC-768 : 43311 233 2 AU-3/STS-1 in STM-256/OC-768 : 43411 237 2 AU-3/STS-1 in STM-256/OC-768 : 44111 241 2 AU-3/STS-1 in STM-256/OC-768 : 44211 245 2 AU-3/STS-1 in STM-256/OC-768 : 44311 249 2 AU-3/STS-1 in STM-256/OC-768 : 44411 253 2 AU-3/STS-1 in STM-256/OC-768 : 44421 254 2 AU-3/STS-1 in STM-256/OC-768 : 44431 255 2 AU-3/STS-1 in STM-256/OC-768 : 44441 256 2 AU-3/STS-1 in STM-256/OC-768 44442 256 3 AU-3/STS-1 in STM-256/OC-768 44443 256 4 AU-3/STS-1 in STM-256/OC-768 G.707 DCBA S U Signal Type ========================================= 0000 1 0 AU-4-64c/STS-192c in STM-64/OC-192 1000 1 0 AU-4-16c/STS-48c in STM-64/OC-192 2000 17 0 AU-4-16c/STS-48c in STM-64/OC-192 3000 33 0 AU-4-16c/STS-48c in STM-64/OC-192 4000 49 0 AU-4-16c/STS-48c in STM-64/OC-192 1100 1 0 AU-4-4c/STS-12c in STM-64/OC-192 1200 5 0 AU-4-4c/STS-12c in STM-64/OC-192 1300 9 0 AU-4-4c/STS-12c in STM-64/OC-192 1400 13 0 AU-4-4c/STS-12c in STM-64/OC-192 2100 17 0 AU-4-4c/STS-12c in STM-64/OC-192 2200 21 0 AU-4-4c/STS-12c in STM-64/OC-192 2300 25 0 AU-4-4c/STS-12c in STM-64/OC-192 2400 29 0 AU-4-4c/STS-12c in STM-64/OC-192 3100 33 0 AU-4-4c/STS-12c in STM-64/OC-192 3200 37 0 AU-4-4c/STS-12c in STM-64/OC-192 3300 41 0 AU-4-4c/STS-12c in STM-64/OC-192 3400 45 0 AU-4-4c/STS-12c in STM-64/OC-192 4100 49 0 AU-4-4c/STS-12c in STM-64/OC-192 4200 53 0 AU-4-4c/STS-12c in STM-64/OC-192 4300 57 0 AU-4-4c/STS-12c in STM-64/OC-192 4400 61 0 AU-4-4c/STS-12c in STM-64/OC-192 1110 1 1 AU-4/STS-3c in STM-64/OC-192 1120 2 1 AU-4/STS-3c in STM-64/OC-192 1130 3 1 AU-4/STS-3c in STM-64/OC-192 1140 4 1 AU-4/STS-3c in STM-64/OC-192 1210 5 1 AU-4/STS-3c in STM-64/OC-192 1220 6 1 AU-4/STS-3c in STM-64/OC-192 1220 7 1 AU-4/STS-3c in STM-64/OC-192 1220 8 1 AU-4/STS-3c in STM-64/OC-192 1310 9 1 AU-4/STS-3c in STM-64/OC-192 : 1410 13 1 AU-4/STS-3c in STM-64/OC-192 : 2110 17 1 AU-4/STS-3c in STM-64/OC-192 : 2210 21 1 AU-4/STS-3c in STM-64/OC-192 : 2310 25 1 AU-4/STS-3c in STM-64/OC-192 : 2410 29 1 AU-4/STS-3c in STM-64/OC-192 : 3110 33 1 AU-4/STS-3c in STM-64/OC-192 : 3210 37 1 AU-4/STS-3c in STM-64/OC-192 : 3310 41 1 AU-4/STS-3c in STM-64/OC-192 : 3410 45 1 AU-4/STS-3c in STM-64/OC-192 : 4110 49 1 AU-4/STS-3c in STM-64/OC-192 : 4210 53 1 AU-4/STS-3c in STM-64/OC-192 : 4310 57 1 AU-4/STS-3c in STM-64/OC-192 : 4410 61 1 AU-4/STS-3c in STM-64/OC-192 4420 62 1 AU-4/STS-3c in STM-64/OC-192 4430 63 1 AU-4/STS-3c in STM-64/OC-192 4440 64 1 AU-4/STS-3c in STM-64/OC-192 1111 1 2 AU-3/STS-1 in STM-64/OC-192 1112 1 3 AU-3/STS-1 in STM-64/OC-192 1113 1 4 AU-3/STS-1 in STM-64/OC-192 1121 2 2 AU-3/STS-1 in STM-64/OC-192 1122 2 3 AU-3/STS-1 in STM-64/OC-192 1123 2 4 AU-3/STS-1 in STM-64/OC-192 : 1131 3 2 AU-3/STS-1 in STM-64/OC-192 : 1141 4 2 AU-3/STS-1 in STM-64/OC-192 : 1211 5 2 AU-3/STS-1 in STM-64/OC-192 : 1311 9 2 AU-3/STS-1 in STM-64/OC-192 : 1411 13 2 AU-3/STS-1 in STM-64/OC-192 : 2111 17 2 AU-3/STS-1 in STM-64/OC-192 : 2211 21 2 AU-3/STS-1 in STM-64/OC-192 : 2311 25 2 AU-3/STS-1 in STM-64/OC-192 : 2411 29 2 AU-3/STS-1 in STM-64/OC-192 : 3111 33 2 AU-3/STS-1 in STM-64/OC-192 : 3211 37 2 AU-3/STS-1 in STM-64/OC-192 : 3311 41 2 AU-3/STS-1 in STM-64/OC-192 : 3411 45 2 AU-3/STS-1 in STM-64/OC-192 : 4111 49 2 AU-3/STS-1 in STM-64/OC-192 : 4211 53 2 AU-3/STS-1 in STM-64/OC-192 : 4311 57 2 AU-3/STS-1 in STM-64/OC-192 : 4411 61 2 AU-3/STS-1 in STM-64/OC-192 : 4441 63 2 AU-3/STS-1 in STM-64/OC-192 4442 64 3 AU-3/STS-1 in STM-64/OC-192 4443 65 4 AU-3/STS-1 in STM-64/OC-192 G.707 CBA S U Signal Type ========================================= 000 1 0 AU-4-16c/STS-48c in STM-16/OC-48 100 1 0 AU-4-4c/STS-12c in STM-16/OC-48 200 5 0 AU-4-4c/STS-12c in STM-16/OC-48 300 9 0 AU-4-4c/STS-12c in STM-16/OC-48 400 13 0 AU-4-4c/STS-12c in STM-16/OC-48 110 1 1 AU-4/STS-3c in STM-16/OC-48 120 2 1 AU-4/STS-3c in STM-16/OC-48 130 3 1 AU-4/STS-3c in STM-16/OC-48 140 4 1 AU-4/STS-3c in STM-16/OC-48 210 5 1 AU-4/STS-3c in STM-16/OC-48 220 6 1 AU-4/STS-3c in STM-16/OC-48 220 7 1 AU-4/STS-3c in STM-16/OC-48 220 8 1 AU-4/STS-3c in STM-16/OC-48 310 9 1 AU-4/STS-3c in STM-16/OC-48 320 10 1 AU-4/STS-3c in STM-16/OC-48 330 11 1 AU-4/STS-3c in STM-16/OC-48 340 12 1 AU-4/STS-3c in STM-16/OC-48 410 13 1 AU-4/STS-3c in STM-16/OC-48 420 14 1 AU-4/STS-3c in STM-16/OC-48 430 15 1 AU-4/STS-3c in STM-16/OC-48 440 16 1 AU-4/STS-3c in STM-16/OC-48 111 1 2 AU-3/STS-1 in STM-16/OC-48 112 1 3 AU-3/STS-1 in STM-16/OC-48 113 1 4 AU-3/STS-1 in STM-16/OC-48 121 2 2 AU-3/STS-1 in STM-16/OC-48 122 2 3 AU-3/STS-1 in STM-16/OC-48 123 2 4 AU-3/STS-1 in STM-16/OC-48 131 3 2 AU-3/STS-1 in STM-16/OC-48 132 3 3 AU-3/STS-1 in STM-16/OC-48 133 3 4 AU-3/STS-1 in STM-16/OC-48 141 4 2 AU-3/STS-1 in STM-16/OC-48 : 211 5 2 AU-3/STS-1 in STM-16/OC-48 : 311 9 2 AU-3/STS-1 in STM-16/OC-48 : 411 13 2 AU-3/STS-1 in STM-16/OC-48 : 441 16 2 AU-3/STS-1 in STM-16/OC-48 442 16 3 AU-3/STS-1 in STM-16/OC-48 443 16 4 AU-3/STS-1 in STM-16/OC-48 G.707 BA S U Signal Type ========================================= 00 1 0 AU-4-4c/STS-12c in STM-4/OC-12 10 1 1 AU-4/STS-3c in STM-4/OC-12 20 2 1 AU-4/STS-3c in STM-4/OC-12 30 3 1 AU-4/STS-3c in STM-4/OC-12 40 4 1 AU-4/STS-3c in STM-4/OC-12 11 1 2 AU-3/STS-1 in STM-4/OC-12 12 1 3 AU-3/STS-1 in STM-4/OC-12 13 1 4 AU-3/STS-1 in STM-4/OC-12 21 2 2 AU-3/STS-1 in STM-4/OC-12 22 2 3 AU-3/STS-1 in STM-4/OC-12 23 2 4 AU-3/STS-1 in STM-4/OC-12 31 3 2 AU-3/STS-1 in STM-4/OC-12 32 3 3 AU-3/STS-1 in STM-4/OC-12 33 3 4 AU-3/STS-1 in STM-4/OC-12 41 4 2 AU-3/STS-1 in STM-4/OC-12 42 4 3 AU-3/STS-1 in STM-4/OC-12 43 4 4 AU-3/STS-1 in STM-4/OC-12 G.707 A S U Signal Type ========================================= 0 1 1 AU-4/STS-3c in STM-1/OC-3 1 1 2 AU-3/STS-1 in STM-1/OC-3 2 1 3 AU-3/STS-1 in STM-1/OC-3 3 1 4 AU-3/STS-1 in STM-1/OC-3 --------------796300C60EC73EF388C167C9 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------796300C60EC73EF388C167C9-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 07:39:34 -0700 Message-ID: <3B40869F.75DCDF48@lucent.com> Date: Mon, 02 Jul 2001 10:35:11 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Eric Gray CC: "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, I was about to keep quite... Because of recent discussions, here is my comments to your previous example in-lines. I am OK with current suggested label, label set etc. However I want to figure out the real application in circuit switching network and please help me about it. Thanks a lot. [snipped] > > > > > > > Would you please give me an example that what I said is not true? > > > Local significance - not every switch in an optical domain is necessarily > capable of performing the same kind of "optical switching". This does not > mean that they cannot interoperate - but it does mean that they may not > interoperate in the way that you expect. Can you give me an "example", I mean a real one? Please specify what type of circuit switches you are talking about, what's their functions etc. I have heard too many hyperthetical applications that don't exist at all. > Under these circumstances, the > choice of "label" may have greater than local significance. Then that's routing constrains and you can specify certain routing constrains at the signaling time. Label itself only has local significance. > Moreover, you > cannot end up lambda switching two light beams of the same color into > a single piece of glass. If you don't have any type of multiplexing mechanisms. It doesn't matter they are the same color or not. Otherwise, indeed you can, and it depends on your multiplexing and modulation mechanisms (. You are probably only talking about wavelength multiplexing. For that specific case, you may be right. Sorry, this is just a side topic. > > Upstream/Downstream indifference of choice - true in optical networks (at > least "Normally"), but not particularly relevant. One or the other MUST > have the final say and the model to-date has been that the final word is > given by the downstream. Given that there MAY BE a scenario in which one > or the other has less than complete knowledge, it is necessary to have a > negotiation/arbitration mechanism. > I think the upstream/downstream nodes are symmetric in circuit switching network. I am looking an example to show me that your "MAY BE" is true. BTW, I have concern about the definition of upstream/downstream. Their definitions in RFC 3031 need modifications for GMPLS. Thanks, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 07:06:00 -0700 Message-ID: <47D99458148BD411BE2E0090276155790228CA7D@njc240po04.mt.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Maarten Vissers'" , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: GMPLS Doubt Date: Mon, 2 Jul 2001 10:04:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Agree with Maarten to support as a single type. Also, the versions of the standards should not be differentiated. I had posted a previous mail questioning the need for this to the exploder. The latest versions provide for interworking with legacy equipment. E.g. T1.105-2000 defines J0 as 1-byte or 16-byte and provides for interworking with equipment not supporting J0. Defining a label for the 1995 version and the 2000 version does not add any descriptive value and only will confuse interworking. As Maarten notes, these differences need to be treated in a generic manner. Deborah Brungard AT&T -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Monday, July 02, 2001 7:29 AM To: manoj juneja Cc: ccamp@ops.ietf.org Subject: Re: GMPLS Doubt Manoj, manoj juneja wrote: > > Hi All, > In the draft draft-ietf-mpls-generalized-signalling-04.txt, > different values of LSP encoding type are defined. What all values > of LSP encoding type are currently supported by GMPLS ? > > The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH > etc. More work is to be done here it seems... It should be possible to request e.g. a DS1 or DS3 connection through a SDH/SONET network. When crossing the UNI, the DS1/DS3 connection request is converted into a VT1.5/STS1 connection request within the SDH/SONET network. So perhaps only the UNI format is required. > I think the only supported values of LSP encoding type are : > > SDH ITU-T G.707 1996 > SONET ANSI T1.105-1995 > SDH ITU-T G.707 2000 > SONET ANSI T1.105-2000 SDH and SONET can be treated as a single type, and this is the direction in the development of G.ason (ITU-T). Let's make sure that GMPLS does follow this; otherwise confusion will be the result. Note that a number of the presumed differences between SONET and SDH may also be present between SDH and SDH (e.g. 16/64 byte trace identifiers). And similarly, some of the presumed SONET/SDH differences may also be present between SONET and SONET (e.g. PDI, E-RDI). The interworking issues associated with these "differences" must thus be treated in a generic SONET/SDH independent manner. Regards, Maarten > Fiber > Lambda > Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ] > > Please comment. > > Regards, > manoj. > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 06:44:15 -0700 Message-ID: <3B407AA0.E82ED70A@sandburst.com> Date: Mon, 02 Jul 2001 09:44:00 -0400 From: Eric Gray MIME-Version: 1.0 To: Suresh Katukam Cc: ccamp@ops.ietf.org Subject: Re: Label Set and Suggested Label Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Suresh, Unfortunately, the current wording is: "There are four cases where a Label Set is useful in the optical domain." It is arguable that your examples are more properly in the TDM domain, but section 3.5 of "draft-ietf-mpls-generalized-signaling-04" does not seem to leave much room for generalizing the label set in this way. It should probably say either that these are examples that apply to the optical domain (other uses may exist for other domains) or - better - still it should simply state these as a few examples and leave it at that. There is nothing to be gained by guessing what the authors meant - they must make it clear. -- Eric Gray You wrote: > Manoj, > > > In the GMPLS drafts, it is mentioned that the use of label set > > is in the following cases : > > > > a) End equipment is only capable of transmitting and > > receiving on a small set of wavelengths. > > b) There are sequence of interfaces which can't support > > wavelength conversion. > > c) It is desireable to limit the amount of wavelength > > conversion to reduce the distortion on the optical > > signals. > > d) Two ends of a link support different sets of wavelengths. > > > > All the above four points are valid only in case LSP encoding type is > > lambda. Does this mean if a label set is received in cases where LSP > > encoding type is other than Lambda, it should be ignored or considered > > protocol error ? > > I am not sure whether it is the intention of GMPLS authors to list > all possible scenerios under which a label set is used. There are > other scenerios under which label set can be used. In TDM, for example, > one may want to use same time slot (for BLSRs) assigned along the > entire BLSR segment. In such a scenerio, BLSR headend lists all available > labels and forwards the PATH message. Each node in BLSR knows what > label to use when it receives a RESV message. > > There may be other reasons too. In anycase, you should not consider > that to be a protocol error. > > Thanks, > Suresh > > > > What about the suggested Label ? Is it also defined to take care of > > specific LSP encoding type ? > > > > Please Clarify. > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 06:42:25 -0700 Message-Id: <4.3.2.7.2.20010702094348.01993ce0@bucket.cisco.com> Date: Mon, 02 Jul 2001 09:45:04 -0400 To: Eric Gray From: "Thomas D. Nadeau" Subject: Re: lmp mib Cc: bhaskara@turinnetworks.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3390825==_.ALT" --=====================_3390825==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed > Does it make sense that we would ever need a negative >enumeration? I don't think so. Let me know if you do. --Tom >-- >Eric Gray > >You wrote: >> >> I believe that the correct value should be >>INTEGER due to it being an enumeration. We will >>fix this in the next revision. >> >> --Tom >> >> >> >>>In lmpTeLinkTable of "draft-dubuc-lmp-mib-02.txt" , >>>lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and >>>when it is >>> >>>defined it is given as INTEGER type. which one is correct? >>> >>>thanks >>>regards >>>bhaskara --=====================_3390825==_.ALT Content-Type: text/html; charset="us-ascii"
        
   Does it make sense that we would ever need a negative
enumeration?

        I don't think so. Let me know if you do.

        --Tom





--
Eric Gray

You wrote:
 
        I believe that the correct value should be
INTEGER due to it being an enumeration. We will
fix this in the next revision.

        --Tom
 
 
 
In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and when it is

defined it is given as INTEGER type.  which one is correct?

thanks
regards
bhaskara
--=====================_3390825==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 06:30:30 -0700 Message-ID: <3B407739.94A71760@sandburst.com> Date: Mon, 02 Jul 2001 09:29:29 -0400 From: Eric Gray MIME-Version: 1.0 To: "Thomas D. Nadeau" Cc: bhaskara@turinnetworks.com, ccamp@ops.ietf.org Subject: Re: lmp mib Content-Type: multipart/alternative; boundary="------------0F7430FDF298EA1B78D85C6B" --------------0F7430FDF298EA1B78D85C6B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom, Does it make sense that we would ever need a negative enumeration? -- Eric Gray You wrote: > > I believe that the correct value should be > INTEGER due to it being an enumeration. We will > fix this in the next revision. > > --Tom > > > > >> In lmpTeLinkTable of "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType >> SYNTAX is given as uint32 in table entry index and when it is >> >> defined it is given as INTEGER type. which one is correct? >> >> thanks >> regards >> bhaskara > --------------0F7430FDF298EA1B78D85C6B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tom,

    Does it make sense that we would ever need a negative
enumeration?

--
Eric Gray

You wrote:

 
I believe that the correct value should be
INTEGER due to it being an enumeration. We will
fix this in the next revision.

--Tom
 
 
 

In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and when it is

defined it is given as INTEGER type.  which one is correct?

thanks
regards
bhaskara

--------------0F7430FDF298EA1B78D85C6B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 04:30:46 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B405AEE.5FE01494@lucent.com> Date: Mon, 02 Jul 2001 13:28:46 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: GMPLS Doubt Content-Type: multipart/mixed; boundary="------------3F984BDEC16F0909332410FA" This is a multi-part message in MIME format. --------------3F984BDEC16F0909332410FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, manoj juneja wrote: > > Hi All, > In the draft draft-ietf-mpls-generalized-signalling-04.txt, > different values of LSP encoding type are defined. What all values > of LSP encoding type are currently supported by GMPLS ? > > The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH > etc. More work is to be done here it seems... It should be possible to request e.g. a DS1 or DS3 connection through a SDH/SONET network. When crossing the UNI, the DS1/DS3 connection request is converted into a VT1.5/STS1 connection request within the SDH/SONET network. So perhaps only the UNI format is required. > > I think the only supported values of LSP encoding type are : > > SDH ITU-T G.707 1996 > SONET ANSI T1.105-1995 > SDH ITU-T G.707 2000 > SONET ANSI T1.105-2000 SDH and SONET can be treated as a single type, and this is the direction in the development of G.ason (ITU-T). Let's make sure that GMPLS does follow this; otherwise confusion will be the result. Note that a number of the presumed differences between SONET and SDH may also be present between SDH and SDH (e.g. 16/64 byte trace identifiers). And similarly, some of the presumed SONET/SDH differences may also be present between SONET and SONET (e.g. PDI, E-RDI). The interworking issues associated with these "differences" must thus be treated in a generic SONET/SDH independent manner. Regards, Maarten > Fiber > Lambda > Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ] > > Please comment. > > Regards, > manoj. > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------3F984BDEC16F0909332410FA Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------3F984BDEC16F0909332410FA-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 00:50:03 -0700 Cc: "'manoj juneja'" , ccamp@ops.ietf.org Message-ID: <3B402785.9F9BD0BC@lucent.com> Date: Mon, 02 Jul 2001 09:49:25 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'manoj juneja'" , ccamp@ops.ietf.org Subject: Re: {SUKLM} numbering scheme Content-Type: multipart/mixed; boundary="------------EFE993FBDD9E9E60453FD418" This is a multi-part message in MIME format. --------------EFE993FBDD9E9E60453FD418 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, I would like to propose to include the conversion scheme (formula and/or table) in an appendix to GMPLS SONET/SDH extension document. Might be helpful to readers of both G.707 and GMPLS. Otherwise I fear people keep asking for it. Regards, Maarten "Mannie, Eric" wrote: > > Hello Manoj, > > The label is the same of course. > > The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a > small bug coming from an old version. That should be removed by Lou. We > should have only one SDH LSP encoding type value for SDH (same for SONET). > > Lou: thanks to correct it. > > For the conversion table, Maarten should still have it. > > Kind regards, > > Eric > > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Thursday, June 28, 2001 8:28 PM > To: ccamp@ops.ietf.org > Subject: {SUKLM} numbering scheme > > Hi All, > I have a doubt regarding {SUKLM} numbering scheme. If I > allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be > different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH > ITU-T G.707 2000 ? > > Eric, on the ipo u and marteen once exchanged the conversion table for > EDCBA and SU, If that table is correct, can u please tell me the > formula from which u derived that table ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------EFE993FBDD9E9E60453FD418 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------EFE993FBDD9E9E60453FD418-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jul 2001 00:46:17 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B40264C.39F07DB6@lucent.com> Date: Mon, 02 Jul 2001 09:44:12 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: LSP Encoding Type Content-Type: multipart/mixed; boundary="------------DE3989A67A8F0498A3DB6ADF" This is a multi-part message in MIME format. --------------DE3989A67A8F0498A3DB6ADF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, The G.707 1996 and 2000 indications are artificial indications not supported by ITU-T. SDH equipment is not designed to meet either 1996 or 2000 versions of G.707. IETF better drops this from GMPLS as it will only cause confusion in my opnion. For your implementation, my recommendation is to simply ignore this. Concerning AUG-X support, G.707 doesn't support it and neither does T1.105. It's a proprietary extension of SDH/SONET. Regards, Maarten manoj juneja wrote: > > Hi All, > If a particular implementation supports LSP encoding type as > SDH ITU-T G-707 1996, Does this mean it can't support signals like > AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------DE3989A67A8F0498A3DB6ADF Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet: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 --------------DE3989A67A8F0498A3DB6ADF-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 01 Jul 2001 07:14:04 -0700 Message-Id: <4.3.2.7.2.20010701101005.0277de38@bucket.cisco.com> Date: Sun, 01 Jul 2001 10:11:27 -0400 To: bhaskara@turinnetworks.com, ccamp@ops.ietf.org, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: lmp mib Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2930684==_.ALT" --=====================_2930684==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I believe that the correct value should be INTEGER due to it being an enumeration. We will fix this in the next revision. --Tom >In lmpTeLinkTable of "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType >SYNTAX is given as uint32 in table entry index and when it is > >defined it is given as INTEGER type. which one is correct? > >thanks >regards >bhaskara --=====================_2930684==_.ALT Content-Type: text/html; charset="us-ascii"
        I believe that the correct value should be
INTEGER due to it being an enumeration. We will
fix this in the next revision.

        --Tom



In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType SYNTAX is given as uint32 in table entry index and when it is

defined it is given as INTEGER type.  which one is correct?

thanks
regards
bhaskara
--=====================_2930684==_.ALT--