Subject: Confirmation for subscribe ccamp

From: [email-masked]
Date: Sat, 06 Apr 2002 00:51:44 -0800

--

Someone (possibly you) has requested that your email address be added
to or deleted from the mailing list "[email-masked]".

If you really want this action to be taken, please send the following
commands (exactly as shown) back to "[email-masked]":

	auth 814be824f832613ede6200d498fdab86 subscribe ccamp [email-masked]

If you do not want this action to be taken, simply ignore this message
and the request will be disregarded.

If your mailer will not allow you to send the entire command as a single
line, you may split it using backslashes, like so:

        auth 814be824f832613ede6200d498fdab86 subscribe ccamp \
        [email-masked]

If you have any questions about the policy of the list owner, please
contact "[email-masked]".

Thanks!

[email-masked]

Delivery-date: Tue, 30 Apr 2002 21:53:21 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Profile parameter in SDH/SONET traffic Params
Date: Tue, 30 Apr 2002 15:37:56 -0700

[ post by non-subscriber ]

Hi All,
        In the new version of the draft 
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt, a new parameter named "Profile" has 
been added in SDH/SONET traffic parameters. As OIF's O-UNI is also using 
this parameter, does this mean that this parameter got changed for O-UNI 
requirements also ?

If this parameter is required only for GMPLS, please indicate that too.

I think OIF's O-UNI makes a reference to this ccamp draft.

Please help me in understanding this issue.

Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Tue, 30 Apr 2002 14:36:22 -0700
Date: Tue, 30 Apr 2002 17:34:28 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: [email-masked]

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

Dear Michiel,

Sorry for the delay in the reply, please see comments in-lined.

Thanks

Regards... Zafar

At 05:57 PM 4/29/2002 +0200, Michiel van Everdingen wrote:
>Hello Zafar,
>
> > > the RSVP-TE "notify message" is sent between
> > > non-adjacent (at transmission plane) nodes in case it is "encapsulated
> > > in a new IP header whose destination is equal to the target IP address."
> > > [RSVP-TE, section 4.3]
> >
> > The notify message with the above mentioned option is also sent over the
> > control network, like other signaling messages.  I did not see the
> > relationship here. Can you please elaborate a bit further why you are
> > mentioning this here?
>
>You talk here about "control network". I tried to focus on the "network"
>part in that "control network".
>
> From a.o. the following sentences of the LMP draft, I deduce that
>"control channels" are only present between two nodes that are neighbors
>at the transmission plane:

Yes, this is correct. Control channels are between the LMP peers running on 
the adjacent nodes. But please note that such nodes may not be adjacent in 
the control network topology.

>"This draft specifies a link management protocol (LMP) that runs between
>  neighboring nodes and is used to manage TE links."
>"In GMPLS, the control channels between two adjacent nodes ..."
>
>However, it seems that not all signaling messages are between adjacent
>nodes (adjacent at the transmission plane). I used the "notify message"
>as an example: "The Notify message provides a mechanism to inform non-
>adjacent nodes of LSP related events" [RSVP-TE, section 4.3].

The notify message can be sent as an IP packet over the control network, 
whose processing will be similar to the similar ResvConf message. In the 
case you like to avoid a L3 entity (RSVP) to be involved at each hop, the 
option of encapsulating them in a new IP header whose destination is equal 
to the target IP address can be used, as you quoted in your email.

>So, assuming a "control network" is built from "control channels",

No, instead I would say that control channels are established over a 
control network.

>this
>"control network" needs to be able to route signaling messages through
>a series of "control channels".

No, it's the applications (e.g., LMP) that have a view of the control 
channels; the network does not know about them or does not use them in 
routing.

>This makes it a real network layer in my
>mind, with associated routing protocol etc.
>
>
> > > So in other words, the proposal is to create an extra "network layer"
> > > (OSI terminology) consisting of "signalling channels". These "signalling
> > > channels" make use of underlying "control channels" which again can make
> > > use of any generic network layer (e.g. DCN). Correct ?
> >
> > No, I don't think so. Just because we've a peer to peer protocol for
> > detecting health of the control channels, IMO, does not mean that we've
> > introduced an extra "network layer". Control network is still managed
> > like any other (IP) network.
>
>As mentioned above: I assumed that a "control network" is built from "control
>channels".

No, please see comments above.

>If this assumption is correct: I think we are building a "control network" 
>(L3)
>on top of "control channels" (L2). "Control channels" (L2) make use of any
>generic network layer (L3, e.g. DCN).
>
>If this assumption is wrong: I can now only deduce that "control channels"
>are a kind if "ping" mechanism to detect point-to-point aliveness of the
>"control network".

I would like to refer to Jonathan's reply to this.

>Please consider the following very simple topology:
>
>     +-----+                     +-----+
>     |     | ................... |     |
>     |  A  |                     |  B  |
>     |     |                     |     |
>     +-----+                     +-----+
>          \ .                   . /
>           \ .                 . /
>            \ .               . /
>             \ .             . /
>              \ .           . /
>               \ . +-----+ . /
>                \ .|     |. /
>                 \ |  C  | /
>                   |     |
>                   +-----+
>
>....: DCN topology (e.g. using a LAN connection between A&B)
>----: transmission topology (the "dataLink"s)
>
>In case the fibre A-C (with associated DCC channel) breaks, the DCN
>network can still find a path between A and C: A-B-C. Correct ?
>So in case of such a fibre failure, you would say that the (routed)
>"control channel" is still alive. Correct ?
>
>If "control channels" are nothing more than the standard "ping" mechanism,
>why not use this standard "ping" mechanism ?

Again, I would like to refer to Jonathan's reply.

>If "control channels" does provide more than standard "ping", could you
>please let me know what that would be (and why that would be mandatorily
>needed) ?
>
>I think I first need clarity on the relation between "control network" and
>"control channel" before being able to comment on your other points.
>
>
>Thanks !
>
>Michiel
><snip>
><...snip...>
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

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

<html>
<font size=3>Dear Michiel, <br>
<br>
Sorry for the delay in the reply, please see comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
At 05:57 PM 4/29/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=cite cite>Hello Zafar,<br>
<br>
&gt; &gt; the RSVP-TE &quot;notify message&quot; is sent between<br>
&gt; &gt; non-adjacent (at transmission plane) nodes in case it is
&quot;encapsulated<br>
&gt; &gt; in a new IP header whose destination is equal to the target IP
address.&quot;<br>
&gt; &gt; [RSVP-TE, section 4.3]<br>
&gt; <br>
&gt; The notify message with the above mentioned option is also sent over
the<br>
&gt; control network, like other signaling messages.&nbsp; I did not see
the<br>
&gt; relationship here. Can you please elaborate a bit further why you
are<br>
&gt; mentioning this here?<br>
<br>
You talk here about &quot;control network&quot;. I tried to focus on the
&quot;network&quot;<br>
part in that &quot;control network&quot;.<br>
<br>
 From a.o. the following sentences of the LMP draft, I deduce that<br>
&quot;control channels&quot; are only present between two nodes that are
neighbors<br>
at the transmission plane:</font></blockquote><br>
Yes, this is correct. Control channels are between the LMP peers running
on the adjacent nodes. But please note that such nodes may not be
adjacent in the control network topology. <br>
<br>
<blockquote type=cite cite><font size=3>&quot;This draft specifies a link
management protocol (LMP) that runs between<br>
&nbsp;neighboring nodes and is used to manage TE links.&quot;<br>
&quot;In GMPLS, the control channels between two adjacent nodes
...&quot;<br>
<br>
However, it seems that not all signaling messages are between
adjacent<br>
nodes (adjacent at the transmission plane). I used the &quot;notify
message&quot;<br>
as an example: &quot;The Notify message provides a mechanism to inform
non-<br>
adjacent nodes of LSP related events&quot; [RSVP-TE, section
4.3].</font></blockquote><br>
The notify message can be sent as an IP packet over the control network,
whose processing will be similar to the <font size=3>similar ResvConf
message</font>. In the case you like to avoid a L3 entity (RSVP) to be
involved at each hop, the option of <font size=3>encapsulating them in a
new IP header whose destination is equal to the target IP address can be
used, as you quoted in your email. <br>
<br>
<br>
<blockquote type=cite cite>So, assuming a &quot;control network&quot; is
built from &quot;control channels&quot;, </font></blockquote><br>
No, instead I would say that control channels are established over a
control network. <br>
<br>
<blockquote type=cite cite><font size=3>this<br>
&quot;control network&quot; needs to be able to route signaling messages
through<br>
a series of &quot;control channels&quot;. </font></blockquote><br>
No, it's the applications (e.g., LMP) that have a view of the control
channels; the network does not know about them or does not use them in
routing. <br>
<br>
<blockquote type=cite cite><font size=3>This makes it a real network
layer in my<br>
mind, with associated routing protocol etc.<br>
<br>
<br>
&gt; &gt; So in other words, the proposal is to create an extra
&quot;network layer&quot;<br>
&gt; &gt; (OSI terminology) consisting of &quot;signalling
channels&quot;. These &quot;signalling<br>
&gt; &gt; channels&quot; make use of underlying &quot;control
channels&quot; which again can make<br>
&gt; &gt; use of any generic network layer (e.g. DCN). Correct ?<br>
&gt; <br>
&gt; No, I don't think so. Just because we've a peer to peer protocol
for<br>
&gt; detecting health of the control channels, IMO, does not mean that
we've<br>
&gt; introduced an extra &quot;network layer&quot;. Control network is
still managed<br>
&gt; like any other (IP) network.<br>
<br>
As mentioned above: I assumed that a &quot;control network&quot; is built
from &quot;control<br>
channels&quot;.</font></blockquote><br>
No, please see comments above. <br>
<br>
<br>
<blockquote type=cite cite><font size=3>If this assumption is correct: I
think we are building a &quot;control network&quot; (L3)<br>
on top of &quot;control channels&quot; (L2). &quot;Control channels&quot;
(L2) make use of any<br>
generic network layer (L3, e.g. DCN).<br>
<br>
If this assumption is wrong: I can now only deduce that &quot;control
channels&quot;<br>
are a kind if &quot;ping&quot; mechanism to detect point-to-point
aliveness of the<br>
&quot;control network&quot;.</font></blockquote><br>
I would like to refer to <font size=3>Jonathan's reply to this. <br>
<br>
<br>
<blockquote type=cite cite>Please consider the following very simple
topology:<br>
<br>
&nbsp;&nbsp;&nbsp;
+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----+<br>
&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | ...................
|&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp; |&nbsp; A&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; B&nbsp; |<br>
&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;
+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
. /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
. /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
. /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
. /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\ .&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; . /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\ . +-----+ . /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\ .|&nbsp;&nbsp;&nbsp;&nbsp; |. /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\ |&nbsp; C&nbsp; | /<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----+<br>
<br>
....: DCN topology (e.g. using a LAN connection between A&amp;B)<br>
----: transmission topology (the &quot;dataLink&quot;s)<br>
<br>
In case the fibre A-C (with associated DCC channel) breaks, the DCN<br>
network can still find a path between A and C: A-B-C. Correct ?<br>
So in case of such a fibre failure, you would say that the (routed)<br>
&quot;control channel&quot; is still alive. Correct ?<br>
<br>
If &quot;control channels&quot; are nothing more than the standard
&quot;ping&quot; mechanism,<br>
why not use this standard &quot;ping&quot; mechanism
?</font></blockquote><br>
Again, I would like to refer to <font size=3>Jonathan's reply. <br>
<br>
<blockquote type=cite cite>If &quot;control channels&quot; does provide
more than standard &quot;ping&quot;, could you<br>
please let me know what that would be (and why that would be
mandatorily<br>
needed) ?<br>
<br>
I think I first need clarity on the relation between &quot;control
network&quot; and<br>
&quot;control channel&quot; before being able to comment on your other
points.<br>
<br>
<br>
Thanks !<br>
<br>
Michiel<br>
&lt;snip&gt;<br>
&lt;...snip...&gt;</blockquote>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]<br>
</font></html>

--=====================_28241288==_.ALT--

Delivery-date: Tue, 30 Apr 2002 13:25:23 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: {SUKLM} Changes in new draft
Date: Tue, 30 Apr 2002 11:29:26 -0700

[ post by non-subscriber ]

Hi All,
        In the newly released draft draft-ietf-ccamp-gmpls-sonet-sdh-04.txt, 
the interpretation of S field in the {SUKLM} structure looks to be different 
than was present in earlier draft draft-ietf-ccamp-gmpls-sonet-sdh-03.txt.

The definition in 04 version is :

1. S=1->N is the index of a particular AUG-1/STS-3 inside an
     STM-N/STS-N multiplex. S is only significant for SDH STM-N (N>0)
     and SONET STS-N (N>1) and must be 0 and ignored for STM-0 and
     STS-1.

The definition in 03 version is :

1. S is only significant for SDH STM-N (N>0) and SONET. It must
     be ignored for STM-0. S is the index of a particular AUG-1/STS-
     1. S=1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N
     multiplex. For example, S=1 indicates the first AUG-1/STS-1, and
     S=N indicates the last AUG-1/STS-1 of this multiplex.

With the old version of the document, if I need to represent say Xth (X<=N) 
VC-4 in STM-N multiplex then the label value is {X, 1, 0, 0}. What will be 
this representation as per 04-version ?

Can someone please explain that what was the reason for this change ? What 
will be the advantage of this approach ?

Regards,
manoj.

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

Delivery-date: Tue, 30 Apr 2002 10:33:23 -0700
Date: Tue, 30 Apr 2002 10:27:52 -0700
To: Zhi-Wei Lin <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: Re: Fwd: Re: SE style in optical neyworks
Cc: [email-masked]

Hi Zhi,

Please see my comments in-line.

Here is an example:

>>>          1+1                        1+1
>>>A ----------------B --------- C ------------D
>>>                      \          /
>>>                        \       /
>>>                           E
>>>
>>>
>>>A - B & C - D 1+1 line protected
>>>B - C, C - E, B - E are all unprotected links.
>So this network you drew assumes a single point of interconnect at B and 
>C...that's fine

Yes.

>>>Say, one wants to create a protected LSP from A to D.
>>>then, you would create one primary LSP from A to D via
>>>A - B - C - D, and then you would create another LSP
>>>from A to D using SE style ( to indicate that this is an
>>>alternate path for same Tunnel ) via A - B - E - C - D.
>>>This way B - C is protected by B - E - C.
>By creating a new LSP A-B-E-C-D, this circuit is completely separate from 
>the original A-B-C-D circuit. There is no sharing at all. It is just 
>incidental that they carry the same traffic (i.e., you just happen to have 
>set up the A-B-E-C-D to carry the same traffic as in A-B-C-D). Again this 
>is not merging (as represented by SE), unless you are re-defining what SE 
>means...

As others pointed out, SE may not be a right terminology to be used for 
this. There is a merging happening at node B since
B uses line APS to find out active link and selects and bridges traffic to 
E and C. Certainly it is not like packet merging, but
the traffic terminates at B from both lines and only one link traffic is 
sent out to E and C. So I am not sure
what do call this? But looks like SE may not be a right term. As you all 
know that, on 1+1 line you make only one
reservation for a LSP, even if LSP is protected. So if one wants to create 
a protected LSP, only the first LSP
makes reservation on 1+1 link and second LSP does not make any additional 
reservation.

>>>B - C - E is not configured as a UPSR. All unprotected links.
>>>Virtual UPSR can be created such a way that B has a bridge
>>>and C has a selector. Ofcourse, for bidirectional LSP, you need
>>>the same thing in the opposite direction too.
>Yes, just as the two LSPs making up the 1+1 from A-B are both unprotected 
>LSPs, but taken together provide the 1+1 service.

Nope. Both LSPs are protected on A-B link. Even if you do not create second 
LSP, the first is protected by default on
A-B due to 1+1 line APS.

>  As such, if B-E-C is carrying the same traffic as B-C *all the time*, 
> then it's still 1+1, but more specifically, it is a 1+1 SNC (sub-network 
> connection). 1+1 doesn't necessary only apply to 1+1 path (when you say 
> path, I think you mean trail? -- G.805 terminology).
>
>However, if B-E-C is not carrying the same traffic, but may be used to 
>support *extra traffic*, then this is a 1:1 type protection.
>
>And if B-E-C LSP is actually supporting multiple LSPs going over B-C, then 
>it's 1:N protection. However, note that even in this case it is still NOT 
>SE, since the B-E-C LSP at any given time is only ever carrying one single 
>traffic.

I agree with this..

Thanks,
Suresh

>Hope this clarifies.
>
>Zhi
>
>>>
>>>Now, what do you call this kind of protection? Protected LSP?
>>>But not 1+1 path protected  - since it is not end-to-end path
>>>protected.
>>>
>>>To clarify again, this is when you would use SE style.
>>>
>>>Thanks
>>>Suresh
>>>
>>>
>>>At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote:
>>>
>>>
>>>>>This can be used to set up Protected circuits which may contain
>>>>>1+1 lines and 1+1 path protected segments. So on 1+1 line
>>>>>protected segments, you Share the bandwidth among primary
>>>>>and alternate paths.
>>>>
>>>>
>>>>         You do not share the bandwidth across 1+1 circuits. You
>>>>double-book the bandwidth because the same packets are
>>>>sent twice: once over each LSP.  You only share bandwidth
>>>>with 1:N.
>>>>
>>>>         --Tom
>>>>
>>>>
>>>>>Setting up protected circuits is not considered
>>>>>in detail so far. Hopefully, P&R design team will consider this..
>>>>>
>>>>>Thanks,
>>>>>Suresh
>>>>>
>>>>>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>How does SE style of RSVP signalling fits in the optical nature of 
>>>>>>network
>>>>>>i.e. in wavelength, TDM switching etc.
>>>>>>
>>>>>>  In other words, How two lsp can share resource in optical networks??
>>>>>>
>>>>>>Regards,
>>>>>>Khuzema.
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>Mathematics is the supreme nostalgia of our time.
>>
>

Delivery-date: Mon, 29 Apr 2002 13:10:56 -0700
From: Jonathan Lang <[email-masked]>
To: 'Michiel van Everdingen' <[email-masked]>, Zafar Ali <[email-masked]>
Cc: [email-masked]
Subject: RE: Question on LMP.
Date: Mon, 29 Apr 2002 13:02:26 -0700

Michiel,

<snip>
> 
> If "control channels" are nothing more than the standard "ping" mechanism,
> why not use this standard "ping" mechanism ?
> If "control channels" does provide more than standard "ping", could you
> please let me know what that would be (and why that would be mandatorily
> needed) ?
standard "ping" only tells you reachability. It does not tell you if the LMP
component is functioning or not. This is similar to why Hellos are used in
other protocols (e.g., RSVP Hello).

Thanks,
Jonathan

> 
> I think I first need clarity on the relation between "control 
> network" and
> "control channel" before being able to comment on your other points.
> 
> 
> Thanks !
> 
> Michiel
> 
> 
> 
> 
> Zafar Ali wrote:
> > 
> > Hi Michiel,
> > 
> > Thanks for the summary; please see comments in-lined.
> > 
> > Thanks
> > 
> > Regards... Zafar
> > 
> > At 12:10 PM 4/26/2002 +0200, Michiel van Everdingen wrote:
> > 
> > > Hello Zafar,
> > >
> > > Please allow me to summarize my understanding of our 
> discussion thus
> > > far.
> > >
> > > LMP's "control channel management"
> > >
> > > - Is an extra, new protocol on top of an existing IP network.
> > 
> > Agreed!
> > 
> > >   That is what I understand when Jonathan writes "You 
> could certainly
> > >   create an LMP control channel through a DCN network. In 
> fact, this
> > >   is probably the preferred configuration."
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
> > >
> > > - Needs careful setting of hello frequency.
> > >   This is based on your comment: "LMP Hellos should be 
> faster than RSVP
> > >   Hellos or the mechanism used to detect signalling 
> channel failure.
> > >   Similarly, LMP Hello frequency should be greater than 
> IGP hello frequency,
> > >   so that the optical network can make "conscious" 
> decision on the control
> > >   channel failure, before having an adverse affect on the 
> IGP adjacencies at L3."
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html
> > 
> > Agreed!
> > 
> > > - Provide a fast recovering transport mechanism for 
> "signalling channels"
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html
> > 
> > I would like to reword this as, LMP provides a mean for 
> detecting control channel failures between LMP neighbors. 
> These control channels are used by
> > signaling and other control entities.
> > 
> > > Furthermore, there is a need to route packets through a 
> network consisting
> > > of "signalling channels":
> > 
> > I would it to be simply referred as the control network, 
> instead of network consisting of "signaling channels".
> > 
> > > the RSVP-TE "notify message" is sent between
> > > non-adjacent (at transmission plane) nodes in case it is 
> "encapsulated
> > > in a new IP header whose destination is equal to the 
> target IP address."
> > > [RSVP-TE, section 4.3]
> > 
> > The notify message with the above mentioned option is also 
> sent over the control network, like other signaling messages. 
>  I did not see the
> > relationship here. Can you please elaborate a bit further 
> why you are mentioning this here?
> > 
> > > So in other words, the proposal is to create an extra 
> "network layer"
> > > (OSI terminology) consisting of "signalling channels". 
> These "signalling
> > > channels" make use of underlying "control channels" which 
> again can make
> > > use of any generic network layer (e.g. DCN). Correct ?
> > 
> > No, I don't think so. Just because we've a peer to peer 
> protocol for detecting health of the control channels, IMO, 
> does not mean that we've
> > introduced an extra "network layer". Control network is 
> still managed like any other (IP) network.
> > 
> > > I agree with you that we need to carefully look at the 
> "hello" frequencies
> > > of these network layers. Probably some consideration is 
> also needed for
> > > hello-timers on datalink layer and hold-off timers at 
> transport layer.
> > 
> > I did not understand which hold off timers you're referring 
> to here?, and what is the relationship of some timers at the 
> "transport layer" with the
> > operation of control network?
> > 
> > > All together, my feeling is that this is getting quite complex.
> > >
> > > Are we sure we want to go in this direction ? Can't we 
> simply remove
> > > the whole "control channel management" mechanism and 
> define "control
> > > channel" as follows:
> > >   control channel = a facility that interconnects two 
> switching neighbours
> > >   at the transmission plane for the purpose of exchanging 
> control messages.
> > >   This facility can be in-band or out-of-band; 
> point-to-point or multi-point.
> > > If we would accept this definition, a DCN network (or 
> better: SCN network)
> > > can be an implementation to have control channels between 
> all neighbouring
> > > nodes at the transmission plane.
> > 
> > I am not is a position to comment on this. However, I would 
> like to reiterate a couple of points. First, I thought that 
> much of the LMP draft is
> > already agreed upon and is close to become an RFC, so I am 
> not sure the value of this discussion at this stage. 
> Secondly, I don't think there were
> > convincing enough arguments to go in that direction.
> > 
> > > If we have to go on discussing "control channel 
> management", I think we
> > > still have the following open questions:
> > > - why does control channel management need to be fast
> > 
> > No, I don't think that control channel management need to 
> be fast (O(mseconds)). I think this will be a comment to the 
> authors of the draft to
> > clarify this point in the draft and remove the related text from it.
> > 
> > > - is control channel management fast.
> > 
> > No, IMO, it only need to satisfy that requirements that I 
> pointed out earlier in,
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html
> > 
> > > On your email:
> > >
> > > > I don't see if we can cover all cases of control 
> channel failure detection
> > > > after removing this functionality from LMP (e.g., the 
> case of routed control
> > > > channels or control channels where L2 failure detection 
> is not feasible).
> > >
> > > Hopefully someone on this mailing list can show us a case 
> in which a standard
> > > IP network is not sufficient for the control plane...
> > >
> > >
> > > > LMP will be using UDP, as indicated in an earlier email 
> from Jonathan.
> > >
> > > Sorry, I was not aware of this. I just joined the list 3 
> weeks ago to ask if
> > > we could add neighbour discovery in LMP and to get 
> clarity on the use of
> > > "control channel management". Guess I was somewhat naive 
> to think that that
> > > could easily be settled....
> > >
> > >
> > > > > Indeed. In some cases L2 detects the failure, in 
> other cases L3 detects
> > > > > the failure. Still confused as to why we can't stick 
> to standard L3
> > > > > mechanisms to detect the failure...
> > > >
> > > > Can you please elaborate on what "other" L3 mechanisms 
> you're referring to
> > > > here? How would you cover the case of an IP routed 
> control channel?
> > >
> > > I did not speak about "other" L3 mechanisms. Just 
> standard L3 mechanisms.
> > 
> > Such mechanism runs on physical links in the control 
> network. However, when we've a routed control channel, these 
> mechanisms do not help us.
> > 
> > > > I think the WG has already agreed upon the control 
> channel management
> > > > procedure within the scope of LMP. I am not sure what 
> is the value of
> > > > this discussion at this point. I'll let some one else 
> comment on it.
> > >
> > > Personally, I found our discussion very useful. Thanks 
> for the to-the-point
> > > answers !
> > 
> > Likewise, it has been a pleasure exchanging ideas with you :-)
> > 
> > Thanks...
> > 
> > Regards.... Zafar
> > 
> > > Best regards,
> > >
> > > Michiel
> > >
> 
> <...snip...>
> 

Delivery-date: Mon, 29 Apr 2002 12:20:00 -0700
From: "Don Fedyk"<[email-masked]>
To: Zafar Ali <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: TE metric and graceful restart
Date: Mon, 29 Apr 2002 15:17:45 -0400

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

------_=_NextPart_001_01C1EFB2.8A7BC48E
Content-Type: text/plain;
	charset="iso-8859-1"

Kireeti, Zafer:

I think that Zafer picked up on my earlier point that just because routing
is gracefully restarting an implementation may have an independent 
LSP system that can function just fine so why be forced to penalize 
it? On the other hand, you may have an LSP system that is linked 
to routing such it must restart as well and then I would agree that 
zeroing bandwidth may well be necessary( but somewhat less "graceful").
I'm not convinced changing Metrics is required at all. 

So I would agree with Zafer the wording should be such that either 
case is allowed,

Don  
-----Original Message-----
>From: Zafar Ali [mailto:[email-masked]]
>Sent: Sunday, April 28, 2002 1:53 AM
>To: Kireeti Kompella
>Cc: [email-masked]
>Subject: RE: TE metric and graceful restart
>
>
>Dear Kireeti, 
>
>Thanks for the reply; Please see comments in-lined. 
>
>At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:
>
>
>On Sat, 27 Apr 2002, Zafar Ali wrote:
>
>> The reason that I understood this as a MAY case is that a node that saves
>> bandwidth usage state information locally is able to determine (or
>> estimate) the amount of unreserved resources immediately upon start-up.
In
>> which case it MAY advertise the saved (projected) value(s) during the
>> graceful restart period.
>
>Attractive as that may be, life is not so simple.  The process of
>recovery for signaling is complex enough without having new LSPs set
>up during recovery.  The idea of discouraging LSPs during recovery is
>not just that the recovering node doesn't know its unreserved bandwidth,
>but that it wants to complete recovery before setting up new LSPs.
>
>A simple example is that the recovering node X uses per-box labels,
>gets a new LSP request while recovering, and allocates label L to that
>request.  But L is already in use for an existing LSP ....  
>One can
>work around this particular example, but keeping it simple seems like
>a good initial goal.
>
>Agreed! As I also mentioned that in doing so the node looses the charm 
>of discouraging other nodes in the network 
>in using it, during the restart period. This opens doors for some 
>potential race conditions and >scenarios like the one you mentioned 
>in the email. Of course, a node that may choose to do so >has to deal 
>with kind of scenarios that you mentioned in the email. I see that 
>there are some tradeoffs involved and the standard should leave a 
>room for exercising such options. Hence, IMO this should be a local 
>(vendor specific) decision. 
>
>In short, while I am agreeing with the recommendation, I think the 
>"SHOULD" part should be >>removed and the standard should leave it as 
>part of the local decision. 
>
>Thanks
>
>Regards... Zafar 
>
>>
>>
>>At least, that's my take.
>>
>>Kireeti.

------_=_NextPart_001_01C1EFB2.8A7BC48E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: TE metric and graceful restart</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Kireeti, Zafer:</FONT>
</P>

<P><FONT SIZE=2>I think that Zafer picked up on my earlier point that just because routing</FONT>
<BR><FONT SIZE=2>is gracefully restarting an implementation may have an independent </FONT>
<BR><FONT SIZE=2>LSP system that can function just fine so why be forced to penalize </FONT>
<BR><FONT SIZE=2>it? On the other hand, you may have an LSP system that is linked </FONT>
<BR><FONT SIZE=2>to routing such it must restart as well and then I would agree that </FONT>
<BR><FONT SIZE=2>zeroing bandwidth may well be necessary( but somewhat less &quot;graceful&quot;).</FONT>
<BR><FONT SIZE=2>I'm not convinced changing Metrics is required at all. </FONT>
</P>

<P><FONT SIZE=2>So I would agree with Zafer the wording should be such that either </FONT>
<BR><FONT SIZE=2>case is allowed,</FONT>
</P>

<P><FONT SIZE=2>Don&nbsp; </FONT>
<BR><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;From: Zafar Ali [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt;Sent: Sunday, April 28, 2002 1:53 AM</FONT>
<BR><FONT SIZE=2>&gt;To: Kireeti Kompella</FONT>
<BR><FONT SIZE=2>&gt;Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;Subject: RE: TE metric and graceful restart</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Dear Kireeti, </FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Thanks for the reply; Please see comments in-lined. </FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;On Sat, 27 Apr 2002, Zafar Ali wrote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt; The reason that I understood this as a MAY case is that a node that saves</FONT>
<BR><FONT SIZE=2>&gt;&gt; bandwidth usage state information locally is able to determine (or</FONT>
<BR><FONT SIZE=2>&gt;&gt; estimate) the amount of unreserved resources immediately upon start-up. In</FONT>
<BR><FONT SIZE=2>&gt;&gt; which case it MAY advertise the saved (projected) value(s) during the</FONT>
<BR><FONT SIZE=2>&gt;&gt; graceful restart period.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Attractive as that may be, life is not so simple.&nbsp; The process of</FONT>
<BR><FONT SIZE=2>&gt;recovery for signaling is complex enough without having new LSPs set</FONT>
<BR><FONT SIZE=2>&gt;up during recovery.&nbsp; The idea of discouraging LSPs during recovery is</FONT>
<BR><FONT SIZE=2>&gt;not just that the recovering node doesn't know its unreserved bandwidth,</FONT>
<BR><FONT SIZE=2>&gt;but that it wants to complete recovery before setting up new LSPs.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;A simple example is that the recovering node X uses per-box labels,</FONT>
<BR><FONT SIZE=2>&gt;gets a new LSP request while recovering, and allocates label L to that</FONT>
<BR><FONT SIZE=2>&gt;request.&nbsp; But L is already in use for an existing LSP ....&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;One can</FONT>
<BR><FONT SIZE=2>&gt;work around this particular example, but keeping it simple seems like</FONT>
<BR><FONT SIZE=2>&gt;a good initial goal.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Agreed! As I also mentioned that in doing so the node looses the charm </FONT>
<BR><FONT SIZE=2>&gt;of discouraging other nodes in the network </FONT>
<BR><FONT SIZE=2>&gt;in using it, during the restart period. This opens doors for some </FONT>
<BR><FONT SIZE=2>&gt;potential race conditions and &gt;scenarios like the one you mentioned </FONT>
<BR><FONT SIZE=2>&gt;in the email. Of course, a node that may choose to do so &gt;has to deal </FONT>
<BR><FONT SIZE=2>&gt;with kind of scenarios that you mentioned in the email. I see that </FONT>
<BR><FONT SIZE=2>&gt;there are some tradeoffs involved and the standard should leave a </FONT>
<BR><FONT SIZE=2>&gt;room for exercising such options. Hence, IMO this should be a local </FONT>
<BR><FONT SIZE=2>&gt;(vendor specific) decision. </FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In short, while I am agreeing with the recommendation, I think the </FONT>
<BR><FONT SIZE=2>&gt;&quot;SHOULD&quot; part should be &gt;&gt;removed and the standard should leave it as </FONT>
<BR><FONT SIZE=2>&gt;part of the local decision. </FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Thanks</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Regards... Zafar </FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;At least, that's my take.</FONT>
<BR><FONT SIZE=2>&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;&gt;Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EFB2.8A7BC48E--

Delivery-date: Mon, 29 Apr 2002 10:15:34 -0700
Date: Mon, 29 Apr 2002 13:13:03 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-signaling-08.txt

FYI
Changes from previous version:
  o Reorder author's list to indicate primary contact
  o Updated LSP Encoding and G-PIDs per the "SONET/SDH" and other compromises
  o Other minor cleanup

>To: IETF-Announce:;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-08.txt
>Date: Mon, 29 Apr 2002 07:53:12 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multiprotocol Label Switching Working 
>Group of the IETF.
>
>         Title           : Generalized MPLS - Signaling Functional Description
>         Author(s)       : L. Berger et al.
>         Filename        : draft-ietf-mpls-generalized-signaling-08.txt
>         Pages           : 32
>         Date            : 26-Apr-02
>
>This document describes extensions to MPLS signaling required to
>support Generalized MPLS.  Generalized MPLS extends the MPLS control
>plane to encompass time-division (e.g. SONET/SDH ADMs), wavelength
>(optical lambdas) and spatial switching (e.g. incoming port or fiber
>to outgoing port or fiber).  This document presents a functional
>description of the extensions.  Protocol specific formats and
>mechanisms, and technology specific details are specified in separate
>documents.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-mpls-generalized-signaling-08.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-08.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt>

Delivery-date: Mon, 29 Apr 2002 10:15:29 -0700
Date: Mon, 29 Apr 2002 13:13:09 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-06.txt

FYI -
Changes from previous version:
  o Reorder author's list to indicate primary contact
  o Split references section
  o Fixed formatting of section 7.2.1
  o Minor editorial changes and clarifications

>To: IETF-Announce:;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-06.txt
>Date: Mon, 29 Apr 2002 07:53:17 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multiprotocol Label Switching Working 
>Group of the IETF.
>
>         Title           : Generalized MPLS Signaling - CR-LDP Extensions
>         Author(s)       : P. Ashwood-Smith, L. Berger et al.
>         Filename        : draft-ietf-mpls-generalized-cr-ldp-06.txt
>         Pages           : 23
>         Date            : 26-Apr-02
>
>This document describes extensions to CR-LDP signaling required to
>support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
>time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and
>spatial switching (e.g. incoming port or fiber to outgoing port or
>fiber).  This document presents a CR-LDP specific description of the
>extensions.  A generic functional description and an RSVP-TE specific
>description can be found in separate documents.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-mpls-generalized-cr-ldp-06.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt>

Delivery-date: Mon, 29 Apr 2002 10:15:23 -0700
Date: Mon, 29 Apr 2002 13:13:16 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-07.txt

FYI -

Changes from previous version:
  o Reorder author's list to indicate primary contact
  o Fixed indication of infinite restart time
  o Added IANA [Suggestions /] Assignments Section
  o Split references section
  o Minor editorial changes and clarifications

>To: IETF-Announce:;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-07.txt
>Date: Mon, 29 Apr 2002 07:53:22 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multiprotocol Label Switching Working 
>Group of the IETF.
>
>         Title           : Generalized MPLS Signaling - RSVP-TE Extensions
>         Author(s)       : L. Berger et al.
>         Filename        : draft-ietf-mpls-generalized-rsvp-te-07.txt
>         Pages           : 40
>         Date            : 26-Apr-02
>
>This document describes extensions to RSVP-TE signaling required to
>support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
>time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and
>spatial switching (e.g. incoming port or fiber to outgoing port or
>fiber).  This document presents an RSVP-TE specific description of
>the extensions.  A generic functional description and a CR-LDP
>specific description can be found in separate documents.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-mpls-generalized-rsvp-te-07.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt>

Delivery-date: Mon, 29 Apr 2002 08:59:29 -0700
Cc: [email-masked]
Date: Mon, 29 Apr 2002 17:57:29 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Question on LMP.

Hello Zafar,

> > the RSVP-TE "notify message" is sent between
> > non-adjacent (at transmission plane) nodes in case it is "encapsulated
> > in a new IP header whose destination is equal to the target IP address."
> > [RSVP-TE, section 4.3]
> 
> The notify message with the above mentioned option is also sent over the
> control network, like other signaling messages.  I did not see the
> relationship here. Can you please elaborate a bit further why you are
> mentioning this here?

You talk here about "control network". I tried to focus on the "network"
part in that "control network".

>From a.o. the following sentences of the LMP draft, I deduce that
"control channels" are only present between two nodes that are neighbors
at the transmission plane:
"This draft specifies a link management protocol (LMP) that runs between
 neighboring nodes and is used to manage TE links."
"In GMPLS, the control channels between two adjacent nodes ..."

However, it seems that not all signaling messages are between adjacent
nodes (adjacent at the transmission plane). I used the "notify message"
as an example: "The Notify message provides a mechanism to inform non-
adjacent nodes of LSP related events" [RSVP-TE, section 4.3].

So, assuming a "control network" is built from "control channels", this
"control network" needs to be able to route signaling messages through
a series of "control channels". This makes it a real network layer in my
mind, with associated routing protocol etc.

> > So in other words, the proposal is to create an extra "network layer"
> > (OSI terminology) consisting of "signalling channels". These "signalling
> > channels" make use of underlying "control channels" which again can make
> > use of any generic network layer (e.g. DCN). Correct ?
> 
> No, I don't think so. Just because we've a peer to peer protocol for
> detecting health of the control channels, IMO, does not mean that we've
> introduced an extra "network layer". Control network is still managed
> like any other (IP) network.

As mentioned above: I assumed that a "control network" is built from "control
channels".

If this assumption is correct: I think we are building a "control network" (L3)
on top of "control channels" (L2). "Control channels" (L2) make use of any
generic network layer (L3, e.g. DCN).

If this assumption is wrong: I can now only deduce that "control channels"
are a kind if "ping" mechanism to detect point-to-point aliveness of the
"control network".

Please consider the following very simple topology:

    +-----+                     +-----+
    |     | ................... |     |
    |  A  |                     |  B  |
    |     |                     |     |
    +-----+                     +-----+
         \ .                   . /
          \ .                 . /
           \ .               . /
            \ .             . /
             \ .           . /
              \ . +-----+ . /
               \ .|     |. /
                \ |  C  | /
                  |     |
                  +-----+

....: DCN topology (e.g. using a LAN connection between A&B)
----: transmission topology (the "dataLink"s)

In case the fibre A-C (with associated DCC channel) breaks, the DCN
network can still find a path between A and C: A-B-C. Correct ?
So in case of such a fibre failure, you would say that the (routed)
"control channel" is still alive. Correct ?

If "control channels" are nothing more than the standard "ping" mechanism,
why not use this standard "ping" mechanism ?
If "control channels" does provide more than standard "ping", could you
please let me know what that would be (and why that would be mandatorily
needed) ?

I think I first need clarity on the relation between "control network" and
"control channel" before being able to comment on your other points.

Thanks !

Michiel

Zafar Ali wrote:
> 
> Hi Michiel,
> 
> Thanks for the summary; please see comments in-lined.
> 
> Thanks
> 
> Regards... Zafar
> 
> At 12:10 PM 4/26/2002 +0200, Michiel van Everdingen wrote:
> 
> > Hello Zafar,
> >
> > Please allow me to summarize my understanding of our discussion thus
> > far.
> >
> > LMP's "control channel management"
> >
> > - Is an extra, new protocol on top of an existing IP network.
> 
> Agreed!
> 
> >   That is what I understand when Jonathan writes "You could certainly
> >   create an LMP control channel through a DCN network. In fact, this
> >   is probably the preferred configuration."
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
> >
> > - Needs careful setting of hello frequency.
> >   This is based on your comment: "LMP Hellos should be faster than RSVP
> >   Hellos or the mechanism used to detect signalling channel failure.
> >   Similarly, LMP Hello frequency should be greater than IGP hello frequency,
> >   so that the optical network can make "conscious" decision on the control
> >   channel failure, before having an adverse affect on the IGP adjacencies at L3."
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html
> 
> Agreed!
> 
> > - Provide a fast recovering transport mechanism for "signalling channels"
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html
> 
> I would like to reword this as, LMP provides a mean for detecting control channel failures between LMP neighbors. These control channels are used by
> signaling and other control entities.
> 
> > Furthermore, there is a need to route packets through a network consisting
> > of "signalling channels":
> 
> I would it to be simply referred as the control network, instead of network consisting of "signaling channels".
> 
> > the RSVP-TE "notify message" is sent between
> > non-adjacent (at transmission plane) nodes in case it is "encapsulated
> > in a new IP header whose destination is equal to the target IP address."
> > [RSVP-TE, section 4.3]
> 
> The notify message with the above mentioned option is also sent over the control network, like other signaling messages.  I did not see the
> relationship here. Can you please elaborate a bit further why you are mentioning this here?
> 
> > So in other words, the proposal is to create an extra "network layer"
> > (OSI terminology) consisting of "signalling channels". These "signalling
> > channels" make use of underlying "control channels" which again can make
> > use of any generic network layer (e.g. DCN). Correct ?
> 
> No, I don't think so. Just because we've a peer to peer protocol for detecting health of the control channels, IMO, does not mean that we've
> introduced an extra "network layer". Control network is still managed like any other (IP) network.
> 
> > I agree with you that we need to carefully look at the "hello" frequencies
> > of these network layers. Probably some consideration is also needed for
> > hello-timers on datalink layer and hold-off timers at transport layer.
> 
> I did not understand which hold off timers you're referring to here?, and what is the relationship of some timers at the "transport layer" with the
> operation of control network?
> 
> > All together, my feeling is that this is getting quite complex.
> >
> > Are we sure we want to go in this direction ? Can't we simply remove
> > the whole "control channel management" mechanism and define "control
> > channel" as follows:
> >   control channel = a facility that interconnects two switching neighbours
> >   at the transmission plane for the purpose of exchanging control messages.
> >   This facility can be in-band or out-of-band; point-to-point or multi-point.
> > If we would accept this definition, a DCN network (or better: SCN network)
> > can be an implementation to have control channels between all neighbouring
> > nodes at the transmission plane.
> 
> I am not is a position to comment on this. However, I would like to reiterate a couple of points. First, I thought that much of the LMP draft is
> already agreed upon and is close to become an RFC, so I am not sure the value of this discussion at this stage. Secondly, I don't think there were
> convincing enough arguments to go in that direction.
> 
> > If we have to go on discussing "control channel management", I think we
> > still have the following open questions:
> > - why does control channel management need to be fast
> 
> No, I don't think that control channel management need to be fast (O(mseconds)). I think this will be a comment to the authors of the draft to
> clarify this point in the draft and remove the related text from it.
> 
> > - is control channel management fast.
> 
> No, IMO, it only need to satisfy that requirements that I pointed out earlier in,
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html
> 
> > On your email:
> >
> > > I don't see if we can cover all cases of control channel failure detection
> > > after removing this functionality from LMP (e.g., the case of routed control
> > > channels or control channels where L2 failure detection is not feasible).
> >
> > Hopefully someone on this mailing list can show us a case in which a standard
> > IP network is not sufficient for the control plane...
> >
> >
> > > LMP will be using UDP, as indicated in an earlier email from Jonathan.
> >
> > Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask if
> > we could add neighbour discovery in LMP and to get clarity on the use of
> > "control channel management". Guess I was somewhat naive to think that that
> > could easily be settled....
> >
> >
> > > > Indeed. In some cases L2 detects the failure, in other cases L3 detects
> > > > the failure. Still confused as to why we can't stick to standard L3
> > > > mechanisms to detect the failure...
> > >
> > > Can you please elaborate on what "other" L3 mechanisms you're referring to
> > > here? How would you cover the case of an IP routed control channel?
> >
> > I did not speak about "other" L3 mechanisms. Just standard L3 mechanisms.
> 
> Such mechanism runs on physical links in the control network. However, when we've a routed control channel, these mechanisms do not help us.
> 
> > > I think the WG has already agreed upon the control channel management
> > > procedure within the scope of LMP. I am not sure what is the value of
> > > this discussion at this point. I'll let some one else comment on it.
> >
> > Personally, I found our discussion very useful. Thanks for the to-the-point
> > answers !
> 
> Likewise, it has been a pleasure exchanging ideas with you :-)
> 
> Thanks...
> 
> Regards.... Zafar
> 
> > Best regards,
> >
> > Michiel
> >

<...snip...>

Delivery-date: Mon, 29 Apr 2002 06:29:31 -0700
content-class: urn:content-classes:message
Subject: RE: encoding link id for unnumbered interfaces 
Date: Mon, 29 Apr 2002 09:27:03 -0400
From: "Dovolsky, Dan" <[email-masked]>
To: <[email-masked]>

BSD.

Question:

Original definition of Local/Remote Interface IP Address sub-TLV, =
specified in draft-katz-yeung-ospf-traffic-02.txt, has divided into it's =
redefinition in draft-katz-yeung-ospf-traffic-06.txt for numbered i/f =
plus new Link Local/Remote Identifier sub-TLV in =
draft-ietf-ccamp-ospf-gmpls-extensions for unnumbered i/f.
Original 02 version covered both numbered and unnumbered cases.

If I understand it right, it was caused by not proper definition of =
unnumbered case in 02 version. In this case, why just not to fix this =
definition in 02?

Now, with katz-yeung and ccamp-ospf, implementation has to find link =
identifier in different sub-TLV, depended what type of interface =
(numbered/unnumbered) it processed.

Proposal:

Instead, we could have just one pair of Local/Remote Link Identifier =
sub-TLVs. For numbered i/f it will be Local/Remote IP Address and for =
unnumbered i/f it will be Local/Remote Link identifier 32 bits length as =
well. Sub-TLV type code the same as for Interface IP Address sub-TLV =
type.

Dan Dovolsky.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Friday, April 26, 2002 4:46 PM
To: Naidu, Venkata
Cc: [email-masked]
Subject: Re: encoding link id for unnumbered interfaces=20

> Yakov,
>=20
> -> I'd like to suggest that we replace Link Local Identifier sub-TLV
> -> and Link Remote Identifier sub-TLV (in both ISIS and OSPF) with a
> -> single sub-TLV that would contain both Link Local Identifier and =
Link=20
> -> Remote Identifier.
>=20
> -> Any objections ?
>=20
>   I prefer : different sub-TLVs. That gives consistency and
>              easy modification in future.
>=20
>   I suggest: Rather make Remote Identifier *mandatory* when
>              Local Identifier is present. This is definitely
>              bad but little better than your suggestion. :-)
>=20
>   I like   : Make both Local and Remote Identifiers are optional
>              (just like local and remote IP address TLVs in TE)
>              and leave the decision to individual vendors=20
>              (local decision).=20
>=20
>   Is there any scenario where this causes interop issues?!?!
>   Is that you are worried about *Tag, Length* extra memory
>   consumption?

No, it is just that if you have both local and remote identifiers
in the same sub-TLV, you don't have to worry about such error
cases as the situation where you have remote identifier sub-TLV
present, but the local identifier sub-TLV missing.

Yakov.

P.S. In contrast with numbered interfaces that allow for both
p2p and multiaccess interfaces, unnumbered interfaces are
restricted to p2p only.

Delivery-date: Mon, 29 Apr 2002 02:21:35 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: "Fedyk Don [BL60:1A00:EXCH]" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Suggested label and Label Set tlv doubts
Date: Mon, 29 Apr 2002 14:37:13 +1000
Organization: wipro technologies

This is a multi-part message in MIME format.

------=_NextPartTM-000-58c5dc32-5b4f-11d6-af80-0080c8048dde
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0238_01C1EF8B.5A474F80"

------=_NextPart_000_0238_01C1EF8B.5A474F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hello Don,

                For every mail that leaves out of my inbox, my employer =
attaches the disclaimer as a part of
                organization security policy. I can't do anything abt it =
and i guess it also doesn't have anything to
                do to make my queries invalid on a public list either =
and should not be a problem to discuss queries
                and make things clear ..After all we are here to share =
veiws and ideas and come out with better solutions.
               =20
                Don't really understand why this should become an issue =
at all. Neway, if the disclaimer hurts any individual,
                please excuse me ...n sorry abt it ...other wise i don't =
see any reason why one should not answer the queiries =20
               =20
                Please find my questions in the mail attached ..

thanks and regards
venkat
               =20
            =20

           =20
  ----- Original Message -----=20
  From: Fedyk, Don [BL60:1A00:EXCH]=20
  To: venkat=20
  Sent: Saturday, April 27, 2002 1:34 AM
  Subject: RE: Suggested label and Label Set tlv doubts

  Venkat

  Your disclaimer makes your message invalid on a public list. You might =
want to rephrase your question as an individual.

  Don
    -----Original Message-----
    From: Venkat Dabbara [mailto:[email-masked]]
    Sent: Friday, April 26, 2002 6:03 AM
    To: [email-masked]
    Subject: Suggested label and Label Set tlv doubts

    hai ,

                Since the suggested label and label set tlvs are =
optional in a Generalized label request, how do i handle
                a situation when someone has sent a request with both =
the TLVs present ??
       =20
                Do label set tlv has higher priority over suggested =
label in which case i can go ahead ignoring the=20
                suggested label and try to satisfy the request with =
label set as constraint on label or do i need to=20
                satisfy the suggested label constraint since my upstream =
has sent me the suggested label with=20
                an assumption that it will be satisfied and moreover =
since it would have created a crossconnect also.
                And ignore the label set tlv.

                I understand that this is a scenario where upstream is =
malfunctioning but that needs to be handled for sure and
                cannot be ignored

                Please do clarify things ...

    thanks=20
    venkat

------=_NextPart_000_0238_01C1EF8B.5A474F80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DISO-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hello Don,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; For every mail that leaves out of =
my=20
inbox, my employer attaches the disclaimer as a part of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; organization security policy. I =
can't do=20
anything abt it and i guess it also doesn't have anything =
to</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; do to make my queries invalid on a =
public=20
list either and should not be a problem to discuss queries</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; and make things clear ..After all =
we are=20
here to share veiws and ideas and come out with better =
solutions.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Don't really understand why this =
should=20
become an issue at all. Neway, if the disclaimer hurts any=20
individual,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; please excuse me ...n sorry abt it =

...other wise i don't see any reason why one should not answer the=20
queiries&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Please find my questions in the =
mail=20
attached ..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks and regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>venkat</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Fedyk, Don =
[BL60:1A00:EXCH]</A>=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">venkat</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, April 27, 2002 =
1:34=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Suggested label =
and Label=20
  Set tlv doubts</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=3D970013715-26042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Venkat</FONT></SPAN></DIV>
  <DIV><SPAN class=3D970013715-26042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D970013715-26042002><FONT face=3DArial =
color=3D#0000ff size=3D2>Your=20
  disclaimer makes your message invalid on a public list. You might want =
to=20
  rephrase your question as an individual.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D970013715-26042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D970013715-26042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Don</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Venkat Dabbara=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Friday, April 26, =
2002 6:03=20
    AM<BR><B>To:</B> <A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B>Subject:<=
/B>=20
    Suggested label and Label Set tlv doubts<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>hai ,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    Since the suggested label and label set tlvs are optional in a =
Generalized=20
    label request, how do i handle</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; a situation when someone has sent a request with =
both the=20
    TLVs present ??</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; Do label set tlv has higher priority over =
suggested label=20
    in which case i can go ahead ignoring the </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; suggested label and try to satisfy the request =
with label=20
    set as constraint on label or do i need to </FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;satisfy=20
    the suggested label constraint since my upstream has sent me the =
suggested=20
    label with </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; an assumption that it will be satisfied and =
moreover=20
    since it would have created a crossconnect also.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; And ignore the label set tlv.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; I understand that this is a scenario where =
upstream is=20
    malfunctioning but that needs to be handled for sure =
and</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    cannot be ignored</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp; Please do clarify things ...</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>thanks </FONT></DIV>
    <DIV><FONT face=3DArial=20
size=3D2>venkat</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0238_01C1EF8B.5A474F80--

------=_NextPartTM-000-58c5dc32-5b4f-11d6-af80-0080c8048dde
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-58c5dc32-5b4f-11d6-af80-0080c8048dde--

Delivery-date: Sat, 27 Apr 2002 23:00:06 -0700
Date: Sun, 28 Apr 2002 01:59:28 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: [email-masked]

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

Hi Michiel,

Thanks for the summary; please see comments in-lined.

Thanks

Regards... Zafar

At 12:10 PM 4/26/2002 +0200, Michiel van Everdingen wrote:
>Hello Zafar,
>
>Please allow me to summarize my understanding of our discussion thus
>far.
>
>LMP's "control channel management"
>
>- Is an extra, new protocol on top of an existing IP network.

Agreed!

>   That is what I understand when Jonathan writes "You could certainly
>   create an LMP control channel through a DCN network. In fact, this
>   is probably the preferred configuration."
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
>
>- Needs careful setting of hello frequency.
>   This is based on your comment: "LMP Hellos should be faster than RSVP
>   Hellos or the mechanism used to detect signalling channel failure.
>   Similarly, LMP Hello frequency should be greater than IGP hello frequency,
>   so that the optical network can make "conscious" decision on the control
>   channel failure, before having an adverse affect on the IGP adjacencies 
> at L3."
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html

Agreed!

>- Provide a fast recovering transport mechanism for "signalling channels"
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html

I would like to reword this as, LMP provides a mean for detecting control 
channel failures between LMP neighbors. These control channels are used by 
signaling and other control entities.

>Furthermore, there is a need to route packets through a network consisting
>of "signalling channels":

I would it to be simply referred as the control network, instead of network 
consisting of "signaling channels".

>the RSVP-TE "notify message" is sent between
>non-adjacent (at transmission plane) nodes in case it is "encapsulated
>in a new IP header whose destination is equal to the target IP address."
>[RSVP-TE, section 4.3]

The notify message with the above mentioned option is also sent over the 
control network, like other signaling messages.  I did not see the 
relationship here. Can you please elaborate a bit further why you are 
mentioning this here?

>So in other words, the proposal is to create an extra "network layer"
>(OSI terminology) consisting of "signalling channels". These "signalling
>channels" make use of underlying "control channels" which again can make
>use of any generic network layer (e.g. DCN). Correct ?

No, I don't think so. Just because we've a peer to peer protocol for 
detecting health of the control channels, IMO, does not mean that we've 
introduced an extra "network layer". Control network is still managed like 
any other (IP) network.

>I agree with you that we need to carefully look at the "hello" frequencies
>of these network layers. Probably some consideration is also needed for
>hello-timers on datalink layer and hold-off timers at transport layer.

I did not understand which hold off timers you're referring to here?, and 
what is the relationship of some timers at the "transport layer" with the 
operation of control network?

>All together, my feeling is that this is getting quite complex.
>
>Are we sure we want to go in this direction ? Can't we simply remove
>the whole "control channel management" mechanism and define "control
>channel" as follows:
>   control channel = a facility that interconnects two switching neighbours
>   at the transmission plane for the purpose of exchanging control messages.
>   This facility can be in-band or out-of-band; point-to-point or multi-point.
>If we would accept this definition, a DCN network (or better: SCN network)
>can be an implementation to have control channels between all neighbouring
>nodes at the transmission plane.

I am not is a position to comment on this. However, I would like to 
reiterate a couple of points. First, I thought that much of the LMP draft 
is already agreed upon and is close to become an RFC, so I am not sure the 
value of this discussion at this stage. Secondly, I don't think there were 
convincing enough arguments to go in that direction.

>If we have to go on discussing "control channel management", I think we
>still have the following open questions:
>- why does control channel management need to be fast

No, I don't think that control channel management need to be fast 
(O(mseconds)). I think this will be a comment to the authors of the draft 
to clarify this point in the draft and remove the related text from it.

>- is control channel management fast.

No, IMO, it only need to satisfy that requirements that I pointed out 
earlier in,
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html

>On your email:
>
> > I don't see if we can cover all cases of control channel failure detection
> > after removing this functionality from LMP (e.g., the case of routed 
> control
> > channels or control channels where L2 failure detection is not feasible).
>
>Hopefully someone on this mailing list can show us a case in which a standard
>IP network is not sufficient for the control plane...
>
>
> > LMP will be using UDP, as indicated in an earlier email from Jonathan.
>
>Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask if
>we could add neighbour discovery in LMP and to get clarity on the use of
>"control channel management". Guess I was somewhat naive to think that that
>could easily be settled....
>
>
> > > Indeed. In some cases L2 detects the failure, in other cases L3 detects
> > > the failure. Still confused as to why we can't stick to standard L3
> > > mechanisms to detect the failure...
> >
> > Can you please elaborate on what "other" L3 mechanisms you're referring to
> > here? How would you cover the case of an IP routed control channel?
>
>I did not speak about "other" L3 mechanisms. Just standard L3 mechanisms.

Such mechanism runs on physical links in the control network. However, when 
we've a routed control channel, these mechanisms do not help us.

> > I think the WG has already agreed upon the control channel management
> > procedure within the scope of LMP. I am not sure what is the value of
> > this discussion at this point. I'll let some one else comment on it.
>
>Personally, I found our discussion very useful. Thanks for the to-the-point
>answers !

Likewise, it has been a pleasure exchanging ideas with you :-)

Thanks...

Regards.... Zafar

>Best regards,
>
>Michiel
>
>
>Zafar Ali wrote:
> >
> > Hi Michiel:
> >
> > Please see comments in-lined.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:
> >
> > > Hello Zafar,
> > >
> > >
> > > > > I'm still confused as to why standard network layer mechanisms 
> would not
> > > > > be sufficient.
> > > >
> > > > I think this answer depends on how we define sufficient;-)
> > >
> > > As control channel management is a mandatory part of LMP, I would define
> > > "sufficient" as "minimally needed to run LMP" or maybe "minimally needed
> > > to run GMPLS".
> >
> > I don't see if we can cover all cases of control channel failure 
> detection after removing this functionality from LMP (e.g., the case of 
> routed control channels or control channels where L2 failure detection is 
> not feasible). Please note that control channel failure detection is 
> currently a
> > requirement for the GMPLS framework, which is already agreed upon, AFAIK.
> >
> > > > LMP control channel management brings some features into picture, e.g.,
> > > > when we've hidden control channels, how can we guarantee that the 
> neighbor
> > > > is listening to the channel we're sending your control messages to? 
> With
> > > > the configuration handshake, LMP guarantees that the two ends are ready
> > > > to exchange messages on the control channel in question.
> > >
> > > I guess control messages will use either TCP, UDP or IP. Correct ?
> >
> > LMP will be using UDP, as indicated in an earlier email from Jonathan.
> >
> > > In case of TCP, I'm assuming TCP's connection establishment phase takes
> > > care that the neighbour is listening.
> > >
> > > In case the control messages are sent using UDP or IP, I agree that the
> > > application has to make sure that the neighbour is listening. For the
> > > LMP control messages this seems no problem as they are acknowledged
> > > anyway by LMP (e.g. linkSummaryAck for the linkSummary message). The
> > > application can then simply resent the message until it receives a
> > > '(N)Ack'.
> >
> > Yes, also this is because LMP does not assume a reliable transport for 
> the control traffic (over the control channel).
> >
> > > > Similarly, it provides a way by which failure on a routed control
> > > > channel (control channel is not bound to a physical interface) or a
> > > > control channel where L2 cannot detect the failure.
> > >
> > > Indeed. In some cases L2 detects the failure, in other cases L3 detects
> > > the failure. Still confused as to why we can't stick to standard L3
> > > mechanisms to detect the failure...
> >
> > Can you please elaborate on what "other" L3 mechanisms you're referring 
> to here? How would you cover the case of an IP routed control channel?
> >
> > > > Without LMP control channel management, how you would suggest
> > > > management and health check for such control channels? Skipping
> > > > such tests will IMO lead to a more ad hoc procedures/ protocols.
> > >
> > > See above.
> > > For inter operability reasons, we could specify which mechanism has
> > > to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms
> > > (like MPLS protection, ML-PPP, ...) are then optional.
> > >
> > >
> > > > Signaling channel is a term I used to specify the following:
> > > > Signaling channel is the logical channel over which signaling
> > > > (say RSVP-TE) messages are exchanged between RSVP peering entities.
> > > > The signaling channel is realized using the collection of all
> > > > control channels between the two RSVP peers.
> > > > A signaling channel failure could be the result of the concurrent
> > > > failure of all control channels or the failure of one of the peering
> > > > signaling entities or one of the peering nodes. Hence, signaling
> > > > channel failure is different than failure of all control channels.
> > > >
> > > > Using the above mentioned definition, a nodal failure always imply
> > > > the failure of the signaling channel as well as control channels.
> > > > However, failure of the last control channel does not imply a nodal
> > > > failure. For the sake of completeness, a signaling channel failure
> > > > could be due to failure of the
> > > > peering RSVP process or due to the neighbor node failure. The
> > > > draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
> > > > failure to cover both cases: i.e., the case where peering RSVP
> > > > entity restarts or the entire node fails. In either case, non-stop
> > > > forwarding is assumed. In short, failure of
> > > > the last control channel is different from the nodal failures.
> > >
> > > Thanks for the definitions !
> > >
> > > Just to check: a signalling channel failure is different from a nodal
> > > failure. A nodal failure implies a signalling channel failure, but not
> > > the other way around. Correct ?
> >
> > Yes, failure of a peering signaling process also leads to signaling 
> channel failure.
> > But, the actions taken in the restart procedure are the same, for the 
> obvious reasons.
> >
> > > In these definitions, how would an RSVP-TE "notify message" be sent
> > > between non-adjacent (at transmission plane) nodes in case it is
> > > "encapsulated in a new IP header whose destination is equal to
> > > the target IP address." [RSVP-TE, section 4.3] ? Is it routed
> > > over a series of signalling channels ? By which routing protocol ?
> > >
> > >
> > > > In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery
> > > > procedure treats nodal failure and control channel failure differently
> > > > (please see above for how they are related to the failure of the
> > > > individual processes).
> > > >
> > > > I think what you're proposing is that we don't need to distinguish
> > > > between the two and we can always apply the signaling channel failure
> > > > (draft uses the term nodal failure to refer to a more general case)
> > > > mechanisms, even in the case of control channel failure?
> > >
> > > My proposal would be to use non-GMPLS specific mechanisms to route
> > > control packets to the intended destination.
> > >
> > >
> > > > Clearly in the absence of LMP, failure of all control channels can
> > > > only be detected by the signaling layer, hence will be treated as
> > > > nodal failures. However, with failure detection on the control channel,
> > > > we can do a better job in recovering.
> > >
> > > Could we agree that the whole "control channel management" mechanism
> > > is only for faster recovery of the control plane ? The idea would be
> > > that failure of one control channel does not change the topology of
> > > the control plane as the associated signalling channel does not get
> > > affected.
> > >
> > > If we could agree on this understanding, I would still opt for non-
> > > GMPLS specific mechanisms.
> >
> > I think the WG has already agreed upon the control channel management 
> procedure within the scope of LMP. I am not sure what is the value of 
> this discussion at this point. I'll let some one else comment on it.
> >
> > <snip>
> > ===============
> > Zafar Ali
> > Cisco Systems
> > (734) 276-2459
> > 100 S Main St. #200
> > Ann Arbor, MI 48104.
> > email: [email-masked]
>
>--
>+------------------------------------------------------------------+
>| Michiel van Everdingen                                           |
>| Systems Engineer                                                 |
>| Lucent Technologies - Optical Networking Group                   |
>| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
>| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
>| Huizen, The Netherlands        mailto:[email-masked] |
>+------------------------------------------------------------------+
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

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

<html>
<font size=3>Hi Michiel, <br>
<br>
Thanks for the summary; please see comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
At 12:10 PM 4/26/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=cite cite>Hello Zafar,<br>
<br>
Please allow me to summarize my understanding of our discussion 
thus<br>
far.<br>
<br>
LMP's &quot;control channel management&quot;<br>
<br>
- Is an extra, new protocol on top of an existing IP
network.</blockquote><br>
Agreed! <br>
<br>
<blockquote type=cite cite>&nbsp; That is what I understand when Jonathan
writes &quot;You could certainly<br>
&nbsp; create an LMP control channel through a DCN network. In fact,
this<br>
&nbsp; is probably the preferred configuration.&quot;<br>
&nbsp;
<a href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html" eudora="autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html</a><br>
<br>
- Needs careful setting of hello frequency.<br>
&nbsp; This is based on your comment: &quot;LMP Hellos should be faster
than RSVP<br>
&nbsp; Hellos or the mechanism used to detect signalling channel
failure.<br>
&nbsp; Similarly, LMP Hello frequency should be greater than IGP hello
frequency,<br>
&nbsp; so that the optical network can make &quot;conscious&quot;
decision on the control<br>
&nbsp; channel failure, before having an adverse affect on the IGP
adjacencies at L3.&quot;<br>
&nbsp;
<a href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html" eudora="autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html</a></blockquote><br>
Agreed! <br>
<br>
<br>
<blockquote type=cite cite>- Provide a fast recovering transport
mechanism for &quot;signalling channels&quot;<br>
&nbsp;
<a href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html" eudora="autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html</a></blockquote><br>
I would like to reword this as, LMP provides a mean for detecting control
channel failures between LMP neighbors. These control channels are used
by signaling and other control entities. <br>
<br>
<blockquote type=cite cite>Furthermore, there is a need to route packets
through a network consisting<br>
of &quot;signalling channels&quot;: </font></blockquote><br>
I would it to be simply referred as the control network, instead of
network consisting of &quot;signaling channels&quot;. <br>
<br>
<blockquote type=cite cite><font size=3>the RSVP-TE &quot;notify
message&quot; is sent between<br>
non-adjacent (at transmission plane) nodes in case it is
&quot;encapsulated<br>
in a new IP header whose destination is equal to the target IP
address.&quot;<br>
[RSVP-TE, section 4.3]</font></blockquote><br>
The notify message with the above mentioned option is also sent over the
control network, like other signaling messages.&nbsp; I did not see the
relationship here. Can you please elaborate a bit further why you are
mentioning this here? <br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>So in other words, the proposal
is to create an extra &quot;network layer&quot;<br>
(OSI terminology) consisting of &quot;signalling channels&quot;. These
&quot;signalling<br>
channels&quot; make use of underlying &quot;control channels&quot; which
again can make<br>
use of any generic network layer (e.g. DCN). Correct
?</font></blockquote><br>
No, I don't think so. Just because we've a peer to peer protocol for
detecting health of the control channels, IMO, does not mean that we've
introduced an extra &quot;network layer&quot;. Control network is still
managed like any other (IP) network.&nbsp; <br>
<br>
<br>
<blockquote type=cite cite><font size=3>I agree with you that we need to
carefully look at the &quot;hello&quot; frequencies<br>
of these network layers. Probably some consideration is also needed
for<br>
hello-timers on datalink layer and hold-off timers at transport
layer.</font></blockquote><br>
I did not understand which hold off timers you're referring to here?, and
what is the relationship of some timers at the &quot;transport
layer&quot; with the operation of control network? <br>
<br>
<br>
<blockquote type=cite cite><font size=3>All together, my feeling is that
this is getting quite complex.<br>
<br>
Are we sure we want to go in this direction ? Can't we simply 
remove<br>
the whole &quot;control channel management&quot; mechanism and define
&quot;control<br>
channel&quot; as follows:<br>
&nbsp; control channel = a facility that interconnects two switching
neighbours<br>
&nbsp; at the transmission plane for the purpose of exchanging control
messages.<br>
&nbsp; This facility can be in-band or out-of-band; point-to-point or
multi-point.<br>
If we would accept this definition, a DCN network (or better: SCN
network)<br>
can be an implementation to have control channels between all
neighbouring<br>
nodes at the transmission plane.</font></blockquote><br>
I am not is a position to comment on this. However, I would like to
reiterate a couple of points. First, I thought that much of the LMP draft
is already agreed upon and is close to become an RFC, so I am not sure
the value of this discussion at this stage. Secondly, I don't think there
were convincing enough arguments to go in that direction. <br>
<br>
<br>
<blockquote type=cite cite><font size=3>If we have to go on discussing
&quot;control channel management&quot;, I think we<br>
still have the following open questions:<br>
- why does control channel management need to be
fast</font></blockquote><br>
No, I don't think that <font size=3>control channel management need to be
fast (O(mseconds)). I think this will be a comment to the authors of the
draft to clarify this point in the draft and remove the related text from
it. <br>
<br>
<blockquote type=cite cite>- is control channel management
fast.</font></blockquote><br>
No, IMO, it only need to satisfy that requirements that I pointed out
earlier in,<br>
<font size=3><a href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html" eudora="autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html<br>
<br>
<br>
<br>
</a><blockquote type=cite cite>On your email:<br>
<br>
&gt; I don't see if we can cover all cases of control channel failure
detection<br>
&gt; after removing this functionality from LMP (e.g., the case of routed
control<br>
&gt; channels or control channels where L2 failure detection is not
feasible).<br>
<br>
Hopefully someone on this mailing list can show us a case in which a
standard<br>
IP network is not sufficient for the control plane...<br>
<br>
<br>
&gt; LMP will be using UDP, as indicated in an earlier email from
Jonathan.<br>
<br>
Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask
if<br>
we could add neighbour discovery in LMP and to get clarity on the use
of<br>
&quot;control channel management&quot;. Guess I was somewhat naive to
think that that<br>
could easily be settled....<br>
<br>
<br>
&gt; &gt; Indeed. In some cases L2 detects the failure, in other cases L3
detects<br>
&gt; &gt; the failure. Still confused as to why we can't stick to
standard L3<br>
&gt; &gt; mechanisms to detect the failure...<br>
&gt; <br>
&gt; Can you please elaborate on what &quot;other&quot; L3 mechanisms
you're referring to<br>
&gt; here? How would you cover the case of an IP routed control
channel?<br>
<br>
I did not speak about &quot;other&quot; L3 mechanisms. Just standard L3
mechanisms.</font></blockquote><br>
Such mechanism runs on physical links in the control network. However,
when we've a routed control channel, these mechanisms do not help us.
<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>&gt; I think the WG has already
agreed upon the control channel management<br>
&gt; procedure within the scope of LMP. I am not sure what is the value
of<br>
&gt; this discussion at this point. I'll let some one else comment on
it.<br>
<br>
Personally, I found our discussion very useful. Thanks for the
to-the-point<br>
answers !</font></blockquote><br>
Likewise, it has been a pleasure exchanging ideas with you :-) <br>
<br>
Thanks... <br>
<br>
<font size=3>Regards.... Zafar <br>
<br>
<br>
<br>
<blockquote type=cite cite>Best regards,<br>
<br>
Michiel<br>
<br>
<br>
Zafar Ali wrote:<br>
&gt; <br>
&gt; Hi Michiel:<br>
&gt; <br>
&gt; Please see comments in-lined.<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Regards... Zafar<br>
&gt; <br>
&gt; At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:<br>
&gt; <br>
&gt; &gt; Hello Zafar,<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; &gt; I'm still confused as to why standard network layer
mechanisms would not<br>
&gt; &gt; &gt; &gt; be sufficient.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I think this answer depends on how we define
sufficient;-)<br>
&gt; &gt;<br>
&gt; &gt; As control channel management is a mandatory part of LMP, I
would define<br>
&gt; &gt; &quot;sufficient&quot; as &quot;minimally needed to run
LMP&quot; or maybe &quot;minimally needed<br>
&gt; &gt; to run GMPLS&quot;.<br>
&gt; <br>
&gt; I don't see if we can cover all cases of control channel failure
detection after removing this functionality from LMP (e.g., the case of
routed control channels or control channels where L2 failure detection is
not feasible). Please note that control channel failure detection is
currently a<br>
&gt; requirement for the GMPLS framework, which is already agreed upon,
AFAIK.<br>
&gt; <br>
&gt; &gt; &gt; LMP control channel management brings some features into
picture, e.g.,<br>
&gt; &gt; &gt; when we’ve hidden control channels, how can we guarantee
that the neighbor<br>
&gt; &gt; &gt; is listening to the channel we’re sending your control
messages to? With<br>
&gt; &gt; &gt; the configuration handshake, LMP guarantees that the two
ends are ready<br>
&gt; &gt; &gt; to exchange messages on the control channel in
question.<br>
&gt; &gt;<br>
&gt; &gt; I guess control messages will use either TCP, UDP or IP.
Correct ?<br>
&gt; <br>
&gt; LMP will be using UDP, as indicated in an earlier email from
Jonathan.<br>
&gt; <br>
&gt; &gt; In case of TCP, I'm assuming TCP's connection establishment
phase takes<br>
&gt; &gt; care that the neighbour is listening.<br>
&gt; &gt;<br>
&gt; &gt; In case the control messages are sent using UDP or IP, I agree
that the<br>
&gt; &gt; application has to make sure that the neighbour is listening.
For the<br>
&gt; &gt; LMP control messages this seems no problem as they are
acknowledged<br>
&gt; &gt; anyway by LMP (e.g. linkSummaryAck for the linkSummary
message). The<br>
&gt; &gt; application can then simply resent the message until it
receives a<br>
&gt; &gt; '(N)Ack'.<br>
&gt; <br>
&gt; Yes, also this is because LMP does not assume a reliable transport
for the control traffic (over the control channel).<br>
&gt; <br>
&gt; &gt; &gt; Similarly, it provides a way by which failure on a routed
control<br>
&gt; &gt; &gt; channel (control channel is not bound to a physical
interface) or a<br>
&gt; &gt; &gt; control channel where L2 cannot detect the failure.<br>
&gt; &gt;<br>
&gt; &gt; Indeed. In some cases L2 detects the failure, in other cases L3
detects<br>
&gt; &gt; the failure. Still confused as to why we can't stick to
standard L3<br>
&gt; &gt; mechanisms to detect the failure...<br>
&gt; <br>
&gt; Can you please elaborate on what &quot;other&quot; L3 mechanisms
you're referring to here? How would you cover the case of an IP routed
control channel?<br>
&gt; <br>
&gt; &gt; &gt; Without LMP control channel management, how you would
suggest<br>
&gt; &gt; &gt; management and health check for such control channels?
Skipping<br>
&gt; &gt; &gt; such tests will IMO lead to a more ad hoc procedures/
protocols.<br>
&gt; &gt;<br>
&gt; &gt; See above.<br>
&gt; &gt; For inter operability reasons, we could specify which mechanism
has<br>
&gt; &gt; to be used as a minimum (e.g. I-ISIS ?). Additional
mechanisms<br>
&gt; &gt; (like MPLS protection, ML-PPP, ...) are then optional.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; Signaling channel is a term I used to specify the
following:<br>
&gt; &gt; &gt; Signaling channel is the logical channel over which
signaling<br>
&gt; &gt; &gt; (say RSVP-TE) messages are exchanged between RSVP peering
entities.<br>
&gt; &gt; &gt; The signaling channel is realized using the collection of
all<br>
&gt; &gt; &gt; control channels between the two RSVP peers.<br>
&gt; &gt; &gt; A signaling channel failure could be the result of the
concurrent<br>
&gt; &gt; &gt; failure of all control channels or the failure of one of
the peering<br>
&gt; &gt; &gt; signaling entities or one of the peering nodes. Hence,
signaling<br>
&gt; &gt; &gt; channel failure is different than failure of all control
channels.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Using the above mentioned definition, a nodal failure
always imply<br>
&gt; &gt; &gt; the failure of the signaling channel as well as control
channels.<br>
&gt; &gt; &gt; However, failure of the last control channel does not
imply a nodal<br>
&gt; &gt; &gt; failure. For the sake of completeness, a signaling channel
failure<br>
&gt; &gt; &gt; could be due to failure of the<br>
&gt; &gt; &gt; peering RSVP process or due to the neighbor node failure.
The<br>
&gt; &gt; &gt; draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term
nodal<br>
&gt; &gt; &gt; failure to cover both cases: i.e., the case where peering
RSVP<br>
&gt; &gt; &gt; entity restarts or the entire node fails. In either case,
non-stop<br>
&gt; &gt; &gt; forwarding is assumed. In short, failure of<br>
&gt; &gt; &gt; the last control channel is different from the nodal
failures.<br>
&gt; &gt;<br>
&gt; &gt; Thanks for the definitions !<br>
&gt; &gt;<br>
&gt; &gt; Just to check: a signalling channel failure is different from a
nodal<br>
&gt; &gt; failure. A nodal failure implies a signalling channel failure,
but not<br>
&gt; &gt; the other way around. Correct ?<br>
&gt; <br>
&gt; Yes, failure of a peering signaling process also leads to signaling
channel failure.<br>
&gt; But, the actions taken in the restart procedure are the same, for
the obvious reasons.<br>
&gt; <br>
&gt; &gt; In these definitions, how would an RSVP-TE &quot;notify
message&quot; be sent<br>
&gt; &gt; between non-adjacent (at transmission plane) nodes in case it
is<br>
&gt; &gt; &quot;encapsulated in a new IP header whose destination is
equal to<br>
&gt; &gt; the target IP address.&quot; [RSVP-TE, section 4.3] ? Is it
routed<br>
&gt; &gt; over a series of signalling channels ? By which routing
protocol ?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP
recovery<br>
&gt; &gt; &gt; procedure treats nodal failure and control channel failure
differently<br>
&gt; &gt; &gt; (please see above for how they are related to the failure
of the<br>
&gt; &gt; &gt; individual processes).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I think what you’re proposing is that we don’t need to
distinguish<br>
&gt; &gt; &gt; between the two and we can always apply the signaling
channel failure<br>
&gt; &gt; &gt; (draft uses the term nodal failure to refer to a more
general case)<br>
&gt; &gt; &gt; mechanisms, even in the case of control channel
failure?<br>
&gt; &gt;<br>
&gt; &gt; My proposal would be to use non-GMPLS specific mechanisms to
route<br>
&gt; &gt; control packets to the intended destination.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; Clearly in the absence of LMP, failure of all control
channels can<br>
&gt; &gt; &gt; only be detected by the signaling layer, hence will be
treated as<br>
&gt; &gt; &gt; nodal failures. However, with failure detection on the
control channel,<br>
&gt; &gt; &gt; we can do a better job in recovering.<br>
&gt; &gt;<br>
&gt; &gt; Could we agree that the whole &quot;control channel
management&quot; mechanism<br>
&gt; &gt; is only for faster recovery of the control plane ? The idea
would be<br>
&gt; &gt; that failure of one control channel does not change the
topology of<br>
&gt; &gt; the control plane as the associated signalling channel does not
get<br>
&gt; &gt; affected.<br>
&gt; &gt;<br>
&gt; &gt; If we could agree on this understanding, I would still opt for
non-<br>
&gt; &gt; GMPLS specific mechanisms.<br>
&gt; <br>
&gt; I think the WG has already agreed upon the control channel
management procedure within the scope of LMP. I am not sure what is the
value of this discussion at this point. I'll let some one else comment on
it.<br>
&gt; <br>
&gt; &lt;snip&gt;<br>
&gt; ===============<br>
&gt; Zafar Ali<br>
&gt; Cisco Systems<br>
&gt; (734) 276-2459<br>
&gt; 100 S Main St. #200<br>
&gt; Ann Arbor, MI 48104.<br>
&gt; email: [email-masked]<br>
<br>
-- <br>
+------------------------------------------------------------------+<br>
| Michiel van
Everdingen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Systems
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Lucent Technologies - Optical Networking
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Botterstraat 45, 1271 XL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :
+31 35 687
4883&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
| P.O. Box 18, 1270
AA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax&nbsp;&nbsp; : +31 35 687
5976&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
| Huizen, The Netherlands&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>
|<br>
+------------------------------------------------------------------+</blockquote>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]<br>
<br>
</font></html>

--=====================_56078156==_.ALT--

Delivery-date: Sat, 27 Apr 2002 22:55:04 -0700
Date: Sun, 28 Apr 2002 01:52:55 -0400
To: Kireeti Kompella <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: TE metric and graceful restart
Cc: <[email-masked]>

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

Dear Kireeti,

Thanks for the reply; Please see comments in-lined.

At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:

>On Sat, 27 Apr 2002, Zafar Ali wrote:
>
> > The reason that I understood this as a MAY case is that a node that saves
> > bandwidth usage state information locally is able to determine (or
> > estimate) the amount of unreserved resources immediately upon start-up. In
> > which case it MAY advertise the saved (projected) value(s) during the
> > graceful restart period.
>
>Attractive as that may be, life is not so simple.  The process of
>recovery for signaling is complex enough without having new LSPs set
>up during recovery.  The idea of discouraging LSPs during recovery is
>not just that the recovering node doesn't know its unreserved bandwidth,
>but that it wants to complete recovery before setting up new LSPs.
>
>A simple example is that the recovering node X uses per-box labels,
>gets a new LSP request while recovering, and allocates label L to that
>request.  But L is already in use for an existing LSP ....
>One can
>work around this particular example, but keeping it simple seems like
>a good initial goal.

Agreed! As I also mentioned that in doing so the node looses the charm of 
discouraging other nodes in the network in using it, during the restart 
period. This opens doors for some potential race conditions and scenarios 
like the one you mentioned in the email. Of course, a node that may choose 
to do so has to deal with kind of scenarios that you mentioned in the 
email. I see that there are some tradeoffs involved and the standard should 
leave a room for exercising such options. Hence, IMO this should be a local 
(vendor specific) decision.

In short, while I am agreeing with the recommendation, I think the "SHOULD" 
part should be removed and the standard should leave it as part of the 
local decision.

Thanks

Regards... Zafar

>At least, that's my take.
>
>Kireeti.
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

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

<html>
<font size=3>Dear Kireeti, <br>
<br>
Thanks for the reply; Please see comments in-lined. <br>
<br>
At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:<br>
<br>
<blockquote type=cite cite>On Sat, 27 Apr 2002, Zafar Ali wrote:<br>
<br>
&gt; The reason that I understood this as a MAY case is that a node that
saves<br>
&gt; bandwidth usage state information locally is able to determine
(or<br>
&gt; estimate) the amount of unreserved resources immediately upon
start-up. In<br>
&gt; which case it MAY advertise the saved (projected) value(s) during
the<br>
&gt; graceful restart period.<br>
<br>
Attractive as that may be, life is not so simple.&nbsp; The process
of<br>
recovery for signaling is complex enough without having new LSPs 
set<br>
up during recovery.&nbsp; The idea of discouraging LSPs during recovery
is<br>
not just that the recovering node doesn't know its unreserved
bandwidth,<br>
but that it wants to complete recovery before setting up new LSPs.<br>
<br>
A simple example is that the recovering node X uses per-box labels,<br>
gets a new LSP request while recovering, and allocates label L to
that<br>
request.&nbsp; But L is already in use for an existing LSP ....&nbsp;
<br>
One can<br>
work around this particular example, but keeping it simple seems
like<br>
a good initial goal.</font></blockquote><br>
<font size=3>Agreed! As I also mentioned that in doing so the node looses
the charm of discouraging other nodes in the network in using it, during
the restart period. This opens doors for some potential race conditions
and scenarios like the one you mentioned in the email. Of course, a node
that may choose to do so has to deal with kind of scenarios that you
mentioned in the email. I see that there are some tradeoffs involved and
the standard should leave a room for exercising such options. Hence, IMO
this should be a local (vendor specific) decision. <br>
<br>
In short, while I am agreeing with the recommendation, I think the
&quot;SHOULD&quot; part should be removed and the standard should leave
it as part of the local decision. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite>At least, that's my take.<br>
<br>
Kireeti.</blockquote>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked] <br>
</font></html>

--=====================_55742152==_.ALT--

Delivery-date: Sat, 27 Apr 2002 22:04:33 -0700
Date: Sat, 27 Apr 2002 22:01:11 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Zafar Ali <[email-masked]>
cc: <[email-masked]>
Subject: RE: TE metric and graceful restart

On Sat, 27 Apr 2002, Zafar Ali wrote:

> The reason that I understood this as a MAY case is that a node that saves
> bandwidth usage state information locally is able to determine (or
> estimate) the amount of unreserved resources immediately upon start-up. In
> which case it MAY advertise the saved (projected) value(s) during the
> graceful restart period.

Attractive as that may be, life is not so simple.  The process of
recovery for signaling is complex enough without having new LSPs set
up during recovery.  The idea of discouraging LSPs during recovery is
not just that the recovering node doesn't know its unreserved bandwidth,
but that it wants to complete recovery before setting up new LSPs.

A simple example is that the recovering node X uses per-box labels,
gets a new LSP request while recovering, and allocates label L to that
request.  But L is already in use for an existing LSP ....  One can
work around this particular example, but keeping it simple seems like
a good initial goal.

At least, that's my take.

Kireeti.

Delivery-date: Sat, 27 Apr 2002 09:22:52 -0700
Date: Sat, 27 Apr 2002 12:16:39 -0400
To: "Don Fedyk"<[email-masked]>, Alex Zinin <[email-masked]>, Yakov Rekhter <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: TE metric and graceful restart
Cc: [email-masked]

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

At 03:12 PM 4/26/2002 -0400, Don Fedyk wrote:

>Yakov
>
>I have a question. Do you mean that a node that is restarting
>its routing view and learning from it's neighbors should mark
>the TE metrics to local neighbors to infinity?

Dear Dan, Yakov, et all:

One point that I would like to point out and make sure that it is NOT a 
requirement that a restarting node SHOULD advertise the infinity TE metric, 
0 bandwidth attributes, etc.

The reason that I understood this as a MAY case is that a node that saves 
bandwidth usage state information locally is able to determine (or 
estimate) the amount of unreserved resources immediately upon start-up. In 
which case it MAY advertise the saved (projected) value(s) during the 
graceful restart period. Understood that in doing so the node in question 
looses the charm of discouraging other nodes in the network in using it, 
during the restart period, but this should be a local decision. 
Furthermore, after completion of the restart procedure, the node in 
question may only re-advertise the actual account information if there is a 
significant change between the projected values and the actual value 
computed as part of the recovery procedure. Hence, in this fashion, it 
minimizes the disruption to the network.

Please verify.

Thanks

Regards... Zafar

>I think that during
>any graceful restart the TE metrics will not have a perfect view
>and local path selections should be blocked but setting the metrics
>artificially to infinity seems like the wrong way to do this in my
>opinion.
>
>Don
>
> > -----Original Message-----
> > From: Alex Zinin [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Friday, April 26, 2002 2:55 PM
> > To: Yakov Rekhter
> > Cc: [email-masked]
> > Subject: Re: TE metric and graceful restart
> >
> >
> > Yakov,
> >
> >   How does this improve the situation given that
> >   unreserved BW of 0 is already announced?
> >
> > --
> > Alex
> >
> > Thursday, April 25, 2002, 12:47:57 PM, you wrote:
> > > Folks,
> >
> > > It was suggested to set the TE metric to infinity during graceful
> > > restart (both for ISIS and OSPF).
> >
> > > Any objections to this suggestion ???
> >
> > > Yakov.
> >
> >
> >
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]
--=====================_6710238==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 03:12 PM 4/26/2002 -0400, Don Fedyk wrote:<br>
<br>
</font><blockquote type=cite cite><font size=2>Yakov <br>
</font><font size=3><br>
</font><font size=2>I have a question. Do you mean that a node that is
restarting</font><font size=3> <br>
</font><font size=2>its routing view and learning from it's neighbors
should mark </font><font size=3><br>
</font><font size=2>the TE metrics to local neighbors to infinity?
</font></blockquote><br>
<font size=3>Dear Dan, Yakov, et all:<br>
<br>
One point that I would like to point out and make sure that it is NOT a
requirement that a restarting node SHOULD advertise the infinity TE
metric, 0 bandwidth attributes, etc. <br>
<br>
The reason that I understood this as a <u>MAY</u> case is that a node
that saves bandwidth usage state information locally is able to determine
(or estimate) the amount of unreserved resources immediately upon
start-up. In which case it <u>MAY</u> advertise the saved (projected)
value(s) during the graceful restart period. Understood that in doing so
the node in question looses the charm of discouraging other nodes in the
network in using it, during the restart period, but this should be a
local decision. Furthermore, after completion of the restart procedure,
the node in question may only re-advertise the actual account information
if there is a significant change between the projected values and the
actual value computed as part of the recovery procedure. Hence, in this
fashion, it minimizes the disruption to the network. <br>
<br>
Please verify. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
</font><blockquote type=cite cite><font size=2>I think that during
</font><font size=3><br>
</font><font size=2>any graceful restart the TE metrics will not have a
perfect view </font><font size=3><br>
</font><font size=2>and local path selections should be blocked but
setting the metrics</font><font size=3> <br>
</font><font size=2>artificially to infinity seems like the wrong way to
do this in my</font><font size=3> <br>
</font><font size=2>opinion. <br>
</font><font size=3><br>
</font><font size=2>Don</font><font size=3> <br>
<br>
</font><font size=2>&gt; -----Original Message-----</font><font size=3>
<br>
</font><font size=2>&gt; From: Alex Zinin
[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font><font size=3>
<br>
</font><font size=2>&gt; Sent: Friday, April 26, 2002 2:55
PM</font><font size=3> <br>
</font><font size=2>&gt; To: Yakov Rekhter</font><font size=3> <br>
</font><font size=2>&gt; Cc: [email-masked]</font><font size=3> 
<br>
</font><font size=2>&gt; Subject: Re: TE metric and graceful
restart</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; Yakov,</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt;&nbsp;&nbsp; How does this improve the situation
given that</font><font size=3> <br>
</font><font size=2>&gt;&nbsp;&nbsp; unreserved BW of 0 is already
announced?</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; -- </font><font size=3><br>
</font><font size=2>&gt; Alex</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; Thursday, April 25, 2002, 12:47:57 PM, you
wrote:</font><font size=3> <br>
</font><font size=2>&gt; &gt; Folks,</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; &gt; It was suggested to set the TE metric to
infinity during graceful</font><font size=3> <br>
</font><font size=2>&gt; &gt; restart (both for ISIS and OSPF).
</font><font size=3><br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; &gt; Any objections to this suggestion
???</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; &gt; Yakov.</font><font size=3> <br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt; </font><font size=3><br>
</font><font size=2>&gt;
</font></blockquote><font size=3>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]</font></html>

--=====================_6710238==_.ALT--

Delivery-date: Fri, 26 Apr 2002 19:55:18 -0700
Date: Fri, 26 Apr 2002 19:54:47 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Naidu, Venkata" <[email-masked]>
cc: <[email-masked]>
Subject: RE: TE metric and graceful restart

On Fri, 26 Apr 2002, Naidu, Venkata wrote:

>   1. First of all, your suggestion might not fit well
>      with draft draft-lefaucheur-te-metric-igp-01.txt.
>      That is, just changing TE metric might help you to
>      stop _some_ unwanted LSPs being setup in restart
>      period but not all. (example, LSPs that use IGP metric
>      in OSPF regular LSAs)

Turn that around: Yakov's proposal helps in all the cases that can
be helped.  Do you have a proposal to stop/discourage the setup of
LSPs that use the IGP metric?

>   2. If we change any of TE LSA contents and flood the
>      *Restart TE LSAs* to neighbor nodes, then there are
>      2 cases:
>
>      (a) The neighbor might have accepted as a helper
>          node
>      (b) The neighbor might have rejected (not at
>          all received any OSPF-grace LSA etc - for so
>          many reasons I can think of)
>
>    In the case (b), OSPF neighbor will simple flood the restart
>    TE LSA into the domain. That is something what you are not
>    intended in the below para:
>
>    ***
>    Neighbors of the restarting node should continue advertise the actual
>    unreserved bandwidth on the TE links from the neighbors to that node.
>    ***

You misread.  The TE links *from the node to the neighbors* change, not
the other way around.  By the way, the so-called restart TE LSAs are
intended to be flooded in all cases, not just when the neighbor doesn't
help.

>   3. More over, I think this is a Re-optimization issue rather than
>      a restart issue. So, IMHO, it is better not to flood the TE LSA
>      (with BW 0 and Infinite Metric changes).

Explain, please.

>   4. Actually, the LSP preventing in the grace period should
>      be handled in signaling protocols and definitely not
>      using back doors of routing protocols.

Explain, please.

Kireeti.

Delivery-date: Fri, 26 Apr 2002 19:38:32 -0700
Date: Fri, 26 Apr 2002 19:36:33 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Alex Zinin <[email-masked]>
cc: <[email-masked]>
Subject: Re: TE metric and graceful restart

On Fri, 26 Apr 2002, Alex Zinin wrote:

> I don't think there's anything in the OSPF & ISIS TE drafts that
> prevents links with max metric from being used in CSPF, so
> it is only more of discouragement, not prevention per se...

There is nothing in the OSPF and ISIS TE drafts that says anything
about how to do CSPF by design.  CSPF is local to the node doing the
computation; it was thought to be a vendor value-add, and hence not
specified.

So the best one can do is discourage -- one can never preempt, except
by removing the link from TE.  However, removing the link will negate
the value of graceful restart.

Hence the proposal: set b/w to 0, and metric to infinity.

Kireeti.

Delivery-date: Fri, 26 Apr 2002 14:18:39 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, Don Fedyk <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Subject: RE: TE metric and graceful restart 
Date: Fri, 26 Apr 2002 17:17:27 -0400

-> Why ? And what is in your opinion the correct way to do this ?

  Signal all of Router neighbors that any LSPs should not be 
  accepted even if the link/path constraints are valid.
 
  This can be done in several ways (4 of my suggestions): 

  Using Routing Protocols
  =======================
  (a) Extend another link local opaque LSA (call it Grace-TE-LSA) 
      which will inform Grace period, action, reason etc 
      etc to neighbors.

      And all *helper* nodes should do the needful in
      signaling/CSPF till grace period.
 
      If the nodes are NOT helpful (for so many reasons) 
      then the Grace-TE-LSA will any way not flooded
      beyond neighbors.

  (b) The *Best* way is - just add ACTION TLV in Grace-LSA 
      format defined in draft-ietf-ospf-hitless-restart-02.txt
      That will dictate *all* the actions to take and
      it is easy to extend for future *restart actions*

	ACTION 0 - Unknown
	ACTION 1 - Don't Allow LSPs
	ACTION 2 - Allow LSPs
 	etc etc....

  (c) Keep every thing same (as it is now) AND generate TE-LSA
      with BW 0 and TE metric Infinity using Link Scope Opaque 
      LSA instead of Area Scope Opaque LSA.

  Using signaling protocols
  =========================
  (d) I don't how well we can extend RSVP hellos to do this job?!? 
      But I am sure there must be several ways...(using Hellos etc)

Venkata.

Delivery-date: Fri, 26 Apr 2002 13:48:47 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'Alex Zinin'" <[email-masked]>, Zafar Ali <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: TE metric and graceful restart
Date: Fri, 26 Apr 2002 16:48:08 -0400

Alex:

-> I don't think there's anything in the OSPF & ISIS TE drafts that
-> prevents links with max metric from being used in CSPF,

  TE drafts won't talk about this...it is implicit CSPF.
  IMHO, It is better to add this condition in TE drafts.

  If all the properties and metric ranges are valid,
  then there must/should exist atleast a *value* (Infinity)
  for negation. This applies to all/any path/link 
  constraints.

Venkata.

Delivery-date: Fri, 26 Apr 2002 13:46:11 -0700
To: "Naidu, Venkata" <[email-masked]>
cc: [email-masked]
Subject: Re: encoding link id for unnumbered interfaces 
Date: Fri, 26 Apr 2002 13:45:55 -0700
From: Yakov Rekhter <[email-masked]>

> Yakov,
> 
> -> I'd like to suggest that we replace Link Local Identifier sub-TLV
> -> and Link Remote Identifier sub-TLV (in both ISIS and OSPF) with a
> -> single sub-TLV that would contain both Link Local Identifier and Link 
> -> Remote Identifier.
> 
> -> Any objections ?
> 
>   I prefer : different sub-TLVs. That gives consistency and
>              easy modification in future.
> 
>   I suggest: Rather make Remote Identifier *mandatory* when
>              Local Identifier is present. This is definitely
>              bad but little better than your suggestion. :-)
> 
>   I like   : Make both Local and Remote Identifiers are optional
>              (just like local and remote IP address TLVs in TE)
>              and leave the decision to individual vendors 
>              (local decision). 
> 
>   Is there any scenario where this causes interop issues?!?!
>   Is that you are worried about *Tag, Length* extra memory
>   consumption?

No, it is just that if you have both local and remote identifiers
in the same sub-TLV, you don't have to worry about such error
cases as the situation where you have remote identifier sub-TLV
present, but the local identifier sub-TLV missing.

Yakov.

P.S. In contrast with numbered interfaces that allow for both
p2p and multiaccess interfaces, unnumbered interfaces are
restricted to p2p only.

Delivery-date: Fri, 26 Apr 2002 13:42:43 -0700
To: "Don Fedyk" <[email-masked]>
cc: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart 
Date: Fri, 26 Apr 2002 13:41:49 -0700
From: Yakov Rekhter <[email-masked]>

Don,

> I have a question. Do you mean that a node that is restarting
> its routing view and learning from it's neighbors should mark 
> the TE metrics to local neighbors to infinity? 

That is correct.

> I think that during 
> any graceful restart the TE metrics will not have a perfect view 
> and local path selections should be blocked but setting the metrics
> artificially to infinity seems like the wrong way to do this in my
> opinion. 

Why ? And what is in your opinion the correct way to do this ?

Yakov.

> 
> Don
> 
> > -----Original Message-----
> > From: Alex Zinin [mailto:[email-masked]]
> > Sent: Friday, April 26, 2002 2:55 PM
> > To: Yakov Rekhter
> > Cc: [email-masked]
> > Subject: Re: TE metric and graceful restart
> > 
> > 
> > Yakov,
> > 
> >   How does this improve the situation given that
> >   unreserved BW of 0 is already announced?
> > 
> > -- 
> > Alex
> > 
> > Thursday, April 25, 2002, 12:47:57 PM, you wrote:
> > > Folks,
> > 
> > > It was suggested to set the TE metric to infinity during graceful
> > > restart (both for ISIS and OSPF). 
> > 
> > > Any objections to this suggestion ???
> > 
> > > Yakov.
> > 
> > 
> > 
> 
> ------_=_NextPart_001_01C1ED56.433DDC64
> Content-Type: text/html;
> 	charset="ISO-8859-1"
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
> <TITLE>RE: TE metric and graceful restart</TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=2>Yakov </FONT>
> </P>
> 
> <P><FONT SIZE=2>I have a question. Do you mean that a node that is restarting
</FONT>
> <BR><FONT SIZE=2>its routing view and learning from it's neighbors should mar
k </FONT>
> <BR><FONT SIZE=2>the TE metrics to local neighbors to infinity? I think that 
during </FONT>
> <BR><FONT SIZE=2>any graceful restart the TE metrics will not have a perfect 
view </FONT>
> <BR><FONT SIZE=2>and local path selections should be blocked but setting the 
metrics</FONT>
> <BR><FONT SIZE=2>artificially to infinity seems like the wrong way to do this
 in my</FONT>
> <BR><FONT SIZE=2>opinion. </FONT>
> </P>
> 
> <P><FONT SIZE=2>Don</FONT>
> </P>
> 
> <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
> <BR><FONT SIZE=2>&gt; From: Alex Zinin [<A HREF="mailto:[email-masked]">mailto
:[email-masked]</A>]</FONT>
> <BR><FONT SIZE=2>&gt; Sent: Friday, April 26, 2002 2:55 PM</FONT>
> <BR><FONT SIZE=2>&gt; To: Yakov Rekhter</FONT>
> <BR><FONT SIZE=2>&gt; Cc: [email-masked]</FONT>
> <BR><FONT SIZE=2>&gt; Subject: Re: TE metric and graceful restart</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; Yakov,</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp; How does this improve the situation given t
hat</FONT>
> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp; unreserved BW of 0 is already announced?</F
ONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; -- </FONT>
> <BR><FONT SIZE=2>&gt; Alex</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; Thursday, April 25, 2002, 12:47:57 PM, you wrote:</FONT
>
> <BR><FONT SIZE=2>&gt; &gt; Folks,</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; &gt; It was suggested to set the TE metric to infinity 
during graceful</FONT>
> <BR><FONT SIZE=2>&gt; &gt; restart (both for ISIS and OSPF). </FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; &gt; Any objections to this suggestion ???</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; &gt; Yakov.</FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> <BR><FONT SIZE=2>&gt; </FONT>
> </P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C1ED56.433DDC64--

Delivery-date: Fri, 26 Apr 2002 13:38:43 -0700
To: Zafar Ali <[email-masked]>
cc: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart 
Date: Fri, 26 Apr 2002 13:38:23 -0700
From: Yakov Rekhter <[email-masked]>

Zafar,

> > > One of the things that it'll do that it'll also prevent someone from using
> > > these links in the Path computation with "0" bandwidth (while the node in
> > > question is restarting). In some scenarios, e.g., signaling for a backup
> > > tunnel without no bandwidth reservation, a (remote) node may be interested
> > > in Paths with "0" bandwidth.
> >
> >I don't think there's anything in the OSPF & ISIS TE drafts that
> >prevents links with max metric from being used in CSPF, so
> >it is only more of discouragement, not prevention per se...
> >Is this still interesting?
> 
> Dear Alex and Yakov:
> 
> I meant the same. I used the word prevent (if there are alternates 
> available) in the context of ... by discouraging. Nonetheless, this is an 
> advantage, IMO.
> Yakov, did you have some other motivation (as well?) in mind?

You are correct wrt the motivation - it is to discourage LSP setup
with "0" bandwidth.

Yakov.

> 
> Thanks
> 
> Regards... Zafar
> 
> >[I guess it might be if CSPF has
> >two 0-BW paths one through a restarting LSR and another through
> >an operational one]...
> >
> >Alex.
> ===============
> Zafar Ali
> Cisco Systems
> (734) 276-2459
> 100 S Main St. #200
> Ann Arbor, MI 48104.
> email: [email-masked]
> --=====================_27231316==_.ALT
> Content-Type: text/html; charset="us-ascii"
> 
> <html>
> <font size=3>At 12:58 PM 4/26/2002 -0700, Alex Zinin wrote:<br>
> <blockquote type=cite cite>Zafar,<br>
> <br>
> &gt; One of the things that it'll do that it'll also prevent someone from
> using<br>
> &gt; these links in the Path computation with &quot;0&quot; bandwidth
> (while the node in <br>
> &gt; question is restarting). In some scenarios, e.g., signaling for a
> backup <br>
> &gt; tunnel without no bandwidth reservation, a (remote) node may be
> interested <br>
> &gt; in Paths with &quot;0&quot; bandwidth.<br>
> <br>
> I don't think there's anything in the OSPF &amp; ISIS TE drafts 
> that<br>
> prevents links with max metric from being used in CSPF, so<br>
> it is only more of discouragement, not prevention per se...<br>
> Is this still interesting? </font></blockquote><br>
> Dear Alex and Yakov: <br>
> <br>
> I meant the same. I used the word prevent (if there are alternates
> available) in the context of ... by discouraging. Nonetheless, this is an
> advantage, IMO. <br>
> Yakov, did you have some other motivation (as well?) in mind? <br>
> <br>
> Thanks<br>
> <br>
> Regards... Zafar <br>
> <br>
> <blockquote type=cite cite><font size=3>[I guess it might be if CSPF
> has<br>
> two 0-BW paths one through a restarting LSR and another through<br>
> an operational one]...<br>
> <br>
> Alex.</blockquote>===============<br>
> Zafar Ali<br>
> Cisco Systems<br>
> (734) 276-2459<br>
> 100 S Main St. #200<br>
> Ann Arbor, <u>MI 48104</u>.<br>
> email: [email-masked]</font></html>
> 
> --=====================_27231316==_.ALT--
> 

Delivery-date: Fri, 26 Apr 2002 13:37:04 -0700
From: "Naidu, Venkata" <[email-masked]>
To: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: encoding link id for unnumbered interfaces
Date: Fri, 26 Apr 2002 16:36:16 -0400

Yakov,

-> I'd like to suggest that we replace Link Local Identifier sub-TLV
-> and Link Remote Identifier sub-TLV (in both ISIS and OSPF) with a
-> single sub-TLV that would contain both Link Local Identifier and Link 
-> Remote Identifier.

-> Any objections ?

  I prefer : different sub-TLVs. That gives consistency and
             easy modification in future.

  I suggest: Rather make Remote Identifier *mandatory* when
             Local Identifier is present. This is definitely
             bad but little better than your suggestion. :-)

  I like   : Make both Local and Remote Identifiers are optional
             (just like local and remote IP address TLVs in TE)
             and leave the decision to individual vendors 
             (local decision). 

  Is there any scenario where this causes interop issues?!?!
  Is that you are worried about *Tag, Length* extra memory
  consumption?

  Remember, I am _not_ objecting your suggestion, in any case.

Venkata.

Delivery-date: Fri, 26 Apr 2002 13:22:27 -0700
From: "Don Fedyk"<[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: TE metric and graceful restart
Date: Fri, 26 Apr 2002 16:22:00 -0400

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

------_=_NextPart_001_01C1ED60.0532A314
Content-Type: text/plain;
	charset="ISO-8859-1"

Alex

In the simplest situation only routing has restarted, all physical 
connections are up. Routing has to rebuild the world with minimal 
disruption to the network. So during this state the physical links still
have LSPs and the links still have metrics and they should stay. The 
one thing you don't want to do is start a path selection from this 
node but all other options are possible. So I would say just let 
the TE database build until it is synchronized and block local path
selections (which is really easy to do).

By the way I think you can still build LSPs through the node and 
feedback and crank back can be used to bridge the "race conditions" 
that have been opened wider by graceful restart. Eventually the node 
is synchronized with the neighbors and LSAs can be generated. 

If you have more elaborate failures such as software for link management
at the same time routing is synchronizing then these local links can 
have bandwidth and metric changes but this is typical of a link 
failure today and is localized only to the links in question. 

All of this is driven by causing the least amount of disruption 
possible which is the goal of graceful restart. 

Don 

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 4:00 PM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: Yakov Rekhter; [email-masked]
> Subject: Re: TE metric and graceful restart
> 
> 
> Don,
> 
>   Would you care to elaborate more, please?
>   Specifically, what do you think is wrong here
>   and what would be the right way in your opinion.
> 
>   Thanks.
> 
> -- 
> Alex
> 
> Friday, April 26, 2002, 12:12:09 PM, you wrote:
> > Yakov 
> 
> > I have a question. Do you mean that a node that is restarting
> > its routing view and learning from it's neighbors should mark 
> > the TE metrics to local neighbors to infinity? I think that during 
> > any graceful restart the TE metrics will not have a perfect view 
> > and local path selections should be blocked but setting the metrics
> > artificially to infinity seems like the wrong way to do this in my
> > opinion. 
> 
> > Don
> 
> 

------_=_NextPart_001_01C1ED60.0532A314
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: TE metric and graceful restart</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Alex</FONT>
</P>

<P><FONT SIZE=2>In the simplest situation only routing has restarted, all physical </FONT>
<BR><FONT SIZE=2>connections are up. Routing has to rebuild the world with minimal </FONT>
<BR><FONT SIZE=2>disruption to the network. So during this state the physical links still</FONT>
<BR><FONT SIZE=2>have LSPs and the links still have metrics and they should stay. The </FONT>
<BR><FONT SIZE=2>one thing you don't want to do is start a path selection from this </FONT>
<BR><FONT SIZE=2>node but all other options are possible. So I would say just let </FONT>
<BR><FONT SIZE=2>the TE database build until it is synchronized and block local path</FONT>
<BR><FONT SIZE=2>selections (which is really easy to do).</FONT>
</P>

<P><FONT SIZE=2>By the way I think you can still build LSPs through the node and </FONT>
<BR><FONT SIZE=2>feedback and crank back can be used to bridge the &quot;race conditions&quot; </FONT>
<BR><FONT SIZE=2>that have been opened wider by graceful restart. Eventually the node </FONT>
<BR><FONT SIZE=2>is synchronized with the neighbors and LSAs can be generated. </FONT>
</P>

<P><FONT SIZE=2>If you have more elaborate failures such as software for link management</FONT>
<BR><FONT SIZE=2>at the same time routing is synchronizing then these local links can </FONT>
<BR><FONT SIZE=2>have bandwidth and metric changes but this is typical of a link </FONT>
<BR><FONT SIZE=2>failure today and is localized only to the links in question. </FONT>
</P>

<P><FONT SIZE=2>All of this is driven by causing the least amount of disruption </FONT>
<BR><FONT SIZE=2>possible which is the goal of graceful restart. </FONT>
</P>

<P><FONT SIZE=2>Don </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Alex Zinin [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, April 26, 2002 4:00 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Fedyk, Don [BL60:1A00:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Yakov Rekhter; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: TE metric and graceful restart</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Don,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Would you care to elaborate more, please?</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Specifically, what do you think is wrong here</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; and what would be the right way in your opinion.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Thanks.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Alex</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Friday, April 26, 2002, 12:12:09 PM, you wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Yakov </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I have a question. Do you mean that a node that is restarting</FONT>
<BR><FONT SIZE=2>&gt; &gt; its routing view and learning from it's neighbors should mark </FONT>
<BR><FONT SIZE=2>&gt; &gt; the TE metrics to local neighbors to infinity? I think that during </FONT>
<BR><FONT SIZE=2>&gt; &gt; any graceful restart the TE metrics will not have a perfect view </FONT>
<BR><FONT SIZE=2>&gt; &gt; and local path selections should be blocked but setting the metrics</FONT>
<BR><FONT SIZE=2>&gt; &gt; artificially to infinity seems like the wrong way to do this in my</FONT>
<BR><FONT SIZE=2>&gt; &gt; opinion. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Don</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1ED60.0532A314--

Delivery-date: Fri, 26 Apr 2002 13:21:28 -0700
Date: Fri, 26 Apr 2002 16:20:47 -0400
To: Alex Zinin <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: TE metric and graceful restart
Cc: Yakov Rekhter <[email-masked]>, [email-masked]

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

At 12:58 PM 4/26/2002 -0700, Alex Zinin wrote:
>Zafar,
>
> > One of the things that it'll do that it'll also prevent someone from using
> > these links in the Path computation with "0" bandwidth (while the node in
> > question is restarting). In some scenarios, e.g., signaling for a backup
> > tunnel without no bandwidth reservation, a (remote) node may be interested
> > in Paths with "0" bandwidth.
>
>I don't think there's anything in the OSPF & ISIS TE drafts that
>prevents links with max metric from being used in CSPF, so
>it is only more of discouragement, not prevention per se...
>Is this still interesting?

Dear Alex and Yakov:

I meant the same. I used the word prevent (if there are alternates 
available) in the context of ... by discouraging. Nonetheless, this is an 
advantage, IMO.
Yakov, did you have some other motivation (as well?) in mind?

Thanks

Regards... Zafar

>[I guess it might be if CSPF has
>two 0-BW paths one through a restarting LSR and another through
>an operational one]...
>
>Alex.
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]
--=====================_27231316==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 12:58 PM 4/26/2002 -0700, Alex Zinin wrote:<br>
<blockquote type=cite cite>Zafar,<br>
<br>
&gt; One of the things that it'll do that it'll also prevent someone from
using<br>
&gt; these links in the Path computation with &quot;0&quot; bandwidth
(while the node in <br>
&gt; question is restarting). In some scenarios, e.g., signaling for a
backup <br>
&gt; tunnel without no bandwidth reservation, a (remote) node may be
interested <br>
&gt; in Paths with &quot;0&quot; bandwidth.<br>
<br>
I don't think there's anything in the OSPF &amp; ISIS TE drafts 
that<br>
prevents links with max metric from being used in CSPF, so<br>
it is only more of discouragement, not prevention per se...<br>
Is this still interesting? </font></blockquote><br>
Dear Alex and Yakov: <br>
<br>
I meant the same. I used the word prevent (if there are alternates
available) in the context of ... by discouraging. Nonetheless, this is an
advantage, IMO. <br>
Yakov, did you have some other motivation (as well?) in mind? <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<blockquote type=cite cite><font size=3>[I guess it might be if CSPF
has<br>
two 0-BW paths one through a restarting LSR and another through<br>
an operational one]...<br>
<br>
Alex.</blockquote>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]</font></html>

--=====================_27231316==_.ALT--

Delivery-date: Fri, 26 Apr 2002 13:15:56 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: TE metric and graceful restart
Date: Fri, 26 Apr 2002 16:15:04 -0400

Yakov,

  Here are my thoughts & comments w.r.t operation of the 
  Traffic Engineering Extensions to OSPF during OSPF 
  Hitless Restart:

  1. First of all, your suggestion might not fit well
     with draft draft-lefaucheur-te-metric-igp-01.txt.
     That is, just changing TE metric might help you to
     stop _some_ unwanted LSPs being setup in restart 
     period but not all. (example, LSPs that use IGP metric 
     in OSPF regular LSAs)
  
  2. If we change any of TE LSA contents and flood the 
     *Restart TE LSAs* to neighbor nodes, then there are 
     2 cases:
	
     (a) The neighbor might have accepted as a helper 
         node
     (b) The neighbor might have rejected (not at
         all received any OSPF-grace LSA etc - for so 
         many reasons I can think of)

   In the case (b), OSPF neighbor will simple flood the restart
   TE LSA into the domain. That is something what you are not
   intended in the below para:
  
   ***
   Neighbors of the restarting node should continue advertise the actual
   unreserved bandwidth on the TE links from the neighbors to that node.
   ***

  3. More over, I think this is a Re-optimization issue rather than
     a restart issue. So, IMHO, it is better not to flood the TE LSA
     (with BW 0 and Infinite Metric changes). 

	- We are expecting that Restart TE LSAs should not be
        flooded beyond neighbor nodes.
	- The new LSPs in the *grace* period will be rejected, or
        cranked back.
      - All those LSPs might take less specific TE path than
        the desired one.
      - If the LSRs are not supporting Adaptivity/Re-optimization
        might end-up with those LSPs hanging around.

  4. Actually, the LSP preventing in the grace period should
     be handled in signaling protocols and definitely not
     using back doors of routing protocols. RSVP and OSPF 
     Restart procedures are independent - one can restart OSPF
     with out letting RSVP going down. 

     So better to exchange the capability in RSVP and prevent
     any LSPs (even of B/W and/or OSPF TE metric are valid)

  5. Minor - it would be better to add/move "Implications 
     on Graceful Restart" section 
     to draft
       draft-ietf-ccamp-gmpls-routing-04.txt
     from draft
       draft-ietf-ccamp-ospf-gmpls-extensions-06.txt

     Because OSPF hitless restart draft is pointing
     to the draft-ietf-ccamp-gmpls-routing-04.txt

--
Venkata.

-> Folks,
-> 
-> It was suggested to set the TE metric to infinity during graceful
-> restart (both for ISIS and OSPF). 
-> 
-> Any objections to this suggestion ???
-> 
-> Yakov.
-> 

Delivery-date: Fri, 26 Apr 2002 13:00:49 -0700
Date: Fri, 26 Apr 2002 13:00:13 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Don Fedyk" <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart

Don,

  Would you care to elaborate more, please?
  Specifically, what do you think is wrong here
  and what would be the right way in your opinion.

  Thanks.

-- 
Alex

Friday, April 26, 2002, 12:12:09 PM, you wrote:
> Yakov 

> I have a question. Do you mean that a node that is restarting
> its routing view and learning from it's neighbors should mark 
> the TE metrics to local neighbors to infinity? I think that during 
> any graceful restart the TE metrics will not have a perfect view 
> and local path selections should be blocked but setting the metrics
> artificially to infinity seems like the wrong way to do this in my
> opinion. 

> Don

Delivery-date: Fri, 26 Apr 2002 12:59:42 -0700
Date: Fri, 26 Apr 2002 12:58:16 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Zafar Ali <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart

Zafar,

> One of the things that it'll do that it'll also prevent someone from using
> these links in the Path computation with "0" bandwidth (while the node in 
> question is restarting). In some scenarios, e.g., signaling for a backup 
> tunnel without no bandwidth reservation, a (remote) node may be interested 
> in Paths with "0" bandwidth.

I don't think there's anything in the OSPF & ISIS TE drafts that
prevents links with max metric from being used in CSPF, so
it is only more of discouragement, not prevention per se...
Is this still interesting? [I guess it might be if CSPF has
two 0-BW paths one through a restarting LSR and another through
an operational one]...

Alex.

Delivery-date: Fri, 26 Apr 2002 12:37:44 -0700
Date: Fri, 26 Apr 2002 15:36:28 -0400
To: Alex Zinin <[email-masked]>, Yakov Rekhter <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: TE metric and graceful restart
Cc: [email-masked]

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

At 11:54 AM 4/26/2002 -0700, Alex Zinin wrote:
>Yakov,
>
>   How does this improve the situation given that
>   unreserved BW of 0 is already announced?
>
>--
>Alex

Alex,

One of the things that it'll do that it'll also prevent someone from using 
these links in the Path computation with "0" bandwidth (while the node in 
question is restarting). In some scenarios, e.g., signaling for a backup 
tunnel without no bandwidth reservation, a (remote) node may be interested 
in Paths with "0" bandwidth.

Thanks

Regards... Zafar

>Thursday, April 25, 2002, 12:47:57 PM, you wrote:
> > Folks,
>
> > It was suggested to set the TE metric to infinity during graceful
> > restart (both for ISIS and OSPF).
>
> > Any objections to this suggestion ???
>
> > Yakov.
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]
--=====================_24572523==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 11:54 AM 4/26/2002 -0700, Alex Zinin wrote:<br>
<blockquote type=cite cite>Yakov,<br>
<br>
&nbsp; How does this improve the situation given that<br>
&nbsp; unreserved BW of 0 is already announced?<br>
<br>
-- <br>
Alex</font></blockquote><br>
Alex, <br>
<br>
One of the things that it'll do that it'll also prevent someone from
using these links in the Path computation with &quot;0&quot; bandwidth
(while the node in question is restarting). In some scenarios, e.g.,
signaling for a backup tunnel without no bandwidth reservation, a
(remote) node may be interested in Paths with &quot;0&quot; bandwidth.
<br>
<br>
<font size=3>Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite>Thursday, April 25, 2002, 12:47:57 PM, you
wrote:<br>
&gt; Folks,<br>
<br>
&gt; It was suggested to set the TE metric to infinity during
graceful<br>
&gt; restart (both for ISIS and OSPF). <br>
<br>
&gt; Any objections to this suggestion ???<br>
<br>
&gt; Yakov.</blockquote>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]</font></html>

--=====================_24572523==_.ALT--

Delivery-date: Fri, 26 Apr 2002 12:12:50 -0700
From: "Don Fedyk"<[email-masked]>
To: Alex Zinin <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: RE: TE metric and graceful restart
Date: Fri, 26 Apr 2002 15:12:09 -0400

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

------_=_NextPart_001_01C1ED56.433DDC64
Content-Type: text/plain;
	charset="ISO-8859-1"

Yakov 

I have a question. Do you mean that a node that is restarting
its routing view and learning from it's neighbors should mark 
the TE metrics to local neighbors to infinity? I think that during 
any graceful restart the TE metrics will not have a perfect view 
and local path selections should be blocked but setting the metrics
artificially to infinity seems like the wrong way to do this in my
opinion. 

Don

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 2:55 PM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: TE metric and graceful restart
> 
> 
> Yakov,
> 
>   How does this improve the situation given that
>   unreserved BW of 0 is already announced?
> 
> -- 
> Alex
> 
> Thursday, April 25, 2002, 12:47:57 PM, you wrote:
> > Folks,
> 
> > It was suggested to set the TE metric to infinity during graceful
> > restart (both for ISIS and OSPF). 
> 
> > Any objections to this suggestion ???
> 
> > Yakov.
> 
> 
> 

------_=_NextPart_001_01C1ED56.433DDC64
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: TE metric and graceful restart</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Yakov </FONT>
</P>

<P><FONT SIZE=2>I have a question. Do you mean that a node that is restarting</FONT>
<BR><FONT SIZE=2>its routing view and learning from it's neighbors should mark </FONT>
<BR><FONT SIZE=2>the TE metrics to local neighbors to infinity? I think that during </FONT>
<BR><FONT SIZE=2>any graceful restart the TE metrics will not have a perfect view </FONT>
<BR><FONT SIZE=2>and local path selections should be blocked but setting the metrics</FONT>
<BR><FONT SIZE=2>artificially to infinity seems like the wrong way to do this in my</FONT>
<BR><FONT SIZE=2>opinion. </FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Alex Zinin [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, April 26, 2002 2:55 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Yakov Rekhter</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: TE metric and graceful restart</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yakov,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; How does this improve the situation given that</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; unreserved BW of 0 is already announced?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Alex</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thursday, April 25, 2002, 12:47:57 PM, you wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Folks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It was suggested to set the TE metric to infinity during graceful</FONT>
<BR><FONT SIZE=2>&gt; &gt; restart (both for ISIS and OSPF). </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Any objections to this suggestion ???</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Yakov.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1ED56.433DDC64--

Delivery-date: Fri, 26 Apr 2002 11:56:35 -0700
Date: Fri, 26 Apr 2002 11:54:41 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: [email-masked]
Subject: Re: TE metric and graceful restart

Yakov,

  How does this improve the situation given that
  unreserved BW of 0 is already announced?

-- 
Alex

Thursday, April 25, 2002, 12:47:57 PM, you wrote:
> Folks,

> It was suggested to set the TE metric to infinity during graceful
> restart (both for ISIS and OSPF). 

> Any objections to this suggestion ???

> Yakov.

Delivery-date: Fri, 26 Apr 2002 10:34:58 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Manoj Agiwal' <[email-masked]>, "Gmpls-Ops (E-mail)" <[email-masked]>, [email-masked], "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: VT Switching
Date: Fri, 26 Apr 2002 17:16:39 +0200

[ post by non-subscriber ]

Hello Manoj,

> Can I specify a VT by a single label , or  I need to encode this
information ( STS->VTG->VT) in some proprietary format which is
understandable by neighbouring nodes .

(There is no proprietary format to use, the label format supports all
cases.)

It depends on your logical topology. You could have a VTG (virtual) link and
in that case the label would be relative to that link (highest part non
significant). At the other extreme you could specify the full label. This
has nothing to do with the monitoring or with the allocation of higher-order
signals. Up to you to decide what you want to do. Since a label is always
interpreted in a particular context, this context will allow you to know how
it must be encoded.

Kind regards,

Eric

-----Original Message-----
From: Manoj Agiwal [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 AM
To: Gmpls-Ops (E-mail); [email-masked]; mpls@UU. NET (E-mail)
Subject: VT Switching

[ post by non-subscriber ]

Hi ,
      I want to estanlish a DS1 trail , using GMPLS signaling .

      The DS1 will  get mapped to a single VT in a VTG , and will get
transferred to other end 
      using VT Switching .

      All the nodes particpating in the connection will do VT switching .

      Can I specify a VT by a single label , or  I need to encode this
information ( STS->VTG->VT) in some
      proprietary format which is understandable by neighbouring nodes .

      I would be interested in knowing how people do this .

Regards ,
Manoj

------- end of forwarded message -------

Delivery-date: Fri, 26 Apr 2002 07:32:26 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: <[email-masked]>
Subject: Suggested label and Label Set tlv doubts
Date: Fri, 26 Apr 2002 20:02:39 +1000
Organization: wipro technologies

This is a multi-part message in MIME format.

------=_NextPartTM-000-ec5d3c55-5914-11d6-af80-0080c8048dde
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0016_01C1ED5D.516B1C00"

------=_NextPart_000_0016_01C1ED5D.516B1C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hai ,

            Since the suggested label and label set tlvs are optional in =
a Generalized label request, how do i handle
            a situation when someone has sent a request with both the =
TLVs present ??
   =20
            Do label set tlv has higher priority over suggested label in =
which case i can go ahead ignoring the=20
            suggested label and try to satisfy the request with label =
set as constraint on label or do i need to=20
            satisfy the suggested label constraint since my upstream has =
sent me the suggested label with=20
            an assumption that it will be satisfied and moreover since =
it would have created a crossconnect also.
            And ignore the label set tlv.

            I understand that this is a scenario where upstream is =
malfunctioning but that needs to be handled for sure and
            cannot be ignored

            Please do clarify things ...

thanks=20
venkat

------=_NextPart_000_0016_01C1ED5D.516B1C00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hai ,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Since=20
the suggested label and label set tlvs are optional in a Generalized =
label=20
request, how do i handle</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; a situation when someone has sent a request with both =
the=20
TLVs present ??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Do label set tlv has higher priority over suggested =
label in=20
which case i can go ahead ignoring the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; suggested label and try to satisfy the request with =
label set=20
as constraint on label or do i need to </FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;satisfy=20
the suggested label constraint since my upstream has sent me the =
suggested label=20
with </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; an assumption that it will be satisfied and moreover =
since it=20
would have created a crossconnect also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; And ignore the label set tlv.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; I understand that this is a scenario where upstream =
is=20
malfunctioning but that needs to be handled for sure and</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; cannot=20
be ignored</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Please do clarify things ...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>venkat</FONT></DIV></BODY></HTML>

------=_NextPart_000_0016_01C1ED5D.516B1C00--

------=_NextPartTM-000-ec5d3c55-5914-11d6-af80-0080c8048dde
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-ec5d3c55-5914-11d6-af80-0080c8048dde--

Delivery-date: Fri, 26 Apr 2002 06:45:17 -0700
Cc: "Gmpls-Ops (E-mail)" <[email-masked]>, [email-masked], "mpls@UU. NET (E-mail)" <[email-masked]>
Date: Fri, 26 Apr 2002 15:42:42 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Manoj Agiwal <[email-masked]>
Original-CC: "Gmpls-Ops (E-mail)" <[email-masked]>, [email-masked], "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: VT Switching

Hello Manoj,

What do you mean with 'neighbouring nodes' ?
In my mind, VT switching matrices are neighbours if they are connected
via some STS trail. This is just like STS switching matrices are neighbours
if they are connected via some OC-n trail.

See my proposal in
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
to find out how VT switching matrices discover each other as neighbours.

Hopefully the CCAMP WG will agree to add something like this in the LMP
draft...

Greetings,

Michiel

Manoj Agiwal wrote:
> 
> [ post by non-subscriber ]
> 
> Hi ,
>       I want to estanlish a DS1 trail , using GMPLS signaling .
> 
>       The DS1 will  get mapped to a single VT in a VTG , and will get
> transferred to other end
>       using VT Switching .
> 
>       All the nodes particpating in the connection will do VT switching .
> 
>       Can I specify a VT by a single label , or  I need to encode this
> information ( STS->VTG->VT) in some
>       proprietary format which is understandable by neighbouring nodes .
> 
>       I would be interested in knowing how people do this .
> 
> Regards ,
> Manoj
> 
> 
> 
> 
> 
> 
> ------- end of forwarded message -------

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 26 Apr 2002 05:44:30 -0700
From: Manoj Agiwal <[email-masked]>
To: "''Ccamp (E-mail)'" <[email-masked]>
Cc: "'Gmpls-Ops (E-mail)'" <[email-masked]>,  "'mpls@UU. NET (E-mail)'" <[email-masked]>
Subject: GMPLS LSP Enc Type
Date: Fri, 26 Apr 2002 15:49:36 +0530

The distinction between the LSP Enc type and G-PID is not very clear. For
example if we map DS3 into STS1,
do we use LSP Enc type as SONET or ANSI PDH. Similarly if we are mapping
Ethernet into SONET frames then LSP Enc type should be SONET or Ethernet.
Second Question is if I map Ethernet frames into SPE using LAPS, What value
should G-PID carry. There are two values defined there, one for Ethernet and
other for LAPS.

Delivery-date: Fri, 26 Apr 2002 03:14:14 -0700
Cc: [email-masked]
Date: Fri, 26 Apr 2002 12:10:17 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Question on LMP.

Hello Zafar,

Please allow me to summarize my understanding of our discussion thus
far.

LMP's "control channel management"

- Is an extra, new protocol on top of an existing IP network.
  That is what I understand when Jonathan writes "You could certainly
  create an LMP control channel through a DCN network. In fact, this
  is probably the preferred configuration."
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html

- Needs careful setting of hello frequency.
  This is based on your comment: "LMP Hellos should be faster than RSVP
  Hellos or the mechanism used to detect signalling channel failure.
  Similarly, LMP Hello frequency should be greater than IGP hello frequen=
cy,
  so that the optical network can make "conscious" decision on the contro=
l
  channel failure, before having an adverse affect on the IGP adjacencies=
 at L3."
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html

- Provide a fast recovering transport mechanism for "signalling channels"=

  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html

Furthermore, there is a need to route packets through a network consistin=
g
of "signalling channels": the RSVP-TE "notify message" is sent between
non-adjacent (at transmission plane) nodes in case it is "encapsulated
in a new IP header whose destination is equal to the target IP address."
[RSVP-TE, section 4.3]

So in other words, the proposal is to create an extra "network layer"
(OSI terminology) consisting of "signalling channels". These "signalling
channels" make use of underlying "control channels" which again can make
use of any generic network layer (e.g. DCN). Correct ?

I agree with you that we need to carefully look at the "hello" frequencie=
s
of these network layers. Probably some consideration is also needed for
hello-timers on datalink layer and hold-off timers at transport layer.

All together, my feeling is that this is getting quite complex.

Are we sure we want to go in this direction ? Can't we simply remove
the whole "control channel management" mechanism and define "control
channel" as follows:
  control channel =3D a facility that interconnects two switching neighbo=
urs
  at the transmission plane for the purpose of exchanging control message=
s.
  This facility can be in-band or out-of-band; point-to-point or multi-po=
int.
If we would accept this definition, a DCN network (or better: SCN network=
)
can be an implementation to have control channels between all neighbourin=
g
nodes at the transmission plane.

If we have to go on discussing "control channel management", I think we
still have the following open questions:
- why does control channel management need to be fast
- is control channel management fast

On your email:

> I don't see if we can cover all cases of control channel failure detect=
ion
> after removing this functionality from LMP (e.g., the case of routed co=
ntrol
> channels or control channels where L2 failure detection is not feasible=
).

Hopefully someone on this mailing list can show us a case in which a stan=
dard
IP network is not sufficient for the control plane...

> LMP will be using UDP, as indicated in an earlier email from Jonathan.

Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask=
 if
we could add neighbour discovery in LMP and to get clarity on the use of
"control channel management". Guess I was somewhat naive to think that th=
at
could easily be settled....

> > Indeed. In some cases L2 detects the failure, in other cases L3 detec=
ts
> > the failure. Still confused as to why we can't stick to standard L3
> > mechanisms to detect the failure...
> =

> Can you please elaborate on what "other" L3 mechanisms you're referring=
 to
> here? How would you cover the case of an IP routed control channel?

I did not speak about "other" L3 mechanisms. Just standard L3 mechanisms.=

> I think the WG has already agreed upon the control channel management
> procedure within the scope of LMP. I am not sure what is the value of
> this discussion at this point. I'll let some one else comment on it.

Personally, I found our discussion very useful. Thanks for the to-the-poi=
nt
answers !

Best regards,

Michiel

Zafar Ali wrote:
> =

> Hi Michiel:
> =

> Please see comments in-lined.
> =

> Thanks
> =

> Regards... Zafar
> =

> At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:
> =

> > Hello Zafar,
> >
> >
> > > > I'm still confused as to why standard network layer mechanisms wo=
uld not
> > > > be sufficient.
> > >
> > > I think this answer depends on how we define sufficient;-)
> >
> > As control channel management is a mandatory part of LMP, I would def=
ine
> > "sufficient" as "minimally needed to run LMP" or maybe "minimally nee=
ded
> > to run GMPLS".
> =

> I don't see if we can cover all cases of control channel failure detect=
ion after removing this functionality from LMP (e.g., the case of routed =
control channels or control channels where L2 failure detection is not fe=
asible). Please note that control channel failure detection is currently =
a
> requirement for the GMPLS framework, which is already agreed upon, AFAI=
K.
> =

> > > LMP control channel management brings some features into picture, e=
=2Eg.,
> > > when we=92ve hidden control channels, how can we guarantee that the=
 neighbor
> > > is listening to the channel we=92re sending your control messages t=
o? With
> > > the configuration handshake, LMP guarantees that the two ends are r=
eady
> > > to exchange messages on the control channel in question.
> >
> > I guess control messages will use either TCP, UDP or IP. Correct ?
> =

> LMP will be using UDP, as indicated in an earlier email from Jonathan.
> =

> > In case of TCP, I'm assuming TCP's connection establishment phase tak=
es
> > care that the neighbour is listening.
> >
> > In case the control messages are sent using UDP or IP, I agree that t=
he
> > application has to make sure that the neighbour is listening. For the=

> > LMP control messages this seems no problem as they are acknowledged
> > anyway by LMP (e.g. linkSummaryAck for the linkSummary message). The
> > application can then simply resent the message until it receives a
> > '(N)Ack'.
> =

> Yes, also this is because LMP does not assume a reliable transport for =
the control traffic (over the control channel).
> =

> > > Similarly, it provides a way by which failure on a routed control
> > > channel (control channel is not bound to a physical interface) or a=

> > > control channel where L2 cannot detect the failure.
> >
> > Indeed. In some cases L2 detects the failure, in other cases L3 detec=
ts
> > the failure. Still confused as to why we can't stick to standard L3
> > mechanisms to detect the failure...
> =

> Can you please elaborate on what "other" L3 mechanisms you're referring=
 to here? How would you cover the case of an IP routed control channel?
> =

> > > Without LMP control channel management, how you would suggest
> > > management and health check for such control channels? Skipping
> > > such tests will IMO lead to a more ad hoc procedures/ protocols.
> >
> > See above.
> > For inter operability reasons, we could specify which mechanism has
> > to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms
> > (like MPLS protection, ML-PPP, ...) are then optional.
> >
> >
> > > Signaling channel is a term I used to specify the following:
> > > Signaling channel is the logical channel over which signaling
> > > (say RSVP-TE) messages are exchanged between RSVP peering entities.=

> > > The signaling channel is realized using the collection of all
> > > control channels between the two RSVP peers.
> > > A signaling channel failure could be the result of the concurrent
> > > failure of all control channels or the failure of one of the peerin=
g
> > > signaling entities or one of the peering nodes. Hence, signaling
> > > channel failure is different than failure of all control channels.
> > >
> > > Using the above mentioned definition, a nodal failure always imply
> > > the failure of the signaling channel as well as control channels.
> > > However, failure of the last control channel does not imply a nodal=

> > > failure. For the sake of completeness, a signaling channel failure
> > > could be due to failure of the
> > > peering RSVP process or due to the neighbor node failure. The
> > > draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
> > > failure to cover both cases: i.e., the case where peering RSVP
> > > entity restarts or the entire node fails. In either case, non-stop
> > > forwarding is assumed. In short, failure of
> > > the last control channel is different from the nodal failures.
> >
> > Thanks for the definitions !
> >
> > Just to check: a signalling channel failure is different from a nodal=

> > failure. A nodal failure implies a signalling channel failure, but no=
t
> > the other way around. Correct ?
> =

> Yes, failure of a peering signaling process also leads to signaling cha=
nnel failure.
> But, the actions taken in the restart procedure are the same, for the o=
bvious reasons.
> =

> > In these definitions, how would an RSVP-TE "notify message" be sent
> > between non-adjacent (at transmission plane) nodes in case it is
> > "encapsulated in a new IP header whose destination is equal to
> > the target IP address." [RSVP-TE, section 4.3] ? Is it routed
> > over a series of signalling channels ? By which routing protocol ?
> >
> >
> > > In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery
> > > procedure treats nodal failure and control channel failure differen=
tly
> > > (please see above for how they are related to the failure of the
> > > individual processes).
> > >
> > > I think what you=92re proposing is that we don=92t need to distingu=
ish
> > > between the two and we can always apply the signaling channel failu=
re
> > > (draft uses the term nodal failure to refer to a more general case)=

> > > mechanisms, even in the case of control channel failure?
> >
> > My proposal would be to use non-GMPLS specific mechanisms to route
> > control packets to the intended destination.
> >
> >
> > > Clearly in the absence of LMP, failure of all control channels can
> > > only be detected by the signaling layer, hence will be treated as
> > > nodal failures. However, with failure detection on the control chan=
nel,
> > > we can do a better job in recovering.
> >
> > Could we agree that the whole "control channel management" mechanism
> > is only for faster recovery of the control plane ? The idea would be
> > that failure of one control channel does not change the topology of
> > the control plane as the associated signalling channel does not get
> > affected.
> >
> > If we could agree on this understanding, I would still opt for non-
> > GMPLS specific mechanisms.
> =

> I think the WG has already agreed upon the control channel management p=
rocedure within the scope of LMP. I am not sure what is the value of this=
 discussion at this point. I'll let some one else comment on it.
> =

> <snip>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Zafar Ali
> Cisco Systems
> (734) 276-2459
> 100 S Main St. #200
> Ann Arbor, MI 48104.
> email: [email-masked]

-- =

+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Thu, 25 Apr 2002 12:50:21 -0700
To: [email-masked]
Subject: TE metric and graceful restart
Date: Thu, 25 Apr 2002 12:47:57 -0700
From: Yakov Rekhter <[email-masked]>

Folks,

It was suggested to set the TE metric to infinity during graceful
restart (both for ISIS and OSPF). 

Any objections to this suggestion ???

Yakov.

Delivery-date: Thu, 25 Apr 2002 10:25:52 -0700
Date: Thu, 25 Apr 2002 13:23:18 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: [email-masked]

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

Hi Michiel:

Please see comments in-lined.

Thanks

Regards... Zafar

At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:
>Hello Zafar,
>
>
> > > I'm still confused as to why standard network layer mechanisms would not
> > > be sufficient.
> >
> > I think this answer depends on how we define sufficient;-)
>
>As control channel management is a mandatory part of LMP, I would define
>"sufficient" as "minimally needed to run LMP" or maybe "minimally needed
>to run GMPLS".

I don't see if we can cover all cases of control channel failure detection 
after removing this functionality from LMP (e.g., the case of routed 
control channels or control channels where L2 failure detection is not 
feasible). Please note that control channel failure detection is currently 
a requirement for the GMPLS framework, which is already agreed upon, AFAIK.

> > LMP control channel management brings some features into picture, e.g.,
> > when we've hidden control channels, how can we guarantee that the neighbor
> > is listening to the channel we're sending your control messages to? With
> > the configuration handshake, LMP guarantees that the two ends are ready
> > to exchange messages on the control channel in question.
>
>I guess control messages will use either TCP, UDP or IP. Correct ?

LMP will be using UDP, as indicated in an earlier email from Jonathan.

>In case of TCP, I'm assuming TCP's connection establishment phase takes
>care that the neighbour is listening.
>
>In case the control messages are sent using UDP or IP, I agree that the
>application has to make sure that the neighbour is listening. For the
>LMP control messages this seems no problem as they are acknowledged
>anyway by LMP (e.g. linkSummaryAck for the linkSummary message). The
>application can then simply resent the message until it receives a
>'(N)Ack'.

Yes, also this is because LMP does not assume a reliable transport for the 
control traffic (over the control channel).

> > Similarly, it provides a way by which failure on a routed control
> > channel (control channel is not bound to a physical interface) or a
> > control channel where L2 cannot detect the failure.
>
>Indeed. In some cases L2 detects the failure, in other cases L3 detects
>the failure. Still confused as to why we can't stick to standard L3
>mechanisms to detect the failure...

Can you please elaborate on what "other" L3 mechanisms you're referring to 
here? How would you cover the case of an IP routed control channel?

> > Without LMP control channel management, how you would suggest
> > management and health check for such control channels? Skipping
> > such tests will IMO lead to a more ad hoc procedures/ protocols.
>
>See above.
>For inter operability reasons, we could specify which mechanism has
>to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms
>(like MPLS protection, ML-PPP, ...) are then optional.
>
>
> > Signaling channel is a term I used to specify the following:
> > Signaling channel is the logical channel over which signaling
> > (say RSVP-TE) messages are exchanged between RSVP peering entities.
> > The signaling channel is realized using the collection of all
> > control channels between the two RSVP peers.
> > A signaling channel failure could be the result of the concurrent
> > failure of all control channels or the failure of one of the peering
> > signaling entities or one of the peering nodes. Hence, signaling
> > channel failure is different than failure of all control channels.
> >
> > Using the above mentioned definition, a nodal failure always imply
> > the failure of the signaling channel as well as control channels.
> > However, failure of the last control channel does not imply a nodal
> > failure. For the sake of completeness, a signaling channel failure
> > could be due to failure of the
> > peering RSVP process or due to the neighbor node failure. The
> > draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
> > failure to cover both cases: i.e., the case where peering RSVP
> > entity restarts or the entire node fails. In either case, non-stop
> > forwarding is assumed. In short, failure of
> > the last control channel is different from the nodal failures.
>
>Thanks for the definitions !
>
>Just to check: a signalling channel failure is different from a nodal
>failure. A nodal failure implies a signalling channel failure, but not
>the other way around. Correct ?

Yes, failure of a peering signaling process also leads to signaling channel 
failure.
But, the actions taken in the restart procedure are the same, for the 
obvious reasons.

>In these definitions, how would an RSVP-TE "notify message" be sent
>between non-adjacent (at transmission plane) nodes in case it is
>"encapsulated in a new IP header whose destination is equal to
>the target IP address." [RSVP-TE, section 4.3] ? Is it routed
>over a series of signalling channels ? By which routing protocol ?
>
>
> > In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery
> > procedure treats nodal failure and control channel failure differently
> > (please see above for how they are related to the failure of the
> > individual processes).
> >
> > I think what you're proposing is that we don't need to distinguish
> > between the two and we can always apply the signaling channel failure
> > (draft uses the term nodal failure to refer to a more general case)
> > mechanisms, even in the case of control channel failure?
>
>My proposal would be to use non-GMPLS specific mechanisms to route
>control packets to the intended destination.
>
>
> > Clearly in the absence of LMP, failure of all control channels can
> > only be detected by the signaling layer, hence will be treated as
> > nodal failures. However, with failure detection on the control channel,
> > we can do a better job in recovering.
>
>Could we agree that the whole "control channel management" mechanism
>is only for faster recovery of the control plane ? The idea would be
>that failure of one control channel does not change the topology of
>the control plane as the associated signalling channel does not get
>affected.
>
>If we could agree on this understanding, I would still opt for non-
>GMPLS specific mechanisms.

I think the WG has already agreed upon the control channel management 
procedure within the scope of LMP. I am not sure what is the value of this 
discussion at this point. I'll let some one else comment on it.

>Best regards,
>Michiel
<snip>
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

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

<html>
<font size=3>Hi Michiel:<br>
<br>
Please see comments in-lined.<br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=cite cite>Hello Zafar,<br>
<br>
<br>
&gt; &gt; I'm still confused as to why standard network layer mechanisms
would not<br>
&gt; &gt; be sufficient.<br>
&gt; <br>
&gt; I think this answer depends on how we define sufficient;-)<br>
<br>
As control channel management is a mandatory part of LMP, I would
define<br>
&quot;sufficient&quot; as &quot;minimally needed to run LMP&quot; or
maybe &quot;minimally needed<br>
to run GMPLS&quot;.</font></blockquote><br>
<font face="Arial, Helvetica" size=3>I don't see if we can cover all
cases of control channel failure detection after removing this
functionality from LMP (e.g., the case of routed control channels or
control channels where L2 failure detection is not feasible). Please note
that control channel failure detection is currently a requirement for the
GMPLS framework, which is already agreed upon, AFAIK. <br>
<br>
<br>
<br>
</font><blockquote type=cite cite>&gt; LMP control channel management
brings some features into picture, e.g.,<br>
&gt; when we’ve hidden control channels, how can we guarantee that the
neighbor<br>
&gt; is listening to the channel we’re sending your control messages to?
With<br>
&gt; the configuration handshake, LMP guarantees that the two ends are
ready<br>
&gt; to exchange messages on the control channel in question.<br>
<br>
I guess control messages will use either TCP, UDP or IP. Correct
?</blockquote><br>
<font face="Arial, Helvetica" size=3>LMP will be using UDP, as indicated
in an earlier email from Jonathan.<br>
<br>
<br>
</font><blockquote type=cite cite>In case of TCP, I'm assuming TCP's
connection establishment phase takes<br>
care that the neighbour is listening.<br>
<br>
In case the control messages are sent using UDP or IP, I agree that
the<br>
application has to make sure that the neighbour is listening. For
the<br>
LMP control messages this seems no problem as they are acknowledged<br>
anyway by LMP (e.g. linkSummaryAck for the linkSummary message). 
The<br>
application can then simply resent the message until it receives a<br>
'(N)Ack'.</blockquote><br>
Yes, also this is because LMP does not assume a reliable transport for
the control traffic (over the control channel).&nbsp; <br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>&gt; Similarly, it provides a way
by which failure on a routed control<br>
&gt; channel (control channel is not bound to a physical interface) or
a<br>
&gt; control channel where L2 cannot detect the failure.<br>
<br>
Indeed. In some cases L2 detects the failure, in other cases L3
detects<br>
the failure. Still confused as to why we can't stick to standard L3<br>
mechanisms to detect the failure...</font></blockquote><br>
<font face="Arial, Helvetica" size=3>Can you please elaborate on what
&quot;other&quot; L3 mechanisms you're referring to here? How would you
cover the case of an IP routed control channel? <br>
<br>
<br>
<br>
</font><blockquote type=cite cite>&gt; Without LMP control channel
management, how you would suggest<br>
&gt; management and health check for such control channels? 
Skipping<br>
&gt; such tests will IMO lead to a more ad hoc procedures/
protocols.<br>
<br>
See above.<br>
For inter operability reasons, we could specify which mechanism has<br>
to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms<br>
(like MPLS protection, ML-PPP, ...) are then optional.<br>
<br>
<br>
&gt; Signaling channel is a term I used to specify the following:<br>
&gt; Signaling channel is the logical channel over which signaling<br>
&gt; (say RSVP-TE) messages are exchanged between RSVP peering
entities.<br>
&gt; The signaling channel is realized using the collection of all<br>
&gt; control channels between the two RSVP peers.<br>
&gt; A signaling channel failure could be the result of the
concurrent<br>
&gt; failure of all control channels or the failure of one of the
peering<br>
&gt; signaling entities or one of the peering nodes. Hence,
signaling<br>
&gt; channel failure is different than failure of all control
channels.<br>
&gt; <br>
&gt; Using the above mentioned definition, a nodal failure always
imply<br>
&gt; the failure of the signaling channel as well as control
channels.<br>
&gt; However, failure of the last control channel does not imply a
nodal<br>
&gt; failure. For the sake of completeness, a signaling channel
failure<br>
&gt; could be due to failure of the<br>
&gt; peering RSVP process or due to the neighbor node failure. The<br>
&gt; draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal<br>
&gt; failure to cover both cases: i.e., the case where peering RSVP<br>
&gt; entity restarts or the entire node fails. In either case,
non-stop<br>
&gt; forwarding is assumed. In short, failure of<br>
&gt; the last control channel is different from the nodal failures.<br>
<br>
Thanks for the definitions !<br>
<br>
Just to check: a signalling channel failure is different from a
nodal<br>
failure. A nodal failure implies a signalling channel failure, but
not<br>
the other way around. Correct ?</blockquote><br>
<font face="Arial, Helvetica" size=3>Yes, failure of a peering signaling
process also leads to signaling channel failure. <br>
But, the actions taken in the restart procedure are the same, for the
obvious reasons. <br>
<br>
<br>
</font><blockquote type=cite cite>In these definitions, how would an
RSVP-TE &quot;notify message&quot; be sent<br>
between non-adjacent (at transmission plane) nodes in case it is<br>
&quot;encapsulated in a new IP header whose destination is equal to<br>
the target IP address.&quot; [RSVP-TE, section 4.3] ? Is it routed<br>
over a series of signalling channels ? By which routing protocol ?<br>
<br>
<br>
&gt; In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP
recovery<br>
&gt; procedure treats nodal failure and control channel failure
differently<br>
&gt; (please see above for how they are related to the failure of
the<br>
&gt; individual processes).<br>
&gt; <br>
&gt; I think what you’re proposing is that we don’t need to
distinguish<br>
&gt; between the two and we can always apply the signaling channel
failure<br>
&gt; (draft uses the term nodal failure to refer to a more general
case)<br>
&gt; mechanisms, even in the case of control channel failure?<br>
<br>
My proposal would be to use non-GMPLS specific mechanisms to route<br>
control packets to the intended destination.<br>
<br>
<br>
&gt; Clearly in the absence of LMP, failure of all control channels
can<br>
&gt; only be detected by the signaling layer, hence will be treated
as<br>
&gt; nodal failures. However, with failure detection on the control
channel,<br>
&gt; we can do a better job in recovering.<br>
<br>
Could we agree that the whole &quot;control channel management&quot;
mechanism<br>
is only for faster recovery of the control plane ? The idea would 
be<br>
that failure of one control channel does not change the topology of<br>
the control plane as the associated signalling channel does not get<br>
affected.<br>
<br>
If we could agree on this understanding, I would still opt for non-<br>
GMPLS specific mechanisms.</blockquote><br>
I think the WG has already agreed upon the control channel management
procedure within the scope of LMP. I am not sure what is the value of
this discussion at this point. I'll let some one else comment on it.
<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Best regards,<br>
<br>
Michiel<br>
<br>
</blockquote>&lt;snip&gt;<br>
===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: [email-masked]<br>
</font></html>

--=====================_9785130==_.ALT--

Delivery-date: Thu, 25 Apr 2002 09:17:23 -0700
From: Manoj Agiwal <[email-masked]>
To: "Gmpls-Ops (E-mail)" <[email-masked]>, <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: VT Switching
Date: Thu, 25 Apr 2002 13:40:13 +0530

[ post by non-subscriber ]

Hi ,
      I want to estanlish a DS1 trail , using GMPLS signaling .

      The DS1 will  get mapped to a single VT in a VTG , and will get
transferred to other end 
      using VT Switching .

      All the nodes particpating in the connection will do VT switching .

      Can I specify a VT by a single label , or  I need to encode this
information ( STS->VTG->VT) in some
      proprietary format which is understandable by neighbouring nodes .

      I would be interested in knowing how people do this .

Regards ,
Manoj

------- end of forwarded message -------

Delivery-date: Thu, 25 Apr 2002 06:01:07 -0700
Cc: [email-masked]
Date: Thu, 25 Apr 2002 14:56:45 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Question on LMP.

Hello Zafar,

> > I'm still confused as to why standard network layer mechanisms would =
not
> > be sufficient.
> =

> I think this answer depends on how we define sufficient;-)

As control channel management is a mandatory part of LMP, I would define
"sufficient" as "minimally needed to run LMP" or maybe "minimally needed
to run GMPLS".

> LMP control channel management brings some features into picture, e.g.,=

> when we=92ve hidden control channels, how can we guarantee that the nei=
ghbor
> is listening to the channel we=92re sending your control messages to? W=
ith
> the configuration handshake, LMP guarantees that the two ends are ready=

> to exchange messages on the control channel in question.

I guess control messages will use either TCP, UDP or IP. Correct ?

In case of TCP, I'm assuming TCP's connection establishment phase takes
care that the neighbour is listening.

In case the control messages are sent using UDP or IP, I agree that the
application has to make sure that the neighbour is listening. For the
LMP control messages this seems no problem as they are acknowledged
anyway by LMP (e.g. linkSummaryAck for the linkSummary message). The
application can then simply resent the message until it receives a
'(N)Ack'.

> Similarly, it provides a way by which failure on a routed control
> channel (control channel is not bound to a physical interface) or a
> control channel where L2 cannot detect the failure.

Indeed. In some cases L2 detects the failure, in other cases L3 detects
the failure. Still confused as to why we can't stick to standard L3
mechanisms to detect the failure...

> Without LMP control channel management, how you would suggest
> management and health check for such control channels? Skipping
> such tests will IMO lead to a more ad hoc procedures/ protocols.

See above.
For inter operability reasons, we could specify which mechanism has
to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms
(like MPLS protection, ML-PPP, ...) are then optional.

> Signaling channel is a term I used to specify the following:
> Signaling channel is the logical channel over which signaling
> (say RSVP-TE) messages are exchanged between RSVP peering entities.
> The signaling channel is realized using the collection of all
> control channels between the two RSVP peers.
> A signaling channel failure could be the result of the concurrent
> failure of all control channels or the failure of one of the peering
> signaling entities or one of the peering nodes. Hence, signaling
> channel failure is different than failure of all control channels.
> =

> Using the above mentioned definition, a nodal failure always imply
> the failure of the signaling channel as well as control channels.
> However, failure of the last control channel does not imply a nodal
> failure. For the sake of completeness, a signaling channel failure
> could be due to failure of the
> peering RSVP process or due to the neighbor node failure. The
> draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
> failure to cover both cases: i.e., the case where peering RSVP
> entity restarts or the entire node fails. In either case, non-stop
> forwarding is assumed. In short, failure of
> the last control channel is different from the nodal failures.

Thanks for the definitions !

Just to check: a signalling channel failure is different from a nodal
failure. A nodal failure implies a signalling channel failure, but not
the other way around. Correct ?

In these definitions, how would an RSVP-TE "notify message" be sent
between non-adjacent (at transmission plane) nodes in case it is
"encapsulated in a new IP header whose destination is equal to
the target IP address." [RSVP-TE, section 4.3] ? Is it routed
over a series of signalling channels ? By which routing protocol ?

> In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery
> procedure treats nodal failure and control channel failure differently
> (please see above for how they are related to the failure of the
> individual processes).
> =

> I think what you=92re proposing is that we don=92t need to distinguish
> between the two and we can always apply the signaling channel failure
> (draft uses the term nodal failure to refer to a more general case)
> mechanisms, even in the case of control channel failure?

My proposal would be to use non-GMPLS specific mechanisms to route
control packets to the intended destination.

> Clearly in the absence of LMP, failure of all control channels can
> only be detected by the signaling layer, hence will be treated as
> nodal failures. However, with failure detection on the control channel,=

> we can do a better job in recovering.

Could we agree that the whole "control channel management" mechanism
is only for faster recovery of the control plane ? The idea would be
that failure of one control channel does not change the topology of
the control plane as the associated signalling channel does not get
affected.

If we could agree on this understanding, I would still opt for non-
GMPLS specific mechanisms.

Best regards,

Michiel

Zafar Ali wrote:
> =

> Hi Michiel,
> =

> Please see comments in-lined.
> =

> Thanks
> =

> Regards=85 Zafar
> =

> At 11:47 AM 4/24/2002 +0200, Michiel van Everdingen wrote:
> =

> > Hello Zafar,
> >
> >
> > > No, I think the main source of confusion is that LMP Hellos are NOT=
 the
> > > only thing that is part of the control channel management.
> >
> > What else ?
> > Control Channel Management seems to only set up a communication mecha=
nism
> > (in the control plane) between two nodes that are neighbours at the
> > transmission plane, i.e. that are neighbours regarding dataLinks.
> > Also, if I look at the definition of the config messages, I can only =
find
> > parameters that deal with this communication mechanism.
> >
> > I'm still confused as to why standard network layer mechanisms would =
not
> > be sufficient.
> =

> I think this answer depends on how we define sufficient;-) LMP control =
channel management brings some features into picture, e.g., when we=92ve =
hidden control channels, how can we guarantee that the neighbor is listen=
ing to the channel we=92re sending your control messages to? With the con=
figuration
> handshake, LMP guarantees that the two ends are ready to exchange messa=
ges on the control channel in question.
> =

> Similarly, it provides a way by which failure on a routed control chann=
el (control channel is not bound to a physical interface) or a control ch=
annel where L2 cannot detect the failure. Without LMP control channel man=
agement, how you would suggest management and health check for such contr=
ol
> channels? Skipping such tests will IMO lead to a more ad hoc procedures=
/ protocols.
> =

> > > > Is there a need to distinguish between signalling channels and co=
ntrol
> > > > channels ?
> > >
> > > Yes, e.g., RSVP recovery procedure differentiate between the contro=
l
> > > channel failures and the signalling channel (Nodal) failure.
> >
> > My understanding is that a nodal failure "relates to the case where a=
 node
> > losses its control state (e.g., after a restart) but does not loose i=
ts data
> > forwarding state."
> >
> > A nodal failure is therefore something else than a failure in a commu=
nication
> > mechanism. Correct ?
> >
> > Why do you relate nodal failure with the failure of a communication
> > mechanism (the 'signalling channel') ?
> =

> Signaling channel is a term I used to specify the following: Signaling =
channel is the logical channel over which signaling (say RSVP-TE) message=
s are exchanged between RSVP peering entities. The signaling channel is r=
ealized using the collection of all control channels between the two RSVP=
 peers.
> A signaling channel failure could be the result of the concurrent failu=
re of all control channels or the failure of one of the peering signaling=
 entities or one of the peering nodes. Hence, signaling channel failure i=
s different than failure of all control channels.
> =

> Using the above mentioned definition, a nodal failure always imply the =
failure of the signaling channel as well as control channels. However, fa=
ilure of the last control channel does not imply a nodal failure. For the=
 sake of completeness, a signaling channel failure could be due to failur=
e of the
> peering RSVP process or due to the neighbor node failure. The draft-iet=
f-mpls-generalized-rsvp-te-06.txt uses the term nodal failure to cover bo=
th cases: i.e., the case where peering RSVP entity restarts or the entire=
 node fails. In either case, non-stop forwarding is assumed. In short, fa=
ilure of
> the last control channel is different from the nodal failures.
> =

> > > > Can't they make use of the same IP network ?
> > >
> > > Yes, they use the same IP (Control) network, but there are differen=
ces in
> > > the two failure cases, e.g., when a peering RSVP process fails vs. =
peering
> > > LMP process fails, control channel(s) failure due to peering node f=
ailure
> > > vs. control channel(s) failure due to an event that made neighborin=
g node
> > > unreachable, etc.
> >
> > Is there a (mandatory) need to distinguish between a failure of the R=
SVP-TE
> > process and a failure of the LMP process ? I guess in a lot of cases =
they fail
> > together (e.g. in case of a nodal failure).
> =

> In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery proc=
edure treats nodal failure and control channel failure differently (pleas=
e see above for how they are related to the failure of the individual pro=
cesses).
> =

> I think what you=92re proposing is that we don=92t need to distinguish =
between the two and we can always apply the signaling channel failure (dr=
aft uses the term nodal failure to refer to a more general case) mechanis=
ms, even in the case of control channel failure? Clearly in the absence o=
f LMP,
> failure of all control channels can only be detected by the signaling l=
ayer, hence will be treated as nodal failures. However, with failure dete=
ction on the control channel, we can do a better job in recovering.
> =

> > Why are process failures related to communication channel failures ?
> > This might indeed lead to the need for two distinct communication
> > channels ('control channel' and 'signalling channel'), which seems to=
 be
> > a disadvantage to me.
> =

> Please see my definition of a signaling channel failure in the above. I=
'm sorry that the absence of the definition in the earlier email caused s=
ome confusion.
> =

> > > When we lose the last control channel with a given neighbor, we los=
e LMP
> > > adjacency with that neighbor. This is an event that IMO requires pr=
oper
> > > treatment from GMPLS control plane.
> >
> > I'm only arguing that standard network layer mechanisms can handle
> > loosing some links in the control plane. We don't need - in my mind -=

> > something specific for LMP.
> >
> >
> > Thanks,
> >
> > Michiel
> >

-- =

+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Thu, 25 Apr 2002 01:22:58 -0700
From: Heiles Juergen <[email-masked]>
To: "'David Wang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: Todor Markov <[email-masked]>, "Steven D. Sensel" <[email-masked]>
Subject: RE: Question about SONET Transparency
Date: Thu, 25 Apr 2002 10:21:38 +0200

David,

you get section/regenerator transparency when you transport the SONET/SDH signal over an DWDM network (either pure wavelength or ODU/digital wrapper) without any termination of the SONET/SDH overhead. Line/Multiplex section transparency is achieved when you transport the SONET/SDH signal over a DWDM system (either pure wavelength or ODU/digital wrapper) that terminates the section/regenerator overhead. The later is for example the case if the transponder/wavelength converter has SONET/SDH regenerator functionality.

Regards

Juergen

> -----Original Message-----
> From: David Wang [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 6:15 PM
> To: [email-masked]'
> Cc: Todor Markov; Steven D. Sensel
> Subject: Question about SONET Transparency
> 
> 
> [ post by non-subscriber ]
> 
> Dear Experts,
> 
> In draft document "GMPLS extension for SONET and SDH 
> Control",  one of the
> SONET/SDH parameter is the "Transparency" field. Two values 
> has been defined
> for this field. 
> 
> Flag 1 (bit 1): section/regenerator transparency, which means 
> all overhead
> bytes will be unchanged in the intermediate device.
> Flag 1 (bit 2): Line/multiplex transparency, which means 
> LOH/MSON cannot be
> changed in the intermediate device.
> 
> By definition, in SONET network the SOH will be read and 
> re-written at the
> end of each section span and LOH will be read and re-written 
> at the end of
> each line span. Where this "transparency" come from? Is it for Digital
> Wrapper? Can somebody give me some background information or 
> point to me
> some Bell Core or ITU-T document or some technical document I 
> can find the
> answer to this "Transparency" SONET/SDH.
> 
> Thanks very much
> David
> 
> 

Delivery-date: Wed, 24 Apr 2002 23:36:19 -0700
Date: Thu, 25 Apr 2002 02:31:53 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]

--=====================_24531834==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Michiel,

Please see comments in-lined.

Thanks

Regards=85 Zafar

At 11:47 AM 4/24/2002 +0200, Michiel van Everdingen wrote:
>Hello Zafar,
>
>
> > No, I think the main source of confusion is that LMP Hellos are NOT the
> > only thing that is part of the control channel management.
>
>What else ?
>Control Channel Management seems to only set up a communication mechanism
>(in the control plane) between two nodes that are neighbours at the
>transmission plane, i.e. that are neighbours regarding dataLinks.
>Also, if I look at the definition of the config messages, I can only find
>parameters that deal with this communication mechanism.
>
>I'm still confused as to why standard network layer mechanisms would not
>be sufficient.

I think this answer depends on how we define sufficient;-) LMP control=20
channel management brings some features into picture, e.g., when we=92ve=20
hidden control channels, how can we guarantee that the neighbor is=20
listening to the channel we=92re sending your control messages to? With the=
=20
configuration handshake, LMP guarantees that the two ends are ready to=20
exchange messages on the control channel in question.

Similarly, it provides a way by which failure on a routed control channel=20
(control channel is not bound to a physical interface) or a control channel=
=20
where L2 cannot detect the failure. Without LMP control channel management,=
=20
how you would suggest management and health check for such control=20
channels? Skipping such tests will IMO lead to a more ad hoc procedures/=20
protocols.

> > > Is there a need to distinguish between signalling channels and control
> > > channels ?
> >
> > Yes, e.g., RSVP recovery procedure differentiate between the control
> > channel failures and the signalling channel (Nodal) failure.
>
>My understanding is that a nodal failure "relates to the case where a node
>losses its control state (e.g., after a restart) but does not loose its=
 data
>forwarding state."
>
>A nodal failure is therefore something else than a failure in a=
 communication
>mechanism. Correct ?
>
>Why do you relate nodal failure with the failure of a communication
>mechanism (the 'signalling channel') ?

Signaling channel is a term I used to specify the following: Signaling=20
channel is the logical channel over which signaling (say RSVP-TE) messages=
=20
are exchanged between RSVP peering entities. The signaling channel is=20
realized using the collection of all control channels between the two RSVP=
=20
peers. A signaling channel failure could be the result of the concurrent=20
failure of all control channels or the failure of one of the peering=20
signaling entities or one of the peering nodes. Hence, signaling channel=20
failure is different than failure of all control channels.

Using the above mentioned definition, a nodal failure always imply the=20
failure of the signaling channel as well as control channels. However,=20
failure of the last control channel does not imply a nodal failure. For the=
=20
sake of completeness, a signaling channel failure could be due to failure=20
of the peering RSVP process or due to the neighbor node failure. The=20
draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal failure to=20
cover both cases: i.e., the case where peering RSVP entity restarts or the=
=20
entire node fails. In either case, non-stop forwarding is assumed. In=20
short, failure of the last control channel is different from the nodal=20
failures.

> > > Can't they make use of the same IP network ?
> >
> > Yes, they use the same IP (Control) network, but there are differences=
 in
> > the two failure cases, e.g., when a peering RSVP process fails vs.=
 peering
> > LMP process fails, control channel(s) failure due to peering node=
 failure
> > vs. control channel(s) failure due to an event that made neighboring=
 node
> > unreachable, etc.
>
>Is there a (mandatory) need to distinguish between a failure of the RSVP-TE
>process and a failure of the LMP process ? I guess in a lot of cases they=
 fail
>together (e.g. in case of a nodal failure).

In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery=20
procedure treats nodal failure and control channel failure differently=20
(please see above for how they are related to the failure of the individual=
=20
processes).

I think what you=92re proposing is that we don=92t need to distinguish=
 between=20
the two and we can always apply the signaling channel failure (draft uses=20
the term nodal failure to refer to a more general case) mechanisms, even in=
=20
the case of control channel failure? Clearly in the absence of LMP, failure=
=20
of all control channels can only be detected by the signaling layer, hence=
=20
will be treated as nodal failures. However, with failure detection on the=20
control channel, we can do a better job in recovering.

>Why are process failures related to communication channel failures ?
>This might indeed lead to the need for two distinct communication
>channels ('control channel' and 'signalling channel'), which seems to be
>a disadvantage to me.

Please see my definition of a signaling channel failure in the above. I'm=20
sorry that the absence of the definition in the earlier email caused some=20
confusion.

> > When we lose the last control channel with a given neighbor, we lose LMP
> > adjacency with that neighbor. This is an event that IMO requires proper
> > treatment from GMPLS control plane.
>
>I'm only arguing that standard network layer mechanisms can handle
>loosing some links in the control plane. We don't need - in my mind -
>something specific for LMP.
>
>
>Thanks,
>
>Michiel
>
>
>Zafar Ali wrote:
> >
> > Dear Michiel,
> >
> > Please see comments in-lined. Jonathan, et all please correct me if I=20
> am wrong.
> >
> > Thanks
> >
> > Regards=85 Zafar
> >
> > At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:
> >
> > > Hello Zafar,
> > >
> > > Thanks for your answers.
> > >
> > > You start by stating
> > >   "The control channel failure detection mechanism is required if=20
> ...<snip>..."
> > > Does this imply that the "control channel management" procedure is=20
> not *always*
> > > required ?
> >
> > No, I think the main source of confusion is that LMP Hellos are NOT the=
=20
> only thing that is part of the control channel management. I read the=20
> following in the draft as a way by which LMP Hellos on a given control=20
> channel can be disabled,
> > =93If the fast keep-alive mechanism of LMP is not used, the=
 HelloInterval=20
> and HelloDeadInterval parameters MUST be set to zero.=94
> > Or one can choose a very high value for the HelloInterval and=20
> HelloDeadInterval.
> >
> > Nonetheless, the configuration parameters for the control channels need=
=20
> to be exchanged using the using Config, ConfigAck, and ConfigNack=20
> messages: the mandatory part.
> >
> > > I understood from the draft and from Jonathan's answers that "control
> > > channel management" is mandatory.
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html
> > >
> > > I can imagine there are cases in which "control channel management"=20
> is not
> > > providing benefit:
> > > - In case there is only one DCC channel with the neighboring node.
> > > - In case lower level mechanisms (e.g. MPLS protection or ML-PPP) are=
=20
> available.
> > > Control channel Management seems to give only unnecessary overhead and
> > > complexity in these cases.
> > >
> > > Is it possible to make "control channel management" an optional=20
> procedure ?
> >
> > Does your comment applies only to LMP Hellos (for which solutions=20
> exist) or to the entire Control Channel State machinery?
> >
> > > Please find further reactions on your email below:
> > >
> > >
> > > > E.g., we would like to distinguish between signalling channel=20
> failure and
> > > > control channel failure during RSVP-TE recovery process, etc.
> > >
> > > Is there a need to distinguish between signalling channels and=20
> control channels ?
> >
> > Yes, e.g., RSVP recovery procedure differentiate between the control=20
> channel failures and the signalling channel (Nodal) failure.
> >
> > > Can't they make use of the same IP network ?
> >
> > Yes, they use the same IP (Control) network, but there are differences=
=20
> in the two failure cases, e.g., when a peering RSVP process fails vs.=20
> peering LMP process fails, control channel(s) failure due to peering node=
=20
> failure vs. control channel(s) failure due to an event that made=20
> neighboring node
> > unreachable, etc.
> >
> > > > Hence, LMP Hellos should be faster than RSVP Hellos or the=20
> mechanism used to
> > > > detect signaling channel failure. Similarly, LMP Hello frequency=
 should
> > > > be greater than IGP hello frequency, so that the optical network=20
> can make
> > > > "conscious" decision on the control channel failure, before having=
=20
> an adverse
> > > > affect on the IGP adjacencies at L3.
> > >
> > > Indeed. This added complexity makes me questioning if we really need=
=20
> "control
> > > channel management".
> >
> > When we lose the last control channel with a given neighbor, we lose=20
> LMP adjacency with that neighbor. This is an event that IMO requires=20
> proper treatment from GMPLS control plane.
> >
> > > > > As stated in section 13 of the LMP draft, all LMP messages are
> > > > > IP encoded. So a standard general purpose IP network should
> > > > > perfectly well be capable to transport such IP encoded LMP
> > > > > messages to the intended destination. Am I missing something
> > > > > here ?
> > > >
> > > > I am sorry but I did not understand what you meant here?
> > >
> > > This is in reaction to Jonathans question in another thread:
> > >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html
> > > My feeling is that standard network layer mechanisms are sufficient.
> > >
> > >
> > > Regards,
> > >
> > > Michiel
> > >
> > > <...snip...>
>
>--
>+------------------------------------------------------------------+
>| Michiel van Everdingen                                           |
>| Systems Engineer                                                 |
>| Lucent Technologies - Optical Networking Group                   |
>| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
>| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
>| Huizen, The Netherlands        mailto:[email-masked]  |
>+------------------------------------------------------------------+

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.

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

<html>
<font size=3D3>Hi Michiel, <br>
<br>
Please see comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards=85 Zafar <br>
<br>
At 11:47 AM 4/24/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=3Dcite cite>Hello Zafar,<br>
<br>
<br>
&gt; No, I think the main source of confusion is that LMP Hellos are NOT
the<br>
&gt; only thing that is part of the control channel management. <br>
<br>
What else ?<br>
Control Channel Management seems to only set up a communication
mechanism<br>
(in the control plane) between two nodes that are neighbours at the<br>
transmission plane, i.e. that are neighbours regarding dataLinks.<br>
Also, if I look at the definition of the config messages, I can only
find<br>
parameters that deal with this communication mechanism.<br>
<br>
I'm still confused as to why standard network layer mechanisms would
not<br>
be sufficient.</font></blockquote><br>
<font size=3D3>I think this answer depends on how we define sufficient;-)
LMP control channel management brings some features into picture, e.g.,
when we=92ve hidden control channels, how can we guarantee that the
neighbor is listening to the channel we=92re sending your control messages
to? With the configuration handshake, LMP guarantees that the two ends
are ready to exchange messages on the control channel in question.&nbsp;
<br>
<br>
Similarly, it provides a way by which failure on a routed control channel
(control channel is not bound to a physical interface) or a control
channel where L2 cannot detect the failure. Without LMP control channel
management, how you would suggest management and health check for such
control channels? Skipping such tests will IMO lead to a more ad hoc
procedures/ protocols. <br>
<br>
<br>
<br>
<blockquote type=3Dcite cite>&gt; &gt; Is there a need to distinguish
between signalling channels and control<br>
&gt; &gt; channels ?<br>
&gt; <br>
&gt; Yes, e.g., RSVP recovery procedure differentiate between the
control<br>
&gt; channel failures and the signalling channel (Nodal) failure.<br>
<br>
My understanding is that a nodal failure &quot;relates to the case where
a node<br>
losses its control state (e.g., after a restart) but does not loose its
data<br>
forwarding state.&quot;<br>
<br>
A nodal failure is therefore something else than a failure in a
communication<br>
mechanism. Correct ?<br>
<br>
Why do you relate nodal failure with the failure of a communication<br>
mechanism (the 'signalling channel') ?</font></blockquote><br>
<font size=3D3>Signaling channel is a term I used to specify the following:
Signaling channel is the logical channel over which signaling (say
RSVP-TE) messages are exchanged between RSVP peering entities. The
signaling channel is realized using the collection of all control
channels between the two RSVP peers. A signaling channel failure could be
the result of the concurrent failure of all control channels or the
failure of one of the peering signaling entities or one of the peering
nodes. Hence, signaling channel failure is different than failure of all
control channels. <br>
<br>
Using the above mentioned definition, a nodal failure always imply the
failure of the signaling channel as well as control channels. However,
failure of the last control channel does not imply a nodal failure. For
the sake of completeness, a signaling channel failure could be due to
failure of the peering RSVP process or due to the neighbor node failure.
The draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
failure to cover both cases: i.e., the case where peering RSVP entity
restarts or the entire node fails. In either case, non-stop forwarding is
assumed. In short, failure of the last control channel is different from
the nodal failures. <br>
<br>
<br>
<br>
<blockquote type=3Dcite cite>&gt; &gt; Can't they make use of the same IP
network ?<br>
&gt; <br>
&gt; Yes, they use the same IP (Control) network, but there are
differences in<br>
&gt; the two failure cases, e.g., when a peering RSVP process fails vs.
peering<br>
&gt; LMP process fails, control channel(s) failure due to peering node
failure<br>
&gt; vs. control channel(s) failure due to an event that made neighboring
node<br>
&gt; unreachable, etc.<br>
<br>
Is there a (mandatory) need to distinguish between a failure of the
RSVP-TE<br>
process and a failure of the LMP process ? I guess in a lot of cases they
fail<br>
together (e.g. in case of a nodal failure).</font></blockquote><br>
<font size=3D3>In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP
recovery procedure treats nodal failure and control channel failure
differently (please see above for how they are related to the failure of
the individual processes). <br>
<br>
I think what you=92re proposing is that we don=92t need to distinguish
between the two and we can always apply the signaling channel failure
(draft uses the term nodal failure to refer to a more general case)
mechanisms, even in the case of control channel failure? Clearly in the
absence of LMP, failure of all control channels can only be detected by
the signaling layer, hence will be treated as nodal failures. However,
with failure detection on the control channel, we can do a better job in
recovering. <br>
<br>
<br>
<blockquote type=3Dcite cite>Why are process failures related to
communication channel failures ?<br>
This might indeed lead to the need for two distinct communication<br>
channels ('control channel' and 'signalling channel'), which seems to
be<br>
a disadvantage to me.</font></blockquote><br>
Please see my definition of a signaling channel failure in the above. I'm
sorry that the absence of the definition in the earlier email caused some
confusion. <br>
<br>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D3>&gt; When we lose the last
control channel with a given neighbor, we lose LMP<br>
&gt; adjacency with that neighbor. This is an event that IMO requires
proper<br>
&gt; treatment from GMPLS control plane.<br>
<br>
I'm only arguing that standard network layer mechanisms can handle<br>
loosing some links in the control plane. We don't need - in my mind
-<br>
something specific for LMP.<br>
<br>
<br>
Thanks,<br>
<br>
Michiel<br>
<br>
<br>
Zafar Ali wrote:<br>
&gt; <br>
&gt; Dear Michiel,<br>
&gt; <br>
&gt; Please see comments in-lined. Jonathan, et all please correct me if
I am wrong.<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Regards=85 Zafar<br>
&gt; <br>
&gt; At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:<br>
&gt; <br>
&gt; &gt; Hello Zafar,<br>
&gt; &gt;<br>
&gt; &gt; Thanks for your answers.<br>
&gt; &gt;<br>
&gt; &gt; You start by stating<br>
&gt; &gt;&nbsp;&nbsp; &quot;The control channel failure detection
mechanism is required if ...&lt;snip&gt;...&quot;<br>
&gt; &gt; Does this imply that the &quot;control channel management&quot;
procedure is not *always*<br>
&gt; &gt; required ?<br>
&gt; <br>
&gt; No, I think the main source of confusion is that LMP Hellos are NOT
the only thing that is part of the control channel management. I read the
following in the draft as a way by which LMP Hellos on a given control
channel can be disabled,<br>
&gt; =93If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval parameters MUST be set to=20
zero.=94<br>
&gt; Or one can choose a very high value for the HelloInterval and
HelloDeadInterval.<br>
&gt; <br>
&gt; Nonetheless, the configuration parameters for the control channels
need to be exchanged using the using Config, ConfigAck, and ConfigNack
messages: the mandatory part.<br>
&gt; <br>
&gt; &gt; I understood from the draft and from Jonathan's answers that
&quot;control<br>
&gt; &gt; channel management&quot; is mandatory.<br>
&gt; &gt;&nbsp;&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html=
</a><br>
&gt; &gt;&nbsp;&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html=
</a><br>
&gt; &gt;<br>
&gt; &gt; I can imagine there are cases in which &quot;control channel
management&quot; is not<br>
&gt; &gt; providing benefit:<br>
&gt; &gt; - In case there is only one DCC channel with the neighboring
node.<br>
&gt; &gt; - In case lower level mechanisms (e.g. MPLS protection or
ML-PPP) are available.<br>
&gt; &gt; Control channel Management seems to give only unnecessary
overhead and<br>
&gt; &gt; complexity in these cases.<br>
&gt; &gt;<br>
&gt; &gt; Is it possible to make &quot;control channel management&quot;
an optional procedure ?<br>
&gt; <br>
&gt; Does your comment applies only to LMP Hellos (for which solutions
exist) or to the entire Control Channel State machinery?<br>
&gt; <br>
&gt; &gt; Please find further reactions on your email below:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; E.g., we would like to distinguish between signalling
channel failure and<br>
&gt; &gt; &gt; control channel failure during RSVP-TE recovery process,
etc.<br>
&gt; &gt;<br>
&gt; &gt; Is there a need to distinguish between signalling channels and
control channels ?<br>
&gt; <br>
&gt; Yes, e.g., RSVP recovery procedure differentiate between the control
channel failures and the signalling channel (Nodal) failure.<br>
&gt; <br>
&gt; &gt; Can't they make use of the same IP network ?<br>
&gt; <br>
&gt; Yes, they use the same IP (Control) network, but there are
differences in the two failure cases, e.g., when a peering RSVP process
fails vs. peering LMP process fails, control channel(s) failure due to
peering node failure vs. control channel(s) failure due to an event that
made neighboring node<br>
&gt; unreachable, etc.<br>
&gt; <br>
&gt; &gt; &gt; Hence, LMP Hellos should be faster than RSVP Hellos or the
mechanism used to<br>
&gt; &gt; &gt; detect signaling channel failure. Similarly, LMP Hello
frequency should<br>
&gt; &gt; &gt; be greater than IGP hello frequency, so that the optical
network can make<br>
&gt; &gt; &gt; &quot;conscious&quot; decision on the control channel
failure, before having an adverse<br>
&gt; &gt; &gt; affect on the IGP adjacencies at L3.<br>
&gt; &gt;<br>
&gt; &gt; Indeed. This added complexity makes me questioning if we really
need &quot;control<br>
&gt; &gt; channel management&quot;.<br>
&gt; <br>
&gt; When we lose the last control channel with a given neighbor, we lose
LMP adjacency with that neighbor. This is an event that IMO requires
proper treatment from GMPLS control plane.<br>
&gt; <br>
&gt; &gt; &gt; &gt; As stated in section 13 of the LMP draft, all LMP
messages are<br>
&gt; &gt; &gt; &gt; IP encoded. So a standard general purpose IP network
should<br>
&gt; &gt; &gt; &gt; perfectly well be capable to transport such IP
encoded LMP<br>
&gt; &gt; &gt; &gt; messages to the intended destination. Am I missing
something<br>
&gt; &gt; &gt; &gt; here ?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I am sorry but I did not understand what you meant
here?<br>
&gt; &gt;<br>
&gt; &gt; This is in reaction to Jonathans question in another
thread:<br>
&gt; &gt;&nbsp;&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html=
</a><br>
&gt; &gt; My feeling is that standard network layer mechanisms are
sufficient.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt;<br>
&gt; &gt; Michiel<br>
&gt; &gt;<br>
&gt; &gt; &lt;...snip...&gt;<br>
<br>
-- <br>
+------------------------------------------------------------------+<br>
| Michiel van
Everdingen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Systems
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Lucent Technologies - Optical Networking
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
| Botterstraat 45, 1271 XL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :
+31 35 687
4883&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
| P.O. Box 18, 1270
AA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax&nbsp;&nbsp; : +31 35 687
5976&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
| Huizen, The Netherlands&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href=3D"mailto:[email-masked]%A0" eudora=3D"autourl">mailto:Mv=
[email-masked]
</a> |<br>
+------------------------------------------------------------------+</blockq=
uote><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
</font></html>

--=====================_24531834==_.ALT--

Delivery-date: Wed, 24 Apr 2002 15:18:06 -0700
From: David Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Todor Markov <[email-masked]>, "Steven D. Sensel" <[email-masked]>
Subject: Question about SONET Transparency
Date: Wed, 24 Apr 2002 11:14:59 -0500

[ post by non-subscriber ]

Dear Experts,

In draft document "GMPLS extension for SONET and SDH Control",  one of the
SONET/SDH parameter is the "Transparency" field. Two values has been defined
for this field. 

Flag 1 (bit 1): section/regenerator transparency, which means all overhead
bytes will be unchanged in the intermediate device.
Flag 1 (bit 2): Line/multiplex transparency, which means LOH/MSON cannot be
changed in the intermediate device.

By definition, in SONET network the SOH will be read and re-written at the
end of each section span and LOH will be read and re-written at the end of
each line span. Where this "transparency" come from? Is it for Digital
Wrapper? Can somebody give me some background information or point to me
some Bell Core or ITU-T document or some technical document I can find the
answer to this "Transparency" SONET/SDH.

Thanks very much
David

Delivery-date: Wed, 24 Apr 2002 02:50:09 -0700
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Wed, 24 Apr 2002 11:47:40 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hello Zafar,

> No, I think the main source of confusion is that LMP Hellos are NOT the=

> only thing that is part of the control channel management. =

What else ?
Control Channel Management seems to only set up a communication mechanism=

(in the control plane) between two nodes that are neighbours at the
transmission plane, i.e. that are neighbours regarding dataLinks.
Also, if I look at the definition of the config messages, I can only find=

parameters that deal with this communication mechanism.

I'm still confused as to why standard network layer mechanisms would not
be sufficient.

> > Is there a need to distinguish between signalling channels and contro=
l
> > channels ?
> =

> Yes, e.g., RSVP recovery procedure differentiate between the control
> channel failures and the signalling channel (Nodal) failure.

My understanding is that a nodal failure "relates to the case where a nod=
e
losses its control state (e.g., after a restart) but does not loose its d=
ata
forwarding state."

A nodal failure is therefore something else than a failure in a communica=
tion
mechanism. Correct ?

Why do you relate nodal failure with the failure of a communication
mechanism (the 'signalling channel') ?

> > Can't they make use of the same IP network ?
> =

> Yes, they use the same IP (Control) network, but there are differences =
in
> the two failure cases, e.g., when a peering RSVP process fails vs. peer=
ing
> LMP process fails, control channel(s) failure due to peering node failu=
re
> vs. control channel(s) failure due to an event that made neighboring no=
de
> unreachable, etc.

Is there a (mandatory) need to distinguish between a failure of the RSVP-=
TE
process and a failure of the LMP process ? I guess in a lot of cases they=
 fail
together (e.g. in case of a nodal failure).

Why are process failures related to communication channel failures ?
This might indeed lead to the need for two distinct communication
channels ('control channel' and 'signalling channel'), which seems to be
a disadvantage to me.

> When we lose the last control channel with a given neighbor, we lose LM=
P
> adjacency with that neighbor. This is an event that IMO requires proper=

> treatment from GMPLS control plane.

I'm only arguing that standard network layer mechanisms can handle
loosing some links in the control plane. We don't need - in my mind -
something specific for LMP.

Thanks,

Michiel

Zafar Ali wrote:
> =

> Dear Michiel,
> =

> Please see comments in-lined. Jonathan, et all please correct me if I a=
m wrong.
> =

> Thanks
> =

> Regards=85 Zafar
> =

> At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:
> =

> > Hello Zafar,
> >
> > Thanks for your answers.
> >
> > You start by stating
> >   "The control channel failure detection mechanism is required if ...=
<snip>..."
> > Does this imply that the "control channel management" procedure is no=
t *always*
> > required ?
> =

> No, I think the main source of confusion is that LMP Hellos are NOT the=
 only thing that is part of the control channel management. I read the fo=
llowing in the draft as a way by which LMP Hellos on a given control chan=
nel can be disabled,
> =93If the fast keep-alive mechanism of LMP is not used, the HelloInterv=
al and HelloDeadInterval parameters MUST be set to zero.=94
> Or one can choose a very high value for the HelloInterval and HelloDead=
Interval.
> =

> Nonetheless, the configuration parameters for the control channels need=
 to be exchanged using the using Config, ConfigAck, and ConfigNack messag=
es: the mandatory part.
> =

> > I understood from the draft and from Jonathan's answers that "control=

> > channel management" is mandatory.
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html
> >
> > I can imagine there are cases in which "control channel management" i=
s not
> > providing benefit:
> > - In case there is only one DCC channel with the neighboring node.
> > - In case lower level mechanisms (e.g. MPLS protection or ML-PPP) are=
 available.
> > Control channel Management seems to give only unnecessary overhead an=
d
> > complexity in these cases.
> >
> > Is it possible to make "control channel management" an optional proce=
dure ?
> =

> Does your comment applies only to LMP Hellos (for which solutions exist=
) or to the entire Control Channel State machinery?
> =

> > Please find further reactions on your email below:
> >
> >
> > > E.g., we would like to distinguish between signalling channel failu=
re and
> > > control channel failure during RSVP-TE recovery process, etc.
> >
> > Is there a need to distinguish between signalling channels and contro=
l channels ?
> =

> Yes, e.g., RSVP recovery procedure differentiate between the control ch=
annel failures and the signalling channel (Nodal) failure.
> =

> > Can't they make use of the same IP network ?
> =

> Yes, they use the same IP (Control) network, but there are differences =
in the two failure cases, e.g., when a peering RSVP process fails vs. pee=
ring LMP process fails, control channel(s) failure due to peering node fa=
ilure vs. control channel(s) failure due to an event that made neighborin=
g node
> unreachable, etc.
> =

> > > Hence, LMP Hellos should be faster than RSVP Hellos or the mechanis=
m used to
> > > detect signaling channel failure. Similarly, LMP Hello frequency sh=
ould
> > > be greater than IGP hello frequency, so that the optical network ca=
n make
> > > "conscious" decision on the control channel failure, before having =
an adverse
> > > affect on the IGP adjacencies at L3.
> >
> > Indeed. This added complexity makes me questioning if we really need =
"control
> > channel management".
> =

> When we lose the last control channel with a given neighbor, we lose LM=
P adjacency with that neighbor. This is an event that IMO requires proper=
 treatment from GMPLS control plane.
> =

> > > > As stated in section 13 of the LMP draft, all LMP messages are
> > > > IP encoded. So a standard general purpose IP network should
> > > > perfectly well be capable to transport such IP encoded LMP
> > > > messages to the intended destination. Am I missing something
> > > > here ?
> > >
> > > I am sorry but I did not understand what you meant here?
> >
> > This is in reaction to Jonathans question in another thread:
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html
> > My feeling is that standard network layer mechanisms are sufficient.
> >
> >
> > Regards,
> >
> > Michiel
> >
> > <...snip...>

-- =

+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Wed, 24 Apr 2002 00:46:24 -0700
Cc: [email-masked]
Date: Wed, 24 Apr 2002 09:44:17 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Jonathan,

> LMP provides discovery of the physical layer. For in-band signaling, LMP
> provides both control plane and physical layer discovery. Working Group has
> already accepted this.

Thanks for the explanation.

Could you then please elaborate a bit more on the following part of your email
in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html

----
> How do you start this link Verification procedure ? The 'beginVerify' message
> seems to assume that the neighbor is already known.
Sending the BeginVerify assumes you know where to send control messages.
This is separate from discovering the data interfaces. This is why using the
term Neighbor Discovery can often be confusing.  You actually have discovery
at various levels. G.7714 talks about this in a little more detail.

> 
> Please note that I'm discussing initial discovery. I don't question the use
> of subsequent test messages verifying the connectivity.
Noted.
----

You seem to want to use the verification procedure for initial neighbor discovery.
However, it is still unclear to me how you can start this verification procedure.

Moreover, in my mind, the verification procedure is not applicable to all dataLink
types. See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html

Best regards,

Michiel

Jonathan Lang wrote:
> 
> Michiel,
> 
> > -----Original Message-----
> > From: Michiel van Everdingen [mailto:[email-masked]]
> > Sent: Sunday, April 21, 2002 11:00 PM
> > To: Jonathan Lang
> > Cc: [email-masked]'
> > Subject: Re: LMP & neighbor discovery
> >
> >
> > Hello Jonathan, all,
> >
> > Does "<snip>" imply that you are not interested in specifying initial
> > neighbor discovery ? Is this accepted by this working group ?
> LMP provides discovery of the physical layer. For in-band signaling, LMP
> provides both control plane and physical layer discovery. Working Group has
> already accepted this.
> 
> <snip> was used to get to what I thought were your main issues.
> 
> Thanks,
> Jonathan
> 
> >
> > Somehow I think that would be a pity. My impression is that it would
> > have been quite easy to copy the text from
> >   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
> > in an additional section in the LMP draft.
> >
> > Please let me know if you think I left a question on this text
> > unanswered.
> >
> >
> > Thanks,
> >
> > Michiel
> >
> > P.S. Jonathan: I will try to answer your question on the
> > control channel
> > in the thread "Question on LMP".
> >
> > Jonathan Lang wrote:
> > >
> > > Michiel,
> > >
> > > <snip>
> > > >
> > > > Repeating my earlier questions:
> > > > - Why is 'control channel management' mandatory ?
> > > > - Why are normal (i.e. not LMP specific) network layer
> > mechanisms not
> > > >   sufficient ?
> > > Why do you think they are sufficient?
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > <...snip...>
> >
> > --
> > +------------------------------------------------------------------+
> > | Michiel van Everdingen                                           |
> > | Systems Engineer                                                 |
> > | Lucent Technologies - Optical Networking Group                   |
> > | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> > | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> > | Huizen, The Netherlands        mailto:[email-masked]  |
> > +------------------------------------------------------------------+
> >

Delivery-date: Tue, 23 Apr 2002 20:40:07 -0700
From: Jonathan Lang <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Tue, 23 Apr 2002 20:29:56 -0700

Michiel,

> -----Original Message-----
> From: Michiel van Everdingen [mailto:[email-masked]]
> Sent: Sunday, April 21, 2002 11:00 PM
> To: Jonathan Lang
> Cc: [email-masked]'
> Subject: Re: LMP & neighbor discovery
> 
> 
> Hello Jonathan, all,
> 
> Does "<snip>" imply that you are not interested in specifying initial
> neighbor discovery ? Is this accepted by this working group ?
LMP provides discovery of the physical layer. For in-band signaling, LMP
provides both control plane and physical layer discovery. Working Group has
already accepted this.

<snip> was used to get to what I thought were your main issues.

Thanks,
Jonathan

> 
> Somehow I think that would be a pity. My impression is that it would
> have been quite easy to copy the text from
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
> in an additional section in the LMP draft.
> 
> Please let me know if you think I left a question on this text
> unanswered.
> 
> 
> Thanks,
> 
> Michiel
> 
> P.S. Jonathan: I will try to answer your question on the 
> control channel
> in the thread "Question on LMP".
> 
> Jonathan Lang wrote:
> > 
> > Michiel,
> > 
> > <snip>
> > >
> > > Repeating my earlier questions:
> > > - Why is 'control channel management' mandatory ?
> > > - Why are normal (i.e. not LMP specific) network layer 
> mechanisms not
> > >   sufficient ?
> > Why do you think they are sufficient?
> > 
> > Thanks,
> > Jonathan
> > 
> > <...snip...>
> 
> -- 
> +------------------------------------------------------------------+
> | Michiel van Everdingen                                           |
> | Systems Engineer                                                 |
> | Lucent Technologies - Optical Networking Group                   |
> | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> | Huizen, The Netherlands        mailto:[email-masked]  |
> +------------------------------------------------------------------+
> 

Delivery-date: Tue, 23 Apr 2002 16:20:23 -0700
Date: Tue, 23 Apr 2002 19:15:29 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]

--=====================_22563855==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear Michiel,

Please see comments in-lined. Jonathan, et all please correct me if I am=20
wrong.

Thanks

Regards=85 Zafar

At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:
>Hello Zafar,
>
>Thanks for your answers.
>
>You start by stating
>   "The control channel failure detection mechanism is required if=20
> ...<snip>..."
>Does this imply that the "control channel management" procedure is not=20
>*always*
>required ?

No, I think the main source of confusion is that LMP Hellos are NOT the=20
only thing that is part of the control channel management. I read the=20
following in the draft as a way by which LMP Hellos on a given control=20
channel can be disabled,
=93If the fast keep-alive mechanism of LMP is not used, the HelloInterval=
 and=20
HelloDeadInterval parameters MUST be set to zero.=94
Or one can choose a very high value for the HelloInterval and=20
HelloDeadInterval.

Nonetheless, the configuration parameters for the control channels need to=
=20
be exchanged using the using Config, ConfigAck, and ConfigNack messages:=20
the mandatory part.

>I understood from the draft and from Jonathan's answers that "control
>channel management" is mandatory.
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html
>
>I can imagine there are cases in which "control channel management" is not
>providing benefit:
>- In case there is only one DCC channel with the neighboring node.
>- In case lower level mechanisms (e.g. MPLS protection or ML-PPP) are=20
>available.
>Control channel Management seems to give only unnecessary overhead and
>complexity in these cases.
>
>Is it possible to make "control channel management" an optional procedure ?

Does your comment applies only to LMP Hellos (for which solutions exist) or=
=20
to the entire Control Channel State machinery?

>Please find further reactions on your email below:
>
>
> > E.g., we would like to distinguish between signalling channel failure=
 and
> > control channel failure during RSVP-TE recovery process, etc.
>
>Is there a need to distinguish between signalling channels and control=20
>channels ?

Yes, e.g., RSVP recovery procedure differentiate between the control=20
channel failures and the signalling channel (Nodal) failure.

>Can't they make use of the same IP network ?

Yes, they use the same IP (Control) network, but there are differences in=20
the two failure cases, e.g., when a peering RSVP process fails vs. peering=
=20
LMP process fails, control channel(s) failure due to peering node failure=20
vs. control channel(s) failure due to an event that made neighboring node=20
unreachable, etc.

> > Hence, LMP Hellos should be faster than RSVP Hellos or the mechanism=20
> used to
> > detect signaling channel failure. Similarly, LMP Hello frequency should
> > be greater than IGP hello frequency, so that the optical network can=
 make
> > "conscious" decision on the control channel failure, before having an=20
> adverse
> > affect on the IGP adjacencies at L3.
>
>Indeed. This added complexity makes me questioning if we really need=
 "control
>channel management".

When we lose the last control channel with a given neighbor, we lose LMP=20
adjacency with that neighbor. This is an event that IMO requires proper=20
treatment from GMPLS control plane.

> > > As stated in section 13 of the LMP draft, all LMP messages are
> > > IP encoded. So a standard general purpose IP network should
> > > perfectly well be capable to transport such IP encoded LMP
> > > messages to the intended destination. Am I missing something
> > > here ?
> >
> > I am sorry but I did not understand what you meant here?
>
>This is in reaction to Jonathans question in another thread:
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html
>My feeling is that standard network layer mechanisms are sufficient.
>
>
>Regards,
>
>Michiel
>
>Zafar Ali wrote:
> >
> > Hi Michiel,
> >
> > Please see some comments in-lined.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
> >
> > > Hello Manoj, Ravi, Jonathan, Zafar,
> > >
> > > I'm somewhat confused on the state of this thread. As far as I
> > > can see, the following questions are still open:
> > > - why is control channel management needed at all ?
> >
> > The control channel failure detection mechanism is required if=20
> lower-level mechanisms are NOT available to detect control channel=20
> failures. E.g., when control channel is (IP) routed and not bound with a=
=20
> particular interface. Furthermore, a control channel failure is an event=
=20
> on which applications
> > are interested in from various prospective. E.g., we would like to=20
> distinguish between signalling channel failure and control channel=20
> failure during RSVP-TE recovery process, etc.
> >
> > > - why does control channel management need to be fast ?
> >
> > A note on the frequency of LMP Hellos: Please note that we need to=20
> distinguish between a signaling channel failure and the control channel=20
> failure. Hence, LMP Hellos should be faster than RSVP Hellos or the=20
> mechanism used to detect signaling channel failure. Similarly, LMP Hello=
=20
> frequency should
> > be greater than IGP hello frequency, so that the optical network can=20
> make "conscious" decision on the control channel failure, before having=20
> an adverse affect on the IGP adjacencies at L3.
> >
> > > - is control channel management fast ?
> >
> > I think the LMP Hello frequency need to follow the above mentioned=20
> criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP=
=20
> Hellos need to be "fast".
> >
> > > As stated in section 13 of the LMP draft, all LMP messages are
> > > IP encoded. So a standard general purpose IP network should
> > > perfectly well be capable to transport such IP encoded LMP
> > > messages to the intended destination. Am I missing something
> > > here ?
> >
> > I am sorry but I did not understand what you meant here?
> >
> > > One of the advantages of using a general purpose IP network is
> > > that there is no need for a point-to-point direct communication
> > > channel between sender and destination. point-to-point direct
> > > communication can become a problem, e.g. when the dataLink is a
> > > VC-12 or a VT-1.5.
> > >
> > > Moreover, control channel management seems to give unnecessary
> > > overhead in case there is only one interface between two
> > > neighbouring switches.
> >
> > IMO when control channels are interface bound (i.e., failure of the=20
> interface means failure in the control channel) and L2 mechanism are=20
> available to for failure detection, we can run LMP Hellos at a lower=20
> frequency and rely on L2 control channel failure detection. But please=20
> note that this is not
> > always the case that your control channel are bound to a particular=20
> interface (e.g., IP routed control channels), hence the need for failure=
=20
> detection within the scope of LMP.
> >
> > > Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
> > > as alternative for "control channel management" ? This seems to
> > > logically extend the current stack used for IP over DCN. From
> > > ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
> > > framing shall be used as the data-link layer protocol."
> > >
> > >
> > > Regards,
> > >
> > > Michiel
> > >
> > > ...<snip>...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.

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

<html>
<font size=3D3>Dear Michiel, <br>
<br>
Please see comments in-lined. Jonathan, et all please correct me if I am
wrong. <br>
<br>
Thanks<br>
<br>
Regards=85 Zafar <br>
<br>
At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=3Dcite cite>Hello Zafar,<br>
<br>
Thanks for your answers.<br>
<br>
You start by stating<br>
&nbsp; &quot;The control channel failure detection mechanism is required
if ...&lt;snip&gt;...&quot;<br>
Does this imply that the &quot;control channel management&quot; procedure
is not *always*<br>
required ? </font></blockquote><br>
<font size=3D3>No, I think the main source of confusion is that LMP Hellos
are NOT the only thing that is part of the control channel management. I
read the following in the draft as a way by which LMP Hellos on a given
control channel can be disabled, <br>
=93<u>If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval parameters MUST be set to
zero.</u>=94<br>
Or one can choose a very high value for the HelloInterval and
HelloDeadInterval. <br>
<br>
Nonetheless, the configuration parameters for the control channels need
to be exchanged using the using Config, ConfigAck, and ConfigNack
messages: the mandatory part. <br>
<br>
<blockquote type=3Dcite cite>I understood from the draft and from
Jonathan's answers that &quot;control<br>
channel management&quot; is mandatory.<br>
&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html=
</a><br>
&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html=
</a><br>
<br>
I can imagine there are cases in which &quot;control channel
management&quot; is not<br>
providing benefit:<br>
- In case there is only one DCC channel with the neighboring node.<br>
- In case lower level mechanisms (e.g. MPLS protection or ML-PPP) are
available.<br>
Control channel Management seems to give only unnecessary overhead
and<br>
complexity in these cases.<br>
<br>
Is it possible to make &quot;control channel management&quot; an optional
procedure ?</font></blockquote><br>
Does your comment applies only to LMP Hellos (for which solutions exist)
or to the entire Control Channel State machinery?&nbsp; <br>
<br>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D3>Please find further reactions on
your email below:<br>
<br>
<br>
&gt; E.g., we would like to distinguish between signalling channel
failure and<br>
&gt; control channel failure during RSVP-TE recovery process, etc.<br>
<br>
Is there a need to distinguish between signalling channels and control
channels ?</font></blockquote><br>
Yes, e.g., RSVP recovery procedure differentiate between the control
channel failures and the <font size=3D3>signalling channel (Nodal) failure.
<br>
<br>
<blockquote type=3Dcite cite>Can't they make use of the same IP network
?</font></blockquote><br>
<font size=3D3>Yes, they use the same IP (Control) network, but there are
differences in the two failure cases, e.g., when a peering RSVP process
fails vs. peering LMP process fails, control channel(s) failure due to
peering node failure vs. control channel(s) failure due to an event that
made neighboring node unreachable, etc.<br>
<br>
<br>
<br>
<blockquote type=3Dcite cite>&gt; Hence, LMP Hellos should be faster than
RSVP Hellos or the mechanism used to<br>
&gt; detect signaling channel failure. Similarly, LMP Hello frequency
should<br>
&gt; be greater than IGP hello frequency, so that the optical network can
make<br>
&gt; &quot;conscious&quot; decision on the control channel failure,
before having an adverse<br>
&gt; affect on the IGP adjacencies at L3.<br>
<br>
Indeed. This added complexity makes me questioning if we really need
&quot;control<br>
channel management&quot;.</font></blockquote><br>
When we lose the last control channel with a given neighbor, we lose LMP
adjacency with that neighbor. This is an event that IMO requires proper
treatment from GMPLS control plane. <br>
<br>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D3>&gt; &gt; As stated in section 1=
3
of the LMP draft, all LMP messages are<br>
&gt; &gt; IP encoded. So a standard general purpose IP network
should<br>
&gt; &gt; perfectly well be capable to transport such IP encoded=20
LMP<br>
&gt; &gt; messages to the intended destination. Am I missing
something<br>
&gt; &gt; here ?<br>
&gt; <br>
&gt; I am sorry but I did not understand what you meant here?<br>
<br>
This is in reaction to Jonathans question in another thread:<br>
&nbsp;
<a href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html"=
 eudora=3D"autourl">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html=
</a><br>
My feeling is that standard network layer mechanisms are=20
sufficient.<br>
<br>
<br>
Regards,<br>
<br>
Michiel<br>
<br>
Zafar Ali wrote:<br>
&gt; <br>
&gt; Hi Michiel,<br>
&gt; <br>
&gt; Please see some comments in-lined.<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Regards... Zafar<br>
&gt; <br>
&gt; At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:<br>
&gt; <br>
&gt; &gt; Hello Manoj, Ravi, Jonathan, Zafar,<br>
&gt; &gt;<br>
&gt; &gt; I'm somewhat confused on the state of this thread. As far as
I<br>
&gt; &gt; can see, the following questions are still open:<br>
&gt; &gt; - why is control channel management needed at all ?<br>
&gt; <br>
&gt; The control channel failure detection mechanism is required if
lower-level mechanisms are NOT available to detect control channel
failures. E.g., when control channel is (IP) routed and not bound with a
particular interface. Furthermore, a control channel failure is an event
on which applications<br>
&gt; are interested in from various prospective. E.g., we would like to
distinguish between signalling channel failure and control channel
failure during RSVP-TE recovery process, etc.<br>
&gt; <br>
&gt; &gt; - why does control channel management need to be fast ?<br>
&gt; <br>
&gt; A note on the frequency of LMP Hellos: Please note that we need to
distinguish between a signaling channel failure and the control channel
failure. Hence, LMP Hellos should be faster than RSVP Hellos or the
mechanism used to detect signaling channel failure. Similarly, LMP Hello
frequency should<br>
&gt; be greater than IGP hello frequency, so that the optical network can
make &quot;conscious&quot; decision on the control channel failure,
before having an adverse affect on the IGP adjacencies at L3.<br>
&gt; <br>
&gt; &gt; - is control channel management fast ?<br>
&gt; <br>
&gt; I think the LMP Hello frequency need to follow the above mentioned
criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP
Hellos need to be &quot;fast&quot;.<br>
&gt; <br>
&gt; &gt; As stated in section 13 of the LMP draft, all LMP messages
are<br>
&gt; &gt; IP encoded. So a standard general purpose IP network
should<br>
&gt; &gt; perfectly well be capable to transport such IP encoded=20
LMP<br>
&gt; &gt; messages to the intended destination. Am I missing
something<br>
&gt; &gt; here ?<br>
&gt; <br>
&gt; I am sorry but I did not understand what you meant here?<br>
&gt; <br>
&gt; &gt; One of the advantages of using a general purpose IP network
is<br>
&gt; &gt; that there is no need for a point-to-point direct
communication<br>
&gt; &gt; channel between sender and destination. point-to-point
direct<br>
&gt; &gt; communication can become a problem, e.g. when the dataLink is
a<br>
&gt; &gt; VC-12 or a VT-1.5.<br>
&gt; &gt;<br>
&gt; &gt; Moreover, control channel management seems to give
unnecessary<br>
&gt; &gt; overhead in case there is only one interface between two<br>
&gt; &gt; neighbouring switches.<br>
&gt; <br>
&gt; IMO when control channels are interface bound (i.e., failure of the
interface means failure in the control channel) and L2 mechanism are
available to for failure detection, we can run LMP Hellos at a lower
frequency and rely on L2 control channel failure detection. But please
note that this is not<br>
&gt; always the case that your control channel are bound to a particular
interface (e.g., IP routed control channels), hence the need for failure
detection within the scope of LMP.<br>
&gt; <br>
&gt; &gt; Just for my curiosity: has MultiLink-PPP (RFC1990) been
considered<br>
&gt; &gt; as alternative for &quot;control channel management&quot; ?
This seems to<br>
&gt; &gt; logically extend the current stack used for IP over DCN.
From<br>
&gt; &gt; ITU-T G.7712: &quot;When carrying only IP over the DCC,
PPPinHDLC<br>
&gt; &gt; framing shall be used as the data-link layer
protocol.&quot;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt;<br>
&gt; &gt; Michiel<br>
&gt; &gt;<br>
&gt; &gt; ...&lt;snip&gt;...</blockquote><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
</font></html>

--=====================_22563855==_.ALT--

Delivery-date: Tue, 23 Apr 2002 07:35:19 -0700
To: [email-masked]
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-06.txt
Date: Tue, 23 Apr 2002 07:34:37 -0700
From: Yakov Rekhter <[email-masked]>

Folks,

draft-ietf-ccamp-ospf-gmpls-extensions-06.txt reflects the comments
received during the WG last call.

Yakov.
------- Forwarded Message

Date:    Tue, 23 Apr 2002 07:12:58 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-06.txt

- --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 G
roup of the IETF.

	Title		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-06.txt
	Pages		: 11
	Date		: 22-Apr-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-06.t
xt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ospf-gmpls-extensions-06.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-06.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Delivery-date: Tue, 23 Apr 2002 07:35:13 -0700
To: [email-masked]
Subject: draft-ietf-ccamp-gmpls-routing-04.txt
Date: Tue, 23 Apr 2002 07:32:03 -0700
From: Yakov Rekhter <[email-masked]>

Folks,

draft-ietf-ccamp-gmpls-routing-04.txt reflects the comments we
received during the WG last call.

Yakov.
------- Forwarded Message

Date:    Tue, 23 Apr 2002 07:13:03 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-04.txt

- --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 G
roup of the IETF.

	Title		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-gmpls-routing-04.txt
	Pages		: 24
	Date		: 22-Apr-02
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-04.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Delivery-date: Tue, 23 Apr 2002 04:14:13 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-02.txt
Date: Tue, 23 Apr 2002 07:12:53 -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 to Control Non-Standard SONET and SDH
                          Features
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-02.txt
	Pages		: 12
	Date		: 22-Apr-02
	
This document is a companion to the GMPLS signaling extensions to 
control SONET and SDH document [GMPLS-SONET-SDH] that defines the 
SONET/SDH technology specific information needed when using GMPLS 
signaling. 
This informational document defines GMPLS signaling extensions to 
control four optional non-standard (i.e. proprietary) SONET and 
SDH features: group signals, arbitrary concatenation, virtual 
concatenation of contiguously concatenated signals and per byte 
transparency.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-extensions-02.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Apr 2002 04:14:10 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-04.txt
Date: Tue, 23 Apr 2002 07:13:03 -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		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-gmpls-routing-04.txt
	Pages		: 24
	Date		: 22-Apr-02
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-routing-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Apr 2002 04:14:04 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-06.txt
Date: Tue, 23 Apr 2002 07:12:58 -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		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-06.txt
	Pages		: 11
	Date		: 22-Apr-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ospf-gmpls-extensions-06.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Apr 2002 04:14:01 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-04.txt
Date: Tue, 23 Apr 2002 07:12:48 -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-04.txt
	Pages		: 21
	Date		: 22-Apr-02
	
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-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Apr 2002 02:17:45 -0700
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Tue, 23 Apr 2002 11:14:50 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hello Zafar,

Thanks for your answers.

You start by stating
  "The control channel failure detection mechanism is required if ...<snip>..."
Does this imply that the "control channel management" procedure is not *always*
required ? I understood from the draft and from Jonathan's answers that "control
channel management" is mandatory.
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html

I can imagine there are cases in which "control channel management" is not
providing benefit:
- In case there is only one DCC channel with the neighboring node.
- In case lower level mechanisms (e.g. MPLS protection or ML-PPP) are available.
Control channel Management seems to give only unnecessary overhead and
complexity in these cases.

Is it possible to make "control channel management" an optional procedure ?

Please find further reactions on your email below:

> E.g., we would like to distinguish between signalling channel failure and
> control channel failure during RSVP-TE recovery process, etc.

Is there a need to distinguish between signalling channels and control channels ?
Can't they make use of the same IP network ?

> Hence, LMP Hellos should be faster than RSVP Hellos or the mechanism used to
> detect signaling channel failure. Similarly, LMP Hello frequency should
> be greater than IGP hello frequency, so that the optical network can make
> "conscious" decision on the control channel failure, before having an adverse
> affect on the IGP adjacencies at L3.

Indeed. This added complexity makes me questioning if we really need "control
channel management".

> > As stated in section 13 of the LMP draft, all LMP messages are
> > IP encoded. So a standard general purpose IP network should
> > perfectly well be capable to transport such IP encoded LMP
> > messages to the intended destination. Am I missing something
> > here ?
> 
> I am sorry but I did not understand what you meant here?

This is in reaction to Jonathans question in another thread:
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html
My feeling is that standard network layer mechanisms are sufficient.

Regards,

Michiel

Zafar Ali wrote:
> 
> Hi Michiel,
> 
> Please see some comments in-lined.
> 
> Thanks
> 
> Regards... Zafar
> 
> At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
> 
> > Hello Manoj, Ravi, Jonathan, Zafar,
> >
> > I'm somewhat confused on the state of this thread. As far as I
> > can see, the following questions are still open:
> > - why is control channel management needed at all ?
> 
> The control channel failure detection mechanism is required if lower-level mechanisms are NOT available to detect control channel failures. E.g., when control channel is (IP) routed and not bound with a particular interface. Furthermore, a control channel failure is an event on which applications
> are interested in from various prospective. E.g., we would like to distinguish between signalling channel failure and control channel failure during RSVP-TE recovery process, etc.
> 
> > - why does control channel management need to be fast ?
> 
> A note on the frequency of LMP Hellos: Please note that we need to distinguish between a signaling channel failure and the control channel failure. Hence, LMP Hellos should be faster than RSVP Hellos or the mechanism used to detect signaling channel failure. Similarly, LMP Hello frequency should
> be greater than IGP hello frequency, so that the optical network can make "conscious" decision on the control channel failure, before having an adverse affect on the IGP adjacencies at L3.
> 
> > - is control channel management fast ?
> 
> I think the LMP Hello frequency need to follow the above mentioned criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP Hellos need to be "fast".
> 
> > As stated in section 13 of the LMP draft, all LMP messages are
> > IP encoded. So a standard general purpose IP network should
> > perfectly well be capable to transport such IP encoded LMP
> > messages to the intended destination. Am I missing something
> > here ?
> 
> I am sorry but I did not understand what you meant here?
> 
> > One of the advantages of using a general purpose IP network is
> > that there is no need for a point-to-point direct communication
> > channel between sender and destination. point-to-point direct
> > communication can become a problem, e.g. when the dataLink is a
> > VC-12 or a VT-1.5.
> >
> > Moreover, control channel management seems to give unnecessary
> > overhead in case there is only one interface between two
> > neighbouring switches.
> 
> IMO when control channels are interface bound (i.e., failure of the interface means failure in the control channel) and L2 mechanism are available to for failure detection, we can run LMP Hellos at a lower frequency and rely on L2 control channel failure detection. But please note that this is not
> always the case that your control channel are bound to a particular interface (e.g., IP routed control channels), hence the need for failure detection within the scope of LMP.
> 
> > Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
> > as alternative for "control channel management" ? This seems to
> > logically extend the current stack used for IP over DCN. From
> > ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
> > framing shall be used as the data-link layer protocol."
> >
> >
> > Regards,
> >
> > Michiel
> >
> > ...<snip>...

Delivery-date: Mon, 22 Apr 2002 16:02:28 -0700
Date: Mon, 22 Apr 2002 18:59:45 -0400
To: "Ravi Ravindran"<[email-masked]>, Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: Question on LMP.
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]

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

Hi Ravi,

Please see comments in-lined.

Thanks

Regards... Zafar

At 03:08 PM 4/22/2002 -0400, Ravi Ravindran wrote:
>hi zafar,
>You have stated that LMP hellos should be fast enough to detect CC failure 
>before the routing and the signalling protocols (belonging to a GMPLS 
>control plane),

I am sorry for the confusion but I was NOT referring to the IGP Hellos in 
GMPLS control network. Instead I was referring to the IGP Hellos that are 
running from a router-to-router in the L3 network that is using the optical 
LSPs (or data bearer channels in the optical network).

>but then what is the action taken by LMP after that, does LMP interact 
>with the L3 protocols (incase there are multiple LMP active CC's b/w two 
>nodes) leading to update of the routing tables.

No,

>how does it prevent loosing IGP hellos (section 3.2) ?
>

Again, please note that I am referring to the L3 adjacency that are 
established from a router-to-router in the L3 network that is using the 
optical LSPs.

Recall, in the case of RSVP-TE, if the last control channel fails and does 
not come back up within "RSVP restart time" or before expiration of 
"cleanup timeout" interval related to the refresh messages, data forwarding 
on the optical LSPs in question can no longer be sustained. Hence, in order 
to avoid such data losses or possible loss of the IGP adjacency, one may 
adapt a conservative approach in reacting to the failure of the last 
control channel, e.g., triggering path/ local protection, a 
make-before-break scheme, etc.  Of course, this is beyond the scope of 
current discussion as well as the LMP draft.

>thanks
>
>Ravi S. Ravindran
>Nortel Networks, Ottawa
>
>
>  -----Original Message-----
>From: Zafar Ali [mailto:[email-masked]]
>Sent: Monday, April 22, 2002 12:47 PM
>To: Michiel van Everdingen
>Cc: Manoj Sontakke; Jonathan Lang; [email-masked]
>Subject: Re: Question on LMP.
>Hi Michiel,
>
>Please see some comments in-lined.
>
>Thanks
>
>Regards... Zafar
>
>At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
>>Hello Manoj, Ravi, Jonathan, Zafar,
>>I'm somewhat confused on the state of this thread. As far as I
>>can see, the following questions are still open:
>>- why is control channel management needed at all ?
>The control channel failure detection mechanism is required if lower-level 
>mechanisms are NOT available to detect control channel failures. E.g., 
>when control channel is (IP) routed and not bound with a particular 
>interface. Furthermore, a control channel failure is an event on which 
>applications are interested in from various prospective. E.g., we would 
>like to distinguish between signalling channel failure and control channel 
>failure during RSVP-TE recovery process, etc.
>
>>- why does control channel management need to be fast ?
>A note on the frequency of LMP Hellos: Please note that we need to 
>distinguish between a signaling channel failure and the control channel 
>failure. Hence, LMP Hellos should be faster than RSVP Hellos or the 
>mechanism used to detect signaling channel failure. Similarly, LMP Hello 
>frequency should be greater than IGP hello frequency, so that the optical 
>network can make "conscious" decision on the control channel failure, 
>before having an adverse affect on the IGP adjacencies at L3.
>
>>- is control channel management fast ?
>I think the LMP Hello frequency need to follow the above mentioned 
>criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP 
>Hellos need to be "fast".
>
>
>
>>As stated in section 13 of the LMP draft, all LMP messages are
>>IP encoded. So a standard general purpose IP network should
>>perfectly well be capable to transport such IP encoded LMP
>>messages to the intended destination. Am I missing something
>>here ?
>I am sorry but I did not understand what you meant here?
>
>
>
>>One of the advantages of using a general purpose IP network is
>>that there is no need for a point-to-point direct communication
>>channel between sender and destination. point-to-point direct
>>communication can become a problem, e.g. when the dataLink is a
>>VC-12 or a VT-1.5.
>>
>>Moreover, control channel management seems to give unnecessary
>>overhead in case there is only one interface between two
>>neighbouring switches.
>IMO when control channels are interface bound (i.e., failure of the 
>interface means failure in the control channel) and L2 mechanism are 
>available to for failure detection, we can run LMP Hellos at a lower 
>frequency and rely on L2 control channel failure detection. But please 
>note that this is not always the case that your control channel are bound 
>to a particular interface (e.g., IP routed control channels), hence the 
>need for failure detection within the scope of LMP.
>
<snip>
=================
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
--=====================_31894842==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Hi Ravi, <br>
<br>
Please see comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
At 03:08 PM 4/22/2002 -0400, Ravi Ravindran wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">hi
zafar,</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">You have stated that LMP
hellos should be fast enough to detect CC failure before the routing and
the signalling protocols (belonging to a GMPLS control plane),
</font></blockquote><br>
I am sorry for the confusion but I was NOT referring to the IGP Hellos in
GMPLS control network. Instead I was referring to the IGP Hellos that are
running from a router-to-router in the L3 network that is using the
optical LSPs (or data bearer channels in the optical network). <br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">but
then what is the action taken by LMP after that, does LMP interact with
the L3 protocols (incase there are multiple LMP active CC's b/w two
nodes) leading to update of the routing tables. 
</font></blockquote><br>
No, <br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">how
does it prevent loosing IGP hellos (section 3.2)
?</font><font size=3><br>
&nbsp;</font></blockquote><br>
Again, please note that I am referring to the L3 adjacency that are
established from a router-to-router in the L3 network that is using the
optical LSPs. <br>
<br>
Recall, in the case of RSVP-TE, if the last control channel fails and
does not come back up within &quot;RSVP restart time&quot; or before
<font size=3>expiration of &quot;cleanup timeout&quot; interval related
to the refresh messages, data forwarding on the optical LSPs in question
can no longer be sustained. Hence, in order to avoid such data losses or
possible loss of the IGP
a</font><font face="Arial, Helvetica" size=3>djacency, </font>one may
adapt a conservative approach in reacting to the failure of the last
control channel, e.g., triggering path/ local protection, a
make-before-break scheme, etc.&nbsp; Of course, this is beyond the scope
of current discussion as well as the LMP draft.&nbsp; <br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">thanks</font><font size=3><br>
<br>
</font><font face="arial" size=2>Ravi S. Ravindran</font><font size=3>
<br>
</font><font face="arial" size=2>Nortel Networks,
Ottawa</font><font size=3> <br>
</font><font face="arial" size=2 color="#0000FF">&nbsp;<br>
</font><font size=3><br>
</font><font face="tahoma" size=2>&nbsp;-----Original Message-----<br>
<b>From:</b> Zafar Ali
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
<b>Sent:</b> Monday, April 22, 2002 12:47 PM<br>
<b>To:</b> Michiel van Everdingen<br>
<b>Cc:</b> Manoj Sontakke; Jonathan Lang; [email-masked]<br>
<b>Subject:</b> Re: Question on LMP.<br>
</font>
<dl><font size=3>
<dd>Hi Michiel, <br>
<br>

<dd>Please see some comments in-lined. <br>
<br>

<dd>Thanks<br>
<br>

<dd>Regards... Zafar <br>
<br>

<dd>At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen
wrote:<blockquote type=cite cite>
<dd>Hello Manoj, Ravi, Jonathan, Zafar,
<dd>I'm somewhat confused on the state of this thread. As far as I
<dd>can see, the following questions are still open:
<dd>- why is control channel management needed at all ?</blockquote>
<dd>The control channel failure detection mechanism is required if
lower-level mechanisms are NOT available to detect control channel
failures. E.g., <u>when control channel is (IP) routed and not bound with
a particular interface.</u> Furthermore, a control channel failure is an
event on which applications are interested in from various prospective.
E.g., we would like to distinguish between signalling channel failure and
control channel failure during RSVP-TE recovery process, etc. <br>
<br>
<blockquote type=cite cite>
<dd>- why does control channel management need to be fast 
?</blockquote>
<dd>A note on the frequency of LMP Hellos: Please note that we need to
distinguish between a signaling channel failure and the control channel
failure. Hence, LMP Hellos should be faster than RSVP Hellos or the
mechanism used to detect signaling channel failure. Similarly, LMP Hello
frequency should be greater than IGP hello frequency, so that the optical
network can make &quot;conscious&quot; decision on the control channel
failure, before having an adverse affect on the IGP adjacencies at
L3.<br>
<br>
<blockquote type=cite cite>
<dd>- is control channel management fast ?</blockquote>
<dd>I think the LMP Hello frequency need to follow the above mentioned
criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP
Hellos need to be &quot;fast&quot;. <br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>As stated in section 13 of the LMP draft, all LMP messages are
<dd>IP encoded. So a standard general purpose IP network should
<dd>perfectly well be capable to transport such IP encoded LMP
<dd>messages to the intended destination. Am I missing something
<dd>here ?</blockquote>
<dd>I am sorry but I did not understand what you meant here? <br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>One of the advantages of using a general purpose IP network is
<dd>that there is no need for a point-to-point direct communication
<dd>channel between sender and destination. point-to-point direct
<dd>communication can become a problem, e.g. when the dataLink is a
<dd>VC-12 or a VT-1.5.<br>
<br>

<dd>Moreover, control channel management seems to give unnecessary
<dd>overhead in case there is only one interface between two
<dd>neighbouring switches.</blockquote>
<dd>IMO when control channels are interface bound (i.e., failure of the
interface means failure in the control channel) and L2 mechanism are
available to for failure detection, we can run LMP Hellos at a lower
frequency and rely on L2 control channel failure detection. But please
note that this is not always the case that your control channel are bound
to a particular interface (e.g., IP routed control channels), hence the
need for failure detection within the scope of LMP. <br>
<br>
</font></blockquote>
</dl>&lt;snip&gt;<br>
=================<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.</html>

--=====================_31894842==_.ALT--

Delivery-date: Mon, 22 Apr 2002 12:13:09 -0700
From: "Ravi Ravindran"<[email-masked]>
To: "'Zafar Ali'" <[email-masked]>, Michiel van Everdingen <[email-masked]>
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Question on LMP.
Date: Mon, 22 Apr 2002 15:08:38 -0400

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

------_=_NextPart_001_01C1EA31.1BD26578
Content-Type: text/plain;
	charset="ISO-8859-1"

hi zafar,
You have stated that LMP hellos should be fast enough to detect CC failure
before the routing and the signalling protocols (belonging to a GMPLS
control plane), but then what is the action taken by LMP after that, does
LMP interact with the L3 protocols (incase there are multiple LMP active
CC's b/w two nodes) leading to update of the routing tables. how does it
prevent loosing IGP hellos (section 3.2) ?
 
thanks

Ravi S. Ravindran 
Nortel Networks, Ottawa 

 -----Original Message-----
From: Zafar Ali [mailto:[email-masked]]
Sent: Monday, April 22, 2002 12:47 PM
To: Michiel van Everdingen
Cc: Manoj Sontakke; Jonathan Lang; [email-masked]
Subject: Re: Question on LMP.

Hi Michiel, 

Please see some comments in-lined. 

Thanks

Regards... Zafar 

At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:

Hello Manoj, Ravi, Jonathan, Zafar,

I'm somewhat confused on the state of this thread. As far as I
can see, the following questions are still open:
- why is control channel management needed at all ?

The control channel failure detection mechanism is required if lower-level
mechanisms are NOT available to detect control channel failures. E.g., when
control channel is (IP) routed and not bound with a particular interface.
Furthermore, a control channel failure is an event on which applications are
interested in from various prospective. E.g., we would like to distinguish
between signalling channel failure and control channel failure during
RSVP-TE recovery process, etc. 

- why does control channel management need to be fast ?

A note on the frequency of LMP Hellos: Please note that we need to
distinguish between a signaling channel failure and the control channel
failure. Hence, LMP Hellos should be faster than RSVP Hellos or the
mechanism used to detect signaling channel failure. Similarly, LMP Hello
frequency should be greater than IGP hello frequency, so that the optical
network can make "conscious" decision on the control channel failure, before
having an adverse affect on the IGP adjacencies at L3.

- is control channel management fast ?

I think the LMP Hello frequency need to follow the above mentioned criteria.
By fast, do you mean O(milliseconds)? If yes, I don't think LMP Hellos need
to be "fast". 

As stated in section 13 of the LMP draft, all LMP messages are
IP encoded. So a standard general purpose IP network should
perfectly well be capable to transport such IP encoded LMP
messages to the intended destination. Am I missing something
here ?

I am sorry but I did not understand what you meant here? 

One of the advantages of using a general purpose IP network is
that there is no need for a point-to-point direct communication
channel between sender and destination. point-to-point direct
communication can become a problem, e.g. when the dataLink is a
VC-12 or a VT-1.5.

Moreover, control channel management seems to give unnecessary
overhead in case there is only one interface between two
neighbouring switches.

IMO when control channels are interface bound (i.e., failure of the
interface means failure in the control channel) and L2 mechanism are
available to for failure detection, we can run LMP Hellos at a lower
frequency and rely on L2 control channel failure detection. But please note
that this is not always the case that your control channel are bound to a
particular interface (e.g., IP routed control channels), hence the need for
failure detection within the scope of LMP. 

Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
as alternative for "control channel management" ? This seems to
logically extend the current stack used for IP over DCN. From
ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
framing shall be used as the data-link layer protocol."

Regards,

Michiel

Zafar Ali wrote:
> 
> At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> 
> > Hi Jonathan,
> >
> > Thanks for the quick response. Please see my comments inline.
> >
> > Manoj
> >
> > Jonathan Lang wrote:
> > >
> > > Manoj,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Manoj Sontakke [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: [email-masked]
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > > --------------------------------------------------------------
> > > > -----------------------------
> > > > Q1.  Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > > >                 -----------------               -----------------
> > > >                 |               |               |               |
> > > >                 |            if1|---------------|if1            |
> > > >                 |            if2|---------------|if2            |
> > > >                 |     OXC 1     |               |     OXC 2     |
> > > >                 |             d1|---------------|d1             |
> > > >                 |             d2|---------------|d2             |
> > > >                 -----------------
> > > > -----------------
> > > >
> > > >
> > > > I have two OXCs connected by four links. Consider d1, d2 are
configured
> > > > to carry data and if1 and if2 are configured to carry control data (
LMP
> > > > messages and RSVP and OSPF messages).
> > > >
> > > > The LMP document defines control channels with an unique identifier
(
> > > > control channel identifier ) between the negibouring nodes.
> > > > So also, the LMP messages are IP encapsulated.
> > > >
> > > > Now, I have a couple of questions
> > > >
> > > > 1. Is there any association between the LMP control channels to the
> > > > physical interfaces( if1, if2). Because all the IP packets are
routed on
> > > > the physical interfaces according to the routing table. The control
> > > > channel messages like  ( config and configAck etc.. ) can go on the
any
> > > > physical interface which is decided by the routing table.
> > > >
> > > > In such case, are the control channels a pure logical concept or do
they
> > > > have any physical interface significance & correlation [ mapping
between
> > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> >
> > > Control channels are associated with interfaces.
> >
> > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > messages are IP encoded. So the routing table decides the outgoing
> > interface for sending the LMP messages (any packet for that matter)
> > depending upon the destination IP address.
> >
> > So is it possible to make such an association between the LMP control
> > channel and a physical interface (though it is desirable)?
> 
> Hi Manoj, et all:
> 
> The association between the CC and data bearer link is neither prevented
nor enforced by the specification, as you also mentioned. IMO, the
association between the CC and data bearer link is a vendor specific
question. Vendors can manage the available set of CCs in the way they would
like to.
> I.e., a vendor may choose a specific CC to send all messages that are
pertaining to a data bearer link, etc. The key is that the receiver node for
the LMP messages should be able to receive LMP messages from any CC that
it's running with a given neighbor. This is of course with the exception of
> LMP Hellos messages.
> 
> > Are we
> > deviating from the standard IP implementation ?
> 
> In selecting the CC by making an association between the CC and the data
link, one will NOT be diverting from IP. Specifically, one may consider CC
to be of two different types: interface bound or routed. E.g., SDCC/ LDCC
based CCs can be regarded as interface bound IPCCs. LMP application can
> select a specific egress interface while using interface bound CCs, etc.
> 
> Thanks
> 
> Regards... Zafar
> 
> <snip>

------_=_NextPart_001_01C1EA31.1BD26578
Content-Type: text/html;
	charset="ISO-8859-1"

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

<META content="MSHTML 5.00.3314.2100" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=189230817-22042002>hi 
zafar,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=189230817-22042002>You 
have stated that LMP hellos should be fast enough to detect CC failure before 
the routing and the signalling protocols (belonging to&nbsp;a&nbsp;GMPLS control 
plane), but then what is the action taken by LMP after that, does 
LMP&nbsp;interact with the  L3 protocols (incase there are multiple LMP active 
CC's b/w two nodes) leading to update of the routing tables. </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=189230817-22042002>how does it 
prevent loosing&nbsp;IGP hellos (section 3.2) ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=189230817-22042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=189230817-22042002></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=189230817-22042002>thanks</SPAN></FONT></DIV>
<P><FONT face=Arial size=2>Ravi S. Ravindran</FONT> <BR><FONT face=Arial 
size=2>Nortel Networks, Ottawa</FONT>&nbsp;<BR><FONT face=Tahoma><FONT 
size=2><SPAN class=189230817-22042002><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></P>
<P><FONT face=Tahoma><FONT size=2><SPAN 
class=189230817-22042002>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Zafar Ali [mailto:[email-masked]]<BR><B>Sent:</B> Monday, April 22, 2002 12:47 
PM<BR><B>To:</B> Michiel van Everdingen<BR><B>Cc:</B> Manoj Sontakke; Jonathan 
Lang; [email-masked]<BR><B>Subject:</B> Re: Question on 
LMP.<BR><BR></P></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT><FONT size=3>Hi Michiel, 
  <BR><BR>Please see some comments in-lined. <BR><BR>Thanks<BR><BR>Regards... 
  Zafar <BR><BR>At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:<BR>
  <BLOCKQUOTE cite type="cite">Hello Manoj, Ravi, Jonathan, Zafar,<BR><BR>I'm 
    somewhat confused on the state of this thread. As far as I<BR>can see, the 
    following questions are still open:<BR>- why is control channel management 
    needed at all ?</FONT></BLOCKQUOTE><BR><FONT size=3>The control channel 
  failure detection mechanism is required if lower-level mechanisms are NOT 
  available to detect control channel failures. E.g., <U>when control channel is 
  (IP) routed and not bound with a particular interface.</U> Furthermore, a 
  control channel failure is an event on which applications are interested in 
  from various prospective. E.g., we would like to distinguish between 
  signalling channel failure and control channel failure during RSVP-TE recovery 
  process, etc. <BR><BR>
  <BLOCKQUOTE cite type="cite">- why does control channel management need to 
    be fast ?</FONT></BLOCKQUOTE><BR><FONT face="Arial, Helvetica" size=3>A note 
  on the frequency of LMP Hellos: Please note that we need to distinguish 
  between a signaling channel failure and the control channel failure. Hence, 
  LMP Hellos should be faster than RSVP Hellos or the mechanism used to detect 
  signaling channel failure. Similarly, LMP Hello frequency should be greater 
  than IGP hello frequency, so that the optical network can make "conscious" 
  decision on the control channel failure, before having an adverse affect on 
  the IGP adjacencies at L3.<BR><BR></FONT>
  <BLOCKQUOTE cite type="cite">- is control channel management fast 
  ?</BLOCKQUOTE><BR><FONT size=3>I think the LMP Hello frequency need to follow 
  the above mentioned criteria. By fast, do you mean O(milliseconds)? If yes, I 
  don't think LMP Hellos need to be "fast". <BR><BR><BR>
  <BLOCKQUOTE cite type="cite">As stated in section 13 of the LMP draft, all 
    LMP messages are<BR>IP encoded. So a standard general purpose IP network 
    should<BR>perfectly well be capable to transport such IP encoded 
    LMP<BR>messages to the intended destination. Am I missing something<BR>here 
    ?</FONT></BLOCKQUOTE><BR><FONT size=3>I am sorry but I did not understand what 
  you meant here? <BR><BR><BR>
  <BLOCKQUOTE cite type="cite">One of the advantages of using a general 
    purpose IP network is<BR>that there is no need for a point-to-point direct 
    communication<BR>channel between sender and destination. point-to-point 
    direct<BR>communication can become a problem, e.g. when the dataLink is 
    a<BR>VC-12 or a VT-1.5.<BR><BR>Moreover, control channel management seems to 
    give unnecessary<BR>overhead in case there is only one interface between 
    two<BR>neighbouring switches.</FONT></BLOCKQUOTE><BR><FONT size=3>IMO when 
  control channels are interface bound (i.e., failure of the interface means 
  failure in the control channel) and L2 mechanism are available to for failure 
  detection, we can run LMP Hellos at a lower frequency and rely on L2 control 
  channel failure detection. But please note that this is not always the case 
  that your control channel are bound to a particular interface (e.g., IP routed 
  control channels), hence the need for failure detection within the scope of 
  LMP. <BR><BR><BR>
  <BLOCKQUOTE cite type="cite">Just for my curiosity: has MultiLink-PPP 
    (RFC1990) been considered<BR>as alternative for "control channel management" 
    ? This seems to<BR>logically extend the current stack used for IP over DCN. 
    From<BR>ITU-T G.7712: "When carrying only IP over the DCC, 
    PPPinHDLC<BR>framing shall be used as the data-link layer 
    protocol."<BR><BR><BR>Regards,<BR><BR>Michiel<BR><BR><BR>Zafar Ali 
    wrote:<BR>&gt; <BR>&gt; At 03:22 PM 4/15/2002 +0530, Manoj Sontakke 
    wrote:<BR>&gt; <BR>&gt; &gt; Hi Jonathan,<BR>&gt; &gt;<BR>&gt; &gt; Thanks 
    for the quick response. Please see my comments inline.<BR>&gt; &gt;<BR>&gt; 
    &gt; Manoj<BR>&gt; &gt;<BR>&gt; &gt; Jonathan Lang wrote:<BR>&gt; &gt; 
    &gt;<BR>&gt; &gt; &gt; Manoj,<BR>&gt; &gt; &gt;&nbsp;&nbsp; Please see 
    inline.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Thanks,<BR>&gt; &gt; &gt; 
    Jonathan<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; -----Original 
    Message-----<BR>&gt; &gt; &gt; &gt; From: Manoj Sontakke [<A 
    href="mailto:[email-masked]" 
    eudora="autourl">mailto:[email-masked]</A>]<BR>&gt; &gt; &gt; &gt; Sent: 
    Thursday, April 11, 2002 7:02 AM<BR>&gt; &gt; &gt; &gt; To: 
    [email-masked]<BR>&gt; &gt; &gt; &gt; Subject: Question on LMP.<BR>&gt; 
    &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Hi,<BR>&gt; 
    &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; I have two questions on LMP.<BR>&gt; 
    &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; 
    --------------------------------------------------------------<BR>&gt; &gt; 
    &gt; &gt; -----------------------------<BR>&gt; &gt; &gt; &gt; Q1.&nbsp; 
    Control Channel Question<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; 
    Assuming a configuration as shown.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; 
    &gt;<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    -----------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    -----------------<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    if1|---------------|if1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    if2|---------------|if2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp; OXC 1&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp; OXC 2&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    d1|---------------|d1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    d2|---------------|d2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |<BR>&gt; &gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    -----------------<BR>&gt; &gt; &gt; &gt; -----------------<BR>&gt; &gt; &gt; 
    &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; I have two OXCs connected 
    by four links. Consider d1, d2 are configured<BR>&gt; &gt; &gt; &gt; to 
    carry data and if1 and if2 are configured to carry control data ( 
    LMP<BR>&gt; &gt; &gt; &gt; messages and RSVP and OSPF messages).<BR>&gt; 
    &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; The LMP document defines control 
    channels with an unique identifier (<BR>&gt; &gt; &gt; &gt; control channel 
    identifier ) between the negibouring nodes.<BR>&gt; &gt; &gt; &gt; So also, 
    the LMP messages are IP encapsulated.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; 
    &gt; &gt; Now, I have a couple of questions<BR>&gt; &gt; &gt; &gt;<BR>&gt; 
    &gt; &gt; &gt; 1. Is there any association between the LMP control channels 
    to the<BR>&gt; &gt; &gt; &gt; physical interfaces( if1, if2). Because all 
    the IP packets are routed on<BR>&gt; &gt; &gt; &gt; the physical interfaces 
    according to the routing table. The control<BR>&gt; &gt; &gt; &gt; channel 
    messages like&nbsp; ( config and configAck etc.. ) can go on the any<BR>&gt; 
    &gt; &gt; &gt; physical interface which is decided by the routing 
    table.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; In such case, are the 
    control channels a pure logical concept or do they<BR>&gt; &gt; &gt; &gt; 
    have any physical interface significance &amp; correlation [ mapping 
    between<BR>&gt; &gt; &gt; &gt; control channles ( ccid ) and interfaces ( 
    if1 and if2 )] ?<BR>&gt; &gt;<BR>&gt; &gt; &gt; Control channels are 
    associated with interfaces.<BR>&gt; &gt;<BR>&gt; &gt; Manoj-&gt; The draft 
    does not say so explicitly. Besides, all the LMP<BR>&gt; &gt; messages are 
    IP encoded. So the routing table decides the outgoing<BR>&gt; &gt; interface 
    for sending the LMP messages (any packet for that matter)<BR>&gt; &gt; 
    depending upon the destination IP address.<BR>&gt; &gt;<BR>&gt; &gt; So is 
    it possible to make such an association between the LMP control<BR>&gt; &gt; 
    channel and a physical interface (though it is desirable)?<BR>&gt; <BR>&gt; 
    Hi Manoj, et all:<BR>&gt; <BR>&gt; The association between the CC and data 
    bearer link is neither prevented nor enforced by the specification, as you 
    also mentioned. IMO, the association between the CC and data bearer link is 
    a vendor specific question. Vendors can manage the available set of CCs in 
    the way they would like to.<BR>&gt; I.e., a vendor may choose a specific CC 
    to send all messages that are pertaining to a data bearer link, etc. The key 
    is that the receiver node for the LMP messages should be able to receive LMP 
    messages from any CC that it's running with a given neighbor. This is of 
    course with the exception of<BR>&gt; LMP Hellos messages.<BR>&gt; <BR>&gt; 
    &gt; Are we<BR>&gt; &gt; deviating from the standard IP implementation 
    ?<BR>&gt; <BR>&gt; In selecting the CC by making an association between the 
    CC and the data link, one will NOT be diverting from IP. Specifically, one 
    may consider CC to be of two different types: interface bound or routed. 
    E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP 
    application can<BR>&gt; select a specific egress interface while using 
    interface bound CCs, etc.<BR>&gt; <BR>&gt; Thanks<BR>&gt; <BR>&gt; 
    Regards... Zafar<BR>&gt; <BR>&gt; 
&lt;snip&gt;</FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1EA31.1BD26578--

Delivery-date: Mon, 22 Apr 2002 09:52:06 -0700
Date: Mon, 22 Apr 2002 12:47:23 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]

--=====================_9573626==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Michiel,

Please see some comments in-lined.

Thanks

Regards... Zafar

At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
>Hello Manoj, Ravi, Jonathan, Zafar,
>
>I'm somewhat confused on the state of this thread. As far as I
>can see, the following questions are still open:
>- why is control channel management needed at all ?

The control channel failure detection mechanism is required if lower-level=
=20
mechanisms are NOT available to detect control channel failures. E.g., when=
=20
control channel is (IP) routed and not bound with a particular interface.=20
Furthermore, a control channel failure is an event on which applications=20
are interested in from various prospective. E.g., we would like to=20
distinguish between signalling channel failure and control channel failure=
=20
during RSVP-TE recovery process, etc.

>- why does control channel management need to be fast ?

A note on the frequency of LMP Hellos: Please note that we need to=20
distinguish between a signaling channel failure and the control channel=20
failure. Hence, LMP Hellos should be faster than RSVP Hellos or the=20
mechanism used to detect signaling channel failure. Similarly, LMP Hello=20
frequency should be greater than IGP hello frequency, so that the optical=20
network can make "conscious" decision on the control channel failure,=20
before having an adverse affect on the IGP adjacencies at L3.

>- is control channel management fast ?

I think the LMP Hello frequency need to follow the above mentioned=20
criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP=20
Hellos need to be "fast".

>As stated in section 13 of the LMP draft, all LMP messages are
>IP encoded. So a standard general purpose IP network should
>perfectly well be capable to transport such IP encoded LMP
>messages to the intended destination. Am I missing something
>here ?

I am sorry but I did not understand what you meant here?

>One of the advantages of using a general purpose IP network is
>that there is no need for a point-to-point direct communication
>channel between sender and destination. point-to-point direct
>communication can become a problem, e.g. when the dataLink is a
>VC-12 or a VT-1.5.
>
>Moreover, control channel management seems to give unnecessary
>overhead in case there is only one interface between two
>neighbouring switches.

IMO when control channels are interface bound (i.e., failure of the=20
interface means failure in the control channel) and L2 mechanism are=20
available to for failure detection, we can run LMP Hellos at a lower=20
frequency and rely on L2 control channel failure detection. But please note=
=20
that this is not always the case that your control channel are bound to a=20
particular interface (e.g., IP routed control channels), hence the need for=
=20
failure detection within the scope of LMP.

>Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
>as alternative for "control channel management" ? This seems to
>logically extend the current stack used for IP over DCN. From
>ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
>framing shall be used as the data-link layer protocol."
>
>
>Regards,
>
>Michiel
>
>
>Zafar Ali wrote:
> >
> > At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> >
> > > Hi Jonathan,
> > >
> > > Thanks for the quick response. Please see my comments inline.
> > >
> > > Manoj
> > >
> > > Jonathan Lang wrote:
> > > >
> > > > Manoj,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Manoj Sontakke [mailto:[email-masked]]
> > > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > > To: [email-masked]
> > > > > Subject: Question on LMP.
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have two questions on LMP.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > -----------------------------
> > > > > Q1.  Control Channel Question
> > > > >
> > > > > Assuming a configuration as shown.
> > > > >
> > > > >
> > > > >                 -----------------               -----------------
> > > > >                 |               |               |               |
> > > > >                 |            if1|---------------|if1            |
> > > > >                 |            if2|---------------|if2            |
> > > > >                 |     OXC 1     |               |     OXC 2     |
> > > > >                 |             d1|---------------|d1             |
> > > > >                 |             d2|---------------|d2             |
> > > > >                 -----------------
> > > > > -----------------
> > > > >
> > > > >
> > > > > I have two OXCs connected by four links. Consider d1, d2 are=20
> configured
> > > > > to carry data and if1 and if2 are configured to carry control=20
> data ( LMP
> > > > > messages and RSVP and OSPF messages).
> > > > >
> > > > > The LMP document defines control channels with an unique=
 identifier (
> > > > > control channel identifier ) between the negibouring nodes.
> > > > > So also, the LMP messages are IP encapsulated.
> > > > >
> > > > > Now, I have a couple of questions
> > > > >
> > > > > 1. Is there any association between the LMP control channels to=
 the
> > > > > physical interfaces( if1, if2). Because all the IP packets are=20
> routed on
> > > > > the physical interfaces according to the routing table. The=
 control
> > > > > channel messages like  ( config and configAck etc.. ) can go on=20
> the any
> > > > > physical interface which is decided by the routing table.
> > > > >
> > > > > In such case, are the control channels a pure logical concept or=
=20
> do they
> > > > > have any physical interface significance & correlation [ mapping=
=20
> between
> > > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> > >
> > > > Control channels are associated with interfaces.
> > >
> > > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > > messages are IP encoded. So the routing table decides the outgoing
> > > interface for sending the LMP messages (any packet for that matter)
> > > depending upon the destination IP address.
> > >
> > > So is it possible to make such an association between the LMP control
> > > channel and a physical interface (though it is desirable)?
> >
> > Hi Manoj, et all:
> >
> > The association between the CC and data bearer link is neither=20
> prevented nor enforced by the specification, as you also mentioned. IMO,=
=20
> the association between the CC and data bearer link is a vendor specific=
=20
> question. Vendors can manage the available set of CCs in the way they=20
> would like to.
> > I.e., a vendor may choose a specific CC to send all messages that are=20
> pertaining to a data bearer link, etc. The key is that the receiver node=
=20
> for the LMP messages should be able to receive LMP messages from any CC=20
> that it=92s running with a given neighbor. This is of course with the=20
> exception of
> > LMP Hellos messages.
> >
> > > Are we
> > > deviating from the standard IP implementation ?
> >
> > In selecting the CC by making an association between the CC and the=20
> data link, one will NOT be diverting from IP. Specifically, one may=20
> consider CC to be of two different types: interface bound or routed.=20
> E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP=
=20
> application can
> > select a specific egress interface while using interface bound CCs, etc.
> >
> > Thanks
> >
> > Regards=85 Zafar
> >
> > <snip>

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

<html>
<font size=3D3>Hi Michiel, <br>
<br>
Please see some comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:<br>
<blockquote type=3Dcite cite>Hello Manoj, Ravi, Jonathan, Zafar,<br>
<br>
I'm somewhat confused on the state of this thread. As far as I<br>
can see, the following questions are still open:<br>
- why is control channel management needed at all
?</font></blockquote><br>
<font size=3D3>The control channel failure detection mechanism is required
if lower-level mechanisms are NOT available to detect control channel
failures. E.g., <u>when control channel is (IP) routed and not bound with
a particular interface.</u> Furthermore, a control channel failure is an
event on which applications are interested in from various prospective.
E.g., we would like to distinguish between signalling channel failure and
control channel failure during RSVP-TE recovery process, etc. <br>
<br>
<blockquote type=3Dcite cite>- why does control channel management need to
be fast ?</font></blockquote><br>
<font face=3D"Arial, Helvetica" size=3D3>A note on the frequency of LMP
Hellos: Please note that we need to distinguish between a signaling
channel failure and the control channel failure. Hence, LMP Hellos should
be faster than RSVP Hellos or the mechanism used to detect signaling
channel failure. Similarly, LMP Hello frequency should be greater than
IGP hello frequency, so that the optical network can make
&quot;conscious&quot; decision on the control channel failure, before
having an adverse affect on the IGP adjacencies at L3.<br>
<br>
</font><blockquote type=3Dcite cite>- is control channel management fast
?</blockquote><br>
<font size=3D3>I think the LMP Hello frequency need to follow the above
mentioned criteria. By fast, do you mean O(milliseconds)? If yes, I don't
think LMP Hellos need to be &quot;fast&quot;. <br>
<br>
<br>
<blockquote type=3Dcite cite>As stated in section 13 of the LMP draft, all
LMP messages are<br>
IP encoded. So a standard general purpose IP network should<br>
perfectly well be capable to transport such IP encoded LMP<br>
messages to the intended destination. Am I missing something<br>
here ?</font></blockquote><br>
<font size=3D3>I am sorry but I did not understand what you meant here?
<br>
<br>
<br>
<blockquote type=3Dcite cite>One of the advantages of using a general
purpose IP network is<br>
that there is no need for a point-to-point direct communication<br>
channel between sender and destination. point-to-point direct<br>
communication can become a problem, e.g. when the dataLink is a<br>
VC-12 or a VT-1.5.<br>
<br>
Moreover, control channel management seems to give unnecessary<br>
overhead in case there is only one interface between two<br>
neighbouring switches.</font></blockquote><br>
<font size=3D3>IMO when control channels are interface bound (i.e., failure
of the interface means failure in the control channel) and L2 mechanism
are available to for failure detection, we can run LMP Hellos at a lower
frequency and rely on L2 control channel failure detection. But please
note that this is not always the case that your control channel are bound
to a particular interface (e.g., IP routed control channels), hence the
need for failure detection within the scope of LMP. <br>
<br>
<br>
<blockquote type=3Dcite cite>Just for my curiosity: has MultiLink-PPP
(RFC1990) been considered<br>
as alternative for &quot;control channel management&quot; ? This seems
to<br>
logically extend the current stack used for IP over DCN. From<br>
ITU-T G.7712: &quot;When carrying only IP over the DCC, PPPinHDLC<br>
framing shall be used as the data-link layer protocol.&quot;<br>
<br>
<br>
Regards,<br>
<br>
Michiel<br>
<br>
<br>
Zafar Ali wrote:<br>
&gt; <br>
&gt; At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:<br>
&gt; <br>
&gt; &gt; Hi Jonathan,<br>
&gt; &gt;<br>
&gt; &gt; Thanks for the quick response. Please see my comments
inline.<br>
&gt; &gt;<br>
&gt; &gt; Manoj<br>
&gt; &gt;<br>
&gt; &gt; Jonathan Lang wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Manoj,<br>
&gt; &gt; &gt;&nbsp;&nbsp; Please see inline.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; &gt; From: Manoj Sontakke
[<a href=3D"mailto:[email-masked]"=
 eudora=3D"autourl">mailto:[email-masked]</a>]<br>
&gt; &gt; &gt; &gt; Sent: Thursday, April 11, 2002 7:02 AM<br>
&gt; &gt; &gt; &gt; To: [email-masked]<br>
&gt; &gt; &gt; &gt; Subject: Question on LMP.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I have two questions on LMP.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;
--------------------------------------------------------------<br>
&gt; &gt; &gt; &gt; -----------------------------<br>
&gt; &gt; &gt; &gt; Q1.&nbsp; Control Channel Question<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Assuming a configuration as shown.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if1|---------------|if1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if2|---------------|if2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 1&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 2&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d1|---------------|d1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d2|---------------|d2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt; &gt; &gt; &gt; -----------------<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I have two OXCs connected by four links. Consider d1,
d2 are configured<br>
&gt; &gt; &gt; &gt; to carry data and if1 and if2 are configured to carry
control data ( LMP<br>
&gt; &gt; &gt; &gt; messages and RSVP and OSPF messages).<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The LMP document defines control channels with an
unique identifier (<br>
&gt; &gt; &gt; &gt; control channel identifier ) between the negibouring
nodes.<br>
&gt; &gt; &gt; &gt; So also, the LMP messages are IP encapsulated.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Now, I have a couple of questions<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 1. Is there any association between the LMP control
channels to the<br>
&gt; &gt; &gt; &gt; physical interfaces( if1, if2). Because all the IP
packets are routed on<br>
&gt; &gt; &gt; &gt; the physical interfaces according to the routing
table. The control<br>
&gt; &gt; &gt; &gt; channel messages like&nbsp; ( config and configAck
etc.. ) can go on the any<br>
&gt; &gt; &gt; &gt; physical interface which is decided by the routing
table.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; In such case, are the control channels a pure logical
concept or do they<br>
&gt; &gt; &gt; &gt; have any physical interface significance &amp;
correlation [ mapping between<br>
&gt; &gt; &gt; &gt; control channles ( ccid ) and interfaces ( if1 and
if2 )] ?<br>
&gt; &gt;<br>
&gt; &gt; &gt; Control channels are associated with interfaces.<br>
&gt; &gt;<br>
&gt; &gt; Manoj-&gt; The draft does not say so explicitly. Besides, all
the LMP<br>
&gt; &gt; messages are IP encoded. So the routing table decides the
outgoing<br>
&gt; &gt; interface for sending the LMP messages (any packet for that
matter)<br>
&gt; &gt; depending upon the destination IP address.<br>
&gt; &gt;<br>
&gt; &gt; So is it possible to make such an association between the LMP
control<br>
&gt; &gt; channel and a physical interface (though it is=20
desirable)?<br>
&gt; <br>
&gt; Hi Manoj, et all:<br>
&gt; <br>
&gt; The association between the CC and data bearer link is neither
prevented nor enforced by the specification, as you also mentioned. IMO,
the association between the CC and data bearer link is a vendor specific
question. Vendors can manage the available set of CCs in the way they
would like to.<br>
&gt; I.e., a vendor may choose a specific CC to send all messages that
are pertaining to a data bearer link, etc. The key is that the receiver
node for the LMP messages should be able to receive LMP messages from any
CC that it=92s running with a given neighbor. This is of course with the
exception of<br>
&gt; LMP Hellos messages.<br>
&gt; <br>
&gt; &gt; Are we<br>
&gt; &gt; deviating from the standard IP implementation ?<br>
&gt; <br>
&gt; In selecting the CC by making an association between the CC and the
data link, one will NOT be diverting from IP. Specifically, one may
consider CC to be of two different types: interface bound or routed.
E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP
application can<br>
&gt; select a specific egress interface while using interface bound CCs,
etc.<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Regards=85 Zafar<br>
&gt; <br>
&gt; &lt;snip&gt;</font></blockquote></html>

--=====================_9573626==_.ALT--

Delivery-date: Mon, 22 Apr 2002 06:51:24 -0700
From: Manoj Agiwal <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Admin Status Object / NHOP in GMPLS
Date: Mon, 22 Apr 2002 19:04:36 +0530

[ post by non-subscriber ]

Hi ,	
      As per RSVP-TE ( mpls )  there  can be multiple fixed filter flow
descriptor in a single Resv message .
      As per new Generalized MPLS RSVP-TE Resv message we have just one
Admin Status. There is no 
      means of knowing this Admin Status corresponds to which Fixed Filter
Flow Descriptor carried in the 
      Resv message .
     
      Do we assume in GMPLS that RSVP Resv message carries only one Fixed
Filter Flow Desc ?

      The same holds true for NHOP in Resv message . There can be different
data links for each fixed filter flow descriptor .

      Generalized RSVP-TE Draft Section 8.1.2 says 

     "A node receiving one or more TLVs in a Path message saves their values
and returns them
   in the HOP objects of subsequent Resv messages sent to the node that
originated the TLVs."

   In this case there are multiple Path states in the same session , all are
of Type FF . Therefore which Path message 
      IF_ID_RSVP_HOP object will be carried in the Resv message . 

     Again do we assume in GMPLS that RSVP Resv message carries only one
Fixed Filter Flow Desc ? 

     Do we have any possibilities in GMPLS of multiple Path states in the
same session , all of type FF . If yes do we send 
     different Resv messages for each FF flow descriptor .

Regards ,
Manoj

Delivery-date: Mon, 22 Apr 2002 00:34:02 -0700
Date: Mon, 22 Apr 2002 13:02:26 +0530
From: Manoj Sontakke <[email-masked]>
Organization: Sasken Communication Technologies Ltd.
To: Michiel van Everdingen <[email-masked]>
CC: Zafar Ali <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hi All,

Q. What does the control channl management achieve?

A. 1. IP reachability confirmation.
   2. Negotiation of Hello and Dead intervals.

I don't see anything else being achieved by the control channel
management.
Now, lets try to answer the questions.

Regards,
Manoj

Michiel van Everdingen wrote:
> 
> Hello Manoj, Ravi, Jonathan, Zafar,
> 
> I'm somewhat confused on the state of this thread. As far as I
> can see, the following questions are still open:
> - why is control channel management needed at all ?
> - why does control channel management need to be fast ?
> - is control channel management fast ?
> 
> As stated in section 13 of the LMP draft, all LMP messages are
> IP encoded. So a standard general purpose IP network should
> perfectly well be capable to transport such IP encoded LMP
> messages to the intended destination. Am I missing something
> here ?
> 
> One of the advantages of using a general purpose IP network is
> that there is no need for a point-to-point direct communication
> channel between sender and destination. point-to-point direct
> communication can become a problem, e.g. when the dataLink is a
> VC-12 or a VT-1.5.
> 
> Moreover, control channel management seems to give unnecessary
> overhead in case there is only one interface between two
> neighbouring switches.
> 
> Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
> as alternative for "control channel management" ? This seems to
> logically extend the current stack used for IP over DCN. From
> ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
> framing shall be used as the data-link layer protocol."
> 
> Regards,
> 
> Michiel
> 
> Zafar Ali wrote:
> >
> > At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> >
> > > Hi Jonathan,
> > >
> > > Thanks for the quick response. Please see my comments inline.
> > >
> > > Manoj
> > >
> > > Jonathan Lang wrote:
> > > >
> > > > Manoj,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Manoj Sontakke [mailto:[email-masked]]
> > > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > > To: [email-masked]
> > > > > Subject: Question on LMP.
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have two questions on LMP.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > -----------------------------
> > > > > Q1.  Control Channel Question
> > > > >
> > > > > Assuming a configuration as shown.
> > > > >
> > > > >
> > > > >                 -----------------               -----------------
> > > > >                 |               |               |               |
> > > > >                 |            if1|---------------|if1            |
> > > > >                 |            if2|---------------|if2            |
> > > > >                 |     OXC 1     |               |     OXC 2     |
> > > > >                 |             d1|---------------|d1             |
> > > > >                 |             d2|---------------|d2             |
> > > > >                 -----------------
> > > > > -----------------
> > > > >
> > > > >
> > > > > I have two OXCs connected by four links. Consider d1, d2 are configured
> > > > > to carry data and if1 and if2 are configured to carry control data ( LMP
> > > > > messages and RSVP and OSPF messages).
> > > > >
> > > > > The LMP document defines control channels with an unique identifier (
> > > > > control channel identifier ) between the negibouring nodes.
> > > > > So also, the LMP messages are IP encapsulated.
> > > > >
> > > > > Now, I have a couple of questions
> > > > >
> > > > > 1. Is there any association between the LMP control channels to the
> > > > > physical interfaces( if1, if2). Because all the IP packets are routed on
> > > > > the physical interfaces according to the routing table. The control
> > > > > channel messages like  ( config and configAck etc.. ) can go on the any
> > > > > physical interface which is decided by the routing table.
> > > > >
> > > > > In such case, are the control channels a pure logical concept or do they
> > > > > have any physical interface significance & correlation [ mapping between
> > > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> > >
> > > > Control channels are associated with interfaces.
> > >
> > > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > > messages are IP encoded. So the routing table decides the outgoing
> > > interface for sending the LMP messages (any packet for that matter)
> > > depending upon the destination IP address.
> > >
> > > So is it possible to make such an association between the LMP control
> > > channel and a physical interface (though it is desirable)?
> >
> > Hi Manoj, et all:
> >
> > The association between the CC and data bearer link is neither prevented nor enforced by the specification, as you also mentioned. IMO, the association between the CC and data bearer link is a vendor specific question. Vendors can manage the available set of CCs in the way they would like to.
> > I.e., a vendor may choose a specific CC to send all messages that are pertaining to a data bearer link, etc. The key is that the receiver node for the LMP messages should be able to receive LMP messages from any CC that it’s running with a given neighbor. This is of course with the exception of
> > LMP Hellos messages.
> >
> > > Are we
> > > deviating from the standard IP implementation ?
> >
> > In selecting the CC by making an association between the CC and the data link, one will NOT be diverting from IP. Specifically, one may consider CC to be of two different types: interface bound or routed. E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP application can
> > select a specific egress interface while using interface bound CCs, etc.
> >
> > Thanks
> >
> > Regards… Zafar
> >
> > <snip>

Delivery-date: Sun, 21 Apr 2002 23:33:38 -0700
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Mon, 22 Apr 2002 08:32:53 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hello Manoj, Ravi, Jonathan, Zafar,

I'm somewhat confused on the state of this thread. As far as I
can see, the following questions are still open:
- why is control channel management needed at all ?
- why does control channel management need to be fast ?
- is control channel management fast ?

As stated in section 13 of the LMP draft, all LMP messages are
IP encoded. So a standard general purpose IP network should
perfectly well be capable to transport such IP encoded LMP
messages to the intended destination. Am I missing something
here ?

One of the advantages of using a general purpose IP network is
that there is no need for a point-to-point direct communication
channel between sender and destination. point-to-point direct
communication can become a problem, e.g. when the dataLink is a
VC-12 or a VT-1.5.

Moreover, control channel management seems to give unnecessary
overhead in case there is only one interface between two
neighbouring switches.

Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
as alternative for "control channel management" ? This seems to
logically extend the current stack used for IP over DCN. From
ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
framing shall be used as the data-link layer protocol."

Regards,

Michiel

Zafar Ali wrote:
> =

> At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> =

> > Hi Jonathan,
> >
> > Thanks for the quick response. Please see my comments inline.
> >
> > Manoj
> >
> > Jonathan Lang wrote:
> > >
> > > Manoj,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Manoj Sontakke [mailto:[email-masked]]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: [email-masked]
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > > --------------------------------------------------------------
> > > > -----------------------------
> > > > Q1.  Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > > >                 -----------------               -----------------=

> > > >                 |               |               |               |=

> > > >                 |            if1|---------------|if1            |=

> > > >                 |            if2|---------------|if2            |=

> > > >                 |     OXC 1     |               |     OXC 2     |=

> > > >                 |             d1|---------------|d1             |=

> > > >                 |             d2|---------------|d2             |=

> > > >                 -----------------
> > > > -----------------
> > > >
> > > >
> > > > I have two OXCs connected by four links. Consider d1, d2 are conf=
igured
> > > > to carry data and if1 and if2 are configured to carry control dat=
a ( LMP
> > > > messages and RSVP and OSPF messages).
> > > >
> > > > The LMP document defines control channels with an unique identifi=
er (
> > > > control channel identifier ) between the negibouring nodes.
> > > > So also, the LMP messages are IP encapsulated.
> > > >
> > > > Now, I have a couple of questions
> > > >
> > > > 1. Is there any association between the LMP control channels to t=
he
> > > > physical interfaces( if1, if2). Because all the IP packets are ro=
uted on
> > > > the physical interfaces according to the routing table. The contr=
ol
> > > > channel messages like  ( config and configAck etc.. ) can go on t=
he any
> > > > physical interface which is decided by the routing table.
> > > >
> > > > In such case, are the control channels a pure logical concept or =
do they
> > > > have any physical interface significance & correlation [ mapping =
between
> > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> >
> > > Control channels are associated with interfaces.
> >
> > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > messages are IP encoded. So the routing table decides the outgoing
> > interface for sending the LMP messages (any packet for that matter)
> > depending upon the destination IP address.
> >
> > So is it possible to make such an association between the LMP control=

> > channel and a physical interface (though it is desirable)?
> =

> Hi Manoj, et all:
> =

> The association between the CC and data bearer link is neither prevente=
d nor enforced by the specification, as you also mentioned. IMO, the asso=
ciation between the CC and data bearer link is a vendor specific question=
=2E Vendors can manage the available set of CCs in the way they would lik=
e to.
> I.e., a vendor may choose a specific CC to send all messages that are p=
ertaining to a data bearer link, etc. The key is that the receiver node f=
or the LMP messages should be able to receive LMP messages from any CC th=
at it=92s running with a given neighbor. This is of course with the excep=
tion of
> LMP Hellos messages.
> =

> > Are we
> > deviating from the standard IP implementation ?
> =

> In selecting the CC by making an association between the CC and the dat=
a link, one will NOT be diverting from IP. Specifically, one may consider=
 CC to be of two different types: interface bound or routed. E.g., SDCC/ =
LDCC based CCs can be regarded as interface bound IPCCs. LMP application =
can
> select a specific egress interface while using interface bound CCs, etc=
=2E
> =

> Thanks
> =

> Regards=85 Zafar
> =

> <snip>

Delivery-date: Sun, 21 Apr 2002 23:11:28 -0700
Date: Mon, 22 Apr 2002 08:10:26 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: applicability of LMP's verify procedure

Hello all,

My feeling is that the verify procedure as described in LMP is
only applicable for CTP-->--CTP and CTP-->--TTP dataLinks. The
verify procedure is not applicable for TTP-->--CTP and
TTP-->--TTP dataLinks.
(CTP = Connection Termination Point
 TTP = Trail Termination Point)

Is this correct ?

For example, the verify procedure is not applicable between a
SONET/SDH multiplexer, that starts the STM-n/OC-n dataLink, and
a transparent optical cross connect. I.e. in the figure below:
the verify procedure is not applicable for dataLink 'A'.

+------+      +------+      +------+      +------+
|    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
|      |   A  |      |   B  |      |   C  |      |
|      |      |      |      |      |      |      |
| NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
+------+      +------+      +------+      +------+

According to ITU-T G.831, "the access point identifier should not
change while the access point remains in existence". I.e. in the
example, the SONET/SDH multiplexer has to constantly send out the
same J0 "test-signal".

This behaviour makes sense in my mind as the receiver (NE-2 in the
example) can *always* verify the dataLink: the so-called test-message
is *constantly* sent by the TTP. In other words there is no need to
"start" a verification sequence.

Best regards,

Michiel

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Sun, 21 Apr 2002 23:03:35 -0700
Cc: "[email-masked]'" <[email-masked]>
Date: Mon, 22 Apr 2002 07:59:55 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>
Subject: Re: LMP & neighbor discovery

Hello Jonathan, all,

Does "<snip>" imply that you are not interested in specifying initial
neighbor discovery ? Is this accepted by this working group ?

Somehow I think that would be a pity. My impression is that it would
have been quite easy to copy the text from
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
in an additional section in the LMP draft.

Please let me know if you think I left a question on this text
unanswered.

Thanks,

Michiel

P.S. Jonathan: I will try to answer your question on the control channel
in the thread "Question on LMP".

Jonathan Lang wrote:
> 
> Michiel,
> 
> <snip>
> >
> > Repeating my earlier questions:
> > - Why is 'control channel management' mandatory ?
> > - Why are normal (i.e. not LMP specific) network layer mechanisms not
> >   sufficient ?
> Why do you think they are sufficient?
> 
> Thanks,
> Jonathan
> 
> <...snip...>

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 19 Apr 2002 05:36:40 -0700
From: Heiles Juergen <[email-masked]>
To: "'venkat'" <[email-masked]>, Maarten Vissers <[email-masked]>, Vinay Vernekar <[email-masked]>
Cc: "ccamp+AEA-ops.ietf.org" <[email-masked]>, "gmpls-ops+AEA-mplsrc.com" <[email-masked]>
Subject: RE: Need for hierarchical SONET/SDH LSPs.
Date: Fri, 19 Apr 2002 14:33:12 +0200

Venkat,

see my comments below.

Juergen

+AD4- -----Original Message-----
+AD4- From: Venkat Dabbara +AFs-mailto:venkat.dabb+AEA-wipro.com+AF0-
+AD4- Sent: Thursday, April 18, 2002 7:36 AM
+AD4- To: Maarten Vissers+ADs- Vinay Vernekar
+AD4- Cc: ccamp+AEA-ops.ietf.org+ADs- gmpls-ops+AEA-mplsrc.com
+AD4- Subject: Re: Need for hierarchical SONET/SDH LSPs.
+AD4- 
+AD4- 
+AD4- hai,
+AD4- 
+AD4- I have a question regarding the Sonet/SDH traffic bandwidth encoding
+AD4- 
+AD4- This is in continuation to the scenario which vinay has 
+AD4- mentioned in his mail.
+AD4- Consider three LSRs A, B and C as shown below.
+AD4- 
+AD4- A---------------B---------------C
+AD4- 
+AD4- Now at node A i initiate an LSP creation with SONET/SDH 
+AD4- traffic parameters with elementary
+AD4- signal type as VC-4 and all other fields as zero and MT field 
+AD4- as 1 ofcourse. Precisely i am trying to 
+AD4- create a VC-4 lsp.
+AD4- 
+AD4- Some doubts on the above scene
+AD4- 
+AD4- 1+AD4- Now assume that B supports some sort of concatenation. 
+AD4- Will it matter in any way to the 
+AD4- LSP creation initiated at node A when the request reaches 
+AD4- node B and further ?? 
+AD4- 
No, as you setup a VC-4 LSP concateantion doesn't matter.

+AD4- 2+AD4-  Now when the label request reaches the node C, the 
+AD4- egress, and if that node satisfies the 
+AD4-       bandwidth asked for, then what label will it give to 
+AD4- node B with respect to SUKLM schema
+AD4-       if node C is capable of switching STS-1 level signal. 
+AD4- Will it be with S+AD0-1, U+AD0-1 and others 0 ??
As you ask for a VC-4 or STS-3c-SPE only S is of interest. S can be any number between 1 and  N for a STM-N line signal between B and C. This U would be 1 accordign to the 03 draft in order to indicate a VC-4 and KLM would be 0.

+AD4-       If yes, it means that the label structure is guided by 
+AD4- the type of signal being requested in the
+AD4-       Sonet/Sdh bandwidth encoding.
Yes

+AD4- 
+AD4- 3+AD4- Lastly when a label structure is formed, what sort of 
+AD4- communication will GMPLS do with the link
+AD4-       layer for creation of crossconnect ??

The communication with the cross-connent matrix is internal to the network element. It is not defined as it depends on your specific implementation. Basically the cross-connect matrix at B has to be set in such a way that the VC-4 time slot used for the LSP on the A-B link is connected to the VC-4 time slot used for the LSP on the B-C link.

+AD4- 
+AD4- Please do clarify there doubts 
+AD4- 
+AD4- thanks in advance
+AD4- 
+AD4- regards
+AD4- venkat
+AD4- 
+AD4- 
+AD4- 
+AD4- 
+AD4- 
+AD4- 
+AD4- -----Original Message-----
+AD4- From: Maarten Vissers +ADw-mvissers+AEA-lucent.com+AD4-
+AD4- To: Vinay Vernekar +ADw-vinay.vernekar+AEA-wipro.com+AD4-
+AD4- Cc: ccamp+AEA-ops.ietf.org +ADw-ccamp+AEA-ops.ietf.org+AD4AOw- 
+AD4- gmpls-ops+AEA-mplsrc.com +ADw-gmpls-ops+AEA-mplsrc.com+AD4-
+AD4- Date: Wednesday, April 17, 2002 1:40 AM
+AD4- Subject: Re: Need for hierarchical SONET/SDH LSPs.
+AD4- 
+AD4- 
+AD4- +AD4-Vinay,
+AD4- +AD4-
+AD4- +AD4-I assume that the signal on the fiber between A and B is an 
+AD4- OC-12/STM-4 optical
+AD4- +AD4-signal (carrying the STM-4/STS-12 signal) and on the fiber 
+AD4- between B and C it is
+AD4- +AD4-a OC-48/STM-16 optical signal (carrying the STM-16/STS-48 
+AD4- signal). Nodes A, B
+AD4- +AD4-and C will have HOVC/STS switch fabrics which may support a subset of
+AD4- +AD4-VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c 
+AD4- swtiching+ADs- e.g. A
+AD4- +AD4-node may support VC-4 switching, where as B and C nodes may 
+AD4- support VC-4 and
+AD4- +AD4-VC-4-4c switching.
+AD4- +AD4-
+AD4- +AD4-If all nodes support VC-4/STS-3c switching (and they 
+AD4- typically do) and the
+AD4- +AD4-STM-N/STS-N links between the nodes also support VC-4/STS-3c 
+AD4- link connections
+AD4- +AD4-(also typically the case), then you can setup a VC-4/STS-3c 
+AD4- connection between
+AD4- +AD4-nodes A and C. The VC-4/STS-3c payload is totally 
+AD4- unimportant for this
+AD4- +AD4-connection+ADs- any payload can be present.
+AD4- +AD4-
+AD4- +AD4-Regards,
+AD4- +AD4-
+AD4- +AD4-Maarten
+AD4- +AD4-
+AD4- +AD4APg- Vinay Vernekar wrote:
+AD4- +AD4APg- 
+AD4- +AD4APg- Hi,
+AD4- +AD4APg- Can I have a SONET/SDH LSP that passes through a SONET ADM 
+AD4- as its transit
+AD4- +AD4APg- LSR??
+AD4- +AD4APg- Consider a situation as shown below -
+AD4- +AD4APg- 
+AD4- +AD4APg- A---------------B---------------C
+AD4- +AD4APg- 
+AD4- +AD4APg- The link A-B is a STS-12 link, B does a byte-interleaved 
+AD4- multiplexing of 4
+AD4- +AD4APg- STS-12 and forms a STS-48, thus B-C is STS-48.
+AD4- +AD4APg- Can a LSP for unstructured VC-4 be setup with A as 
+AD4- ingress, B as transit and C
+AD4- +AD4APg- as the egress??
+AD4- +AD4APg- As per the draft +ACI-Framework for GMPLS based control of 
+AD4- SONET/SDH networks+ACI- the
+AD4- +AD4APg- frames are not labeled instead it is the flow that is 
+AD4- being labelled. It also
+AD4- +AD4APg- mentions that tunnels should be used when switching from a 
+AD4- different signal
+AD4- +AD4APg- level i.e VC-12 to VC-4.
+AD4- +AD4APg- With this in mind, I would assume that a LSP as mentioned 
+AD4- should be possible,
+AD4- +AD4APg- because the signal type remains same i.e VC-4 even the 
+AD4- frames get interleaved
+AD4- +AD4APg- from STS-12 to STS-48.
+AD4- +AD4APg- Please correct me if I am wrong.
+AD4- +AD4APg- 
+AD4- +AD4APg- Thanks in advance.
+AD4- +AD4APg- Regards
+AD4- +AD4APg- Vinay
+AD4- +AD4APg- 
+AD4- +AD4APg- 
+AD4- +AD4APg-                            Name: Wipro+AF8-Disclaimer.txt
+AD4- +AD4APg-    Wipro+AF8-Disclaimer.txt    Type: Plain Text (text/plain)
+AD4- +AD4APg-                        Encoding: 7bit
+AD4- 
+AD4- 

Delivery-date: Fri, 19 Apr 2002 02:26:24 -0700
From: [email-masked]
To: [email-masked], [email-masked],  [email-masked]
Subject: RE: Need for hierarchical SONET/SDH LSPs.
Date: Fri, 19 Apr 2002 10:22:45 +0100

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_01C1E783.C40330C0
Content-Type: text/plain;
	charset="ISO-8859-1"

Heinrich...please see below.  regards, Neil

-----Original Message-----
From: Hummel Heinrich [mailto:[email-masked]]
Sent: 19 April 2002 08:33
To: 'Vinay Vernekar'; [email-masked]; [email-masked]
Subject: AW: Need for hierarchical SONET/SDH LSPs.

Vinay,
See also my draft, draft-hummel-mpls-hierarchical-lsp-00.txt: 
An hierarchical LSP (H-LSP) shall concatenate normal LSPs (and/or
hierarchical LSPs of lower hierarchical level) just like an normal LSP
concatenates
physical links. However, it takes some changes in CR-LDP signalling as to
establish hierarchical LSPs:
Explicit Routing: the ingress of the H-LSP provides the complete sequence of
sub H-LSPs to be concatenated (= change in ER-TLV).
Implicit Routing: the ingress (the transit) node of the H-LSP needs to send
the LSP-ID of the first (the next) sub H-LSP to be concatenated (=new TLV).
The messages (LABEL-REQUEST, LABEL-MAPPING,...) have to be sent THRU
"Control-Plane" sub H-LSPs (like thru tunnels) whose endpoints comply with
the
endpoints of the to be concatenated "User Plane" sub H-LSPs.
The  LSP-IDs of the involved "Control-Plane" sub H-LSPs should be derivable
from the LSP-IDs of the involved "User-Plane" sub H-LSPs.
 
I stressed that, based on a small but contiguous partial mesh of LSPs an
effective full mesh can be accomplished by building H-LSPs.
The N-square problem would completely disappear. Costs, i.e. work for the
H-LSPs would only happen at the rim of the network. Indeed the network would
not
even know that the H-LSPs exist, as all messages are tunnelled thru the
"Control Plane" sub H-LSPs.

I would appreciate if more people supported this work on H-LSPs. 
 
NH=> I tried reading your ID some time ago and I could not make any sense of
it....not sure if its the content, the way its written or just that I am
stupid.  However, I also asked a colleague's opinion and he had the same
view.  
 
However, I don't understand what all the fuss is here.....AFAI can tell,
this is not news to trad network operators as we have been creating nested
network hierarchies for years, whose behaviour/manifestation is largely what
you are concluding towards the end of your mail above.  Could I suggest a
read of G.805 on client/server relationships (vertical partitioning), and
please don't overlook the *commercial and technical* aspects of (horizontal)
partitioning within a single layer network, ie who owns what.  One key
observation here is that unless you own all the layers to, and including,
the duct layer network (yes, its truly a network) you can say nothing with
any confidence on resilience......every layer network inherits (recursively)
the immediately lower layer network's connectivity, and this starts with the
duct connectivity.  Corrollary:- Any model that assumes some all-seeing
routing instance across all layers is extremely naive (in a commercial
sense) because no operator is ever going to own all layers to the duct
everywhere.....and as soon as you lease you lose sight of the lower layers,
and I could never imagine any operator would be willing to advertise this
sort of info (even if it was technically feasible, which I doubt).
Conclusion=> so-called peer-models cannot scale beyond a single
wholly-owned-to-the-duct domain....which is somewhat restrictive if you
think about it.
 
The N^2/2 issue is always overplayed, and it *never* goes away despite what
some say.......if site X wants to connect to site Y you must have
connectivity in some form or other in *some* dimension.
 
Further, the *topology* of layer network N (whatever co technology) is
determined by the link connections in that layer (ie adjacent-node 1
hops)....in turn these link connections in layer N are created by trails (=
LSPs = usually many hops) in layer N+1 (ie next lower layer network).  This
relationship recurses all the way to the duct.  Now if you make the trails
in each layer network dynamic (ie set-up on demand), then the topology of
layer N cannot exist until the topology of layer N+1 exists, which in turn
cannot exist until the topology of layer N+2 exists....etc to the duct.  The
key point here is that such layered networks can only be stable and
commercially viable *if* there is a significant increase in the trail
holding times as one approaches the duct......and the duct network itself
has the longest holding times.  We have done the maths on such models ages
ago (can't share them unfortunately) and offering SVC/BoD L1 services does
not create a compelling business case (understatement), which gets worse as
you go lower and lower in the hierarchy.....but I suspect you don't need me
to tell you this, you just have to look (i) at who is currently buying
what/why at L1 (if anything) and (ii) in our industry's press and note who
is going bust.
 
However, if you believe I am overlooking something in the above Heinrich
please enlighten me.
 
regards, Neil

------_=_NextPart_001_01C1E783.C40330C0
Content-Type: text/html;
	charset="ISO-8859-1"

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

<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=360553108-19042002>Heinrich...please see below.&nbsp; regards, 
Neil</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hummel Heinrich 
  [mailto:[email-masked]]<BR><B>Sent:</B> 19 April 2002 
  08:33<BR><B>To:</B> 'Vinay Vernekar'; [email-masked]; 
  [email-masked]<BR><B>Subject:</B> AW: Need for hierarchical SONET/SDH 
  LSPs.<BR><BR></DIV></FONT>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2>Vinay,</FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial size=2>See 
  also my draft, draft-hummel-mpls-hierarchical-lsp-00.txt: </FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial size=2>An 
  hierarchical LSP (H-LSP) shall concatenate normal LSPs (and/or hierarchical 
  LSPs of lower hierarchical level) just like an normal LSP 
  concatenates</FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2>physical links. However, i<SPAN class=554470507-19042002><FONT 
  color=#0000ff face=Arial size=2>t takes some changes in CR-LDP signalling as 
  to establish hierarchical LSPs:</FONT></SPAN></FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2><SPAN class=554470507-19042002>Explicit Routing: the ingress of the 
  H-LSP provides the complete sequence of sub H-LSPs to be concatenated (= 
  change in ER-TLV).</SPAN></FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2><SPAN class=554470507-19042002>Implicit Routing: the ingress (the 
  transit) node&nbsp;of the H-LSP needs to send the LSP-ID of&nbsp;the 
  first&nbsp;(the next) sub H-LSP to be concatenated (=new 
  TLV).</SPAN></FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2><SPAN class=554470507-19042002>The messages (LABEL-REQUEST, 
  LABEL-MAPPING,...) have to be sent THRU "Control-Plane" sub H-LSPs (like thru 
  tunnels) whose endpoints comply with the</SPAN></FONT></SPAN></DIV>
  <DIV><SPAN class=554470507-19042002><FONT color=#0000ff face=Arial 
  size=2><SPAN class=554470507-19042002>endpoints of the to be concatenated 
  "User Plane" sub H-LSPs.</SPAN></FONT></SPAN></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>The&nbsp; LSP-IDs of 
  the involved "Control-Plane" sub H-LSPs</SPAN></SPAN>&nbsp;<SPAN 
  class=554470507-19042002>should be derivable from</SPAN><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>&nbsp;the LSP-IDs of 
  the involved "User-Plane" sub H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN 
  class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>I stressed that, based 
  on a small but contiguous partial mesh of LSPs an effective full mesh can be 
  accomplished by building H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>The N-square problem 
  would completely disappear. Costs, i.e. work for the H-LSPs would only happen 
  at the rim of the network. Indeed the network would 
  not</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>even know that the 
  H-LSPs exist, as all messages are tunnelled thru the "Control Plane" sub 
  H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN 
  class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=554470507-19042002><SPAN 
  class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002>I would appreciate if 
  more people supported this work on H-LSPs.<FONT face="Comic Sans MS"><SPAN 
  class=360553108-19042002>&nbsp;</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>NH=&gt; I tried reading 
  your ID some time ago and I could not make any sense of it....not sure if its 
  the content, the way its written or just that I am stupid.&nbsp; However, I 
  also asked a colleague's opinion and he had the same view.&nbsp; 
  </SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT><FONT 
  size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>However, I don't 
  understand what all the fuss is here.....AFAI can tell, this is&nbsp;not news 
  to trad network operators as we have been creating nested network hierarchies 
  for years, whose behaviour/manifestation is largely what you are concluding 
  towards the end of your mail above.&nbsp; Could I suggest a read of G.805 on 
  client/server relationships (vertical partitioning), and please don't overlook 
  the *commercial and technical* aspects of (horizontal) partitioning within a 
  single layer network, ie who owns what.&nbsp; One key observation here is that 
  unless you own all the layers to, and including, the duct layer network (yes, 
  its truly a network) you can say nothing with any confidence on 
  resilience......every layer network inherits (recursively) the immediately 
  lower layer network's connectivity, and this starts with the duct 
  connectivity.&nbsp; Corrollary:- Any model that assumes some all-seeing 
  routing instance across all layers is extremely naive (in a commercial sense) 
  because no operator is ever going to own all layers to the duct 
  everywhere.....and as soon as you lease you lose sight of the lower layers, 
  and I could never imagine any operator would be willing to advertise this sort 
  of info (even if it was technically feasible, which I doubt).&nbsp; 
  Conclusion=&gt; so-called peer-models cannot scale beyond a single 
  wholly-owned-to-the-duct domain....which is somewhat restrictive if you think 
  about it.</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT><FONT 
  size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>The N^2/2 issue is always 
  overplayed, and it *never* goes away despite what some say.......if site X 
  wants to connect to site Y you must have connectivity in some form or other in 
  *some* dimension.</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>Further, the *topology* of 
  layer network N (whatever co technology) is determined by the link connections 
  in that layer (ie adjacent-node 1 hops)....in turn these link connections in 
  layer N are created by trails (= LSPs = usually many hops) in layer N+1 (ie 
  next lower layer network).&nbsp; This relationship recurses all the way to the 
  duct.&nbsp; Now if you make the trails in each layer network dynamic (ie 
  set-up on demand), then the topology of layer N cannot exist until the 
  topology of layer N+1 exists, which in turn cannot exist until the topology of 
  layer N+2 exists....etc to the duct.&nbsp; The key point here is that such 
  layered networks can only be stable and commercially viable *if* there is a 
  significant increase in the trail holding times as one approaches the 
  duct......and the duct network itself has the longest holding times.&nbsp; We 
  have done the maths on such models ages ago (can't share them unfortunately) 
  and offering SVC/BoD L1 services does not create a compelling business case 
  (understatement), which gets worse as you go lower and lower in the 
  hierarchy.....but I suspect you don't need me to tell you this, you just have 
  to look&nbsp;(i) at who is currently buying what/why at L1 (if anything) and 
  (ii) in our industry's press and note who is going 
  bust.</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>However, if you believe I 
  am overlooking something in the above Heinrich please enlighten 
  me.</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN 
  class=360553108-19042002></SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
  class=554470507-19042002><SPAN class=554470507-19042002><FONT 
  face="Comic Sans MS"><SPAN class=360553108-19042002>regards, 
  Neil</SPAN></FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1E783.C40330C0--

Delivery-date: Fri, 19 Apr 2002 00:38:29 -0700
From: Hummel Heinrich <[email-masked]>
To: "'Vinay Vernekar'" <[email-masked]>, [email-masked], [email-masked]
Subject: AW: Need for hierarchical SONET/SDH LSPs.
Date: Fri, 19 Apr 2002 09:33:30 +0200

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_01C1E774.80C521B0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Vinay,
See also my draft, draft-hummel-mpls-hierarchical-lsp-00.txt:=20
An hierarchical LSP (H-LSP) shall concatenate normal LSPs (and/or =
hierarchical LSPs of lower hierarchical level) just like an normal LSP =
concatenates
physical links. However, it takes some changes in CR-LDP signalling as =
to establish hierarchical LSPs:
Explicit Routing: the ingress of the H-LSP provides the complete =
sequence of sub H-LSPs to be concatenated (=3D change in ER-TLV).
Implicit Routing: the ingress (the transit) node of the H-LSP needs to =
send the LSP-ID of the first (the next) sub H-LSP to be concatenated =
(=3Dnew TLV).
The messages (LABEL-REQUEST, LABEL-MAPPING,...) have to be sent THRU =
"Control-Plane" sub H-LSPs (like thru tunnels) whose endpoints comply =
with the
endpoints of the to be concatenated "User Plane" sub H-LSPs.
The  LSP-IDs of the involved "Control-Plane" sub H-LSPs should be =
derivable from the LSP-IDs of the involved "User-Plane" sub H-LSPs.
=20
I stressed that, based on a small but contiguous partial mesh of LSPs =
an effective full mesh can be accomplished by building H-LSPs.
The N-square problem would completely disappear. Costs, i.e. work for =
the H-LSPs would only happen at the rim of the network. Indeed the =
network would not
even know that the H-LSPs exist, as all messages are tunnelled thru the =
"Control Plane" sub H-LSPs.
=20
=20
I would appreciate if more people supported this work on H-LSPs.
=20
Heinrich Hummel
Siemens
=20
=20
=20
=20
=20

=20
 -----Urspr=FCngliche Nachricht-----
Von: Vinay Vernekar [mailto:[email-masked]]
Gesendet: Dienstag, 16. April 2002 15:18
An: [email-masked]; [email-masked]
Betreff: Need for hierarchical SONET/SDH LSPs.

Hi,
Can I have a SONET/SDH LSP that passes through a SONET ADM as its =
transit LSR??
Consider a situation as shown below -
=20
A---------------B---------------C
=20
The link A-B is a STS-12 link, B does a byte-interleaved multiplexing =
of 4 STS-12 and forms a STS-48, thus B-C is STS-48.
Can a LSP for unstructured VC-4 be setup with A as ingress, B as =
transit and C as the egress??=20
As per the draft "Framework for GMPLS based control of SONET/SDH =
networks" the frames are not labeled instead it is the flow that is =
being labelled. It also mentions that tunnels should be used when =
switching from a different signal level i.e VC-12 to VC-4.=20
With this in mind, I would assume that a LSP as mentioned should be =
possible, because the signal type remains same i.e VC-4 even the frames =
get interleaved from STS-12 to STS-48.
Please correct me if I am wrong.
=20
Thanks in advance.
Regards
Vinay
=20

------_=_NextPart_001_01C1E774.80C521B0
Content-Type: text/html;
	charset="ISO-8859-1"

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

<META content="MSHTML 5.50.4915.500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff 
size=2>Vinay,</FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2>See 
also my draft, draft-hummel-mpls-hierarchical-lsp-00.txt: </FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2>An 
hierarchical LSP (H-LSP) shall concatenate normal LSPs (and/or hierarchical LSPs 
of lower hierarchical level) just like an normal LSP 
concatenates</FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff 
size=2>physical links. However, i<SPAN class=554470507-19042002><FONT face=Arial 
color=#0000ff size=2>t takes some changes in CR-LDP signalling as to establish 
hierarchical LSPs:</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002>Explicit Routing: the ingress of the H-LSP provides the 
complete sequence of sub H-LSPs to be concatenated (= change in 
ER-TLV).</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002>Implicit Routing: the ingress (the transit) 
node&nbsp;of the H-LSP needs to send the LSP-ID of&nbsp;the first&nbsp;(the 
next) sub H-LSP to be concatenated (=new TLV).</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002>The messages (LABEL-REQUEST, LABEL-MAPPING,...) have to 
be sent THRU "Control-Plane" sub H-LSPs (like thru tunnels) whose endpoints 
comply with the</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002>endpoints of the to be concatenated "User Plane" sub 
H-LSPs.</SPAN></FONT></SPAN></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>The&nbsp; LSP-IDs of the 
involved "Control-Plane" sub H-LSPs</SPAN></SPAN>&nbsp;<SPAN 
class=554470507-19042002>should be derivable from</SPAN><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>&nbsp;the LSP-IDs of the 
involved "User-Plane" sub H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN 
class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>I stressed that, based 
on a small but contiguous partial mesh of LSPs an effective full mesh can be 
accomplished by building H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>The N-square problem 
would completely disappear. Costs, i.e. work for the H-LSPs would only happen at 
the rim of the network. Indeed the network would 
not</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>even know that the 
H-LSPs exist, as all messages are tunnelled thru the "Control Plane" sub 
H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN 
class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN 
class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>I would appreciate if 
more people supported this work on 
H-LSPs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN 
class=554470507-19042002></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN class=554470507-19042002>Heinrich 
Hummel</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=554470507-19042002><SPAN 
class=554470507-19042002>Siemens</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=554470507-19042002><FONT face=Arial color=#0000ff size=2><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN>&nbsp;</DIV><SPAN 
class=554470507-19042002><FONT face=Arial color=#0000ff><SPAN 
class=554470507-19042002></SPAN></FONT></SPAN><FONT face=Tahoma>
<DIV><BR>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=554470507-19042002>&nbsp;</SPAN>-----Ursprüngliche 
Nachricht-----<BR><B>Von:</B> Vinay Vernekar 
[mailto:[email-masked]]<BR><B>Gesendet:</B> Dienstag, 16. April 2002 
15:18<BR><B>An:</B> [email-masked]; [email-masked]<BR><B>Betreff:</B> 
Need for hierarchical SONET/SDH LSPs.<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial>Hi,</FONT></DIV>
  <DIV><FONT face=Arial>Can I have a SONET/SDH LSP that passes through a SONET 
  ADM as its transit LSR??</FONT></DIV>
  <DIV><FONT face=Arial>Consider a situation as shown below -</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial>A---------------B---------------C</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial>The link A-B is a STS-12 link, B does a byte-interleaved 
  multiplexing of 4 STS-12 and forms a STS-48, thus B-C is STS-48.</FONT></DIV>
  <DIV><FONT face=Arial>Can a LSP for unstructured VC-4 be setup with A as 
  ingress, B as transit and C as the egress?? </FONT></DIV>
  <DIV><FONT face=Arial>As per the draft "Framework for GMPLS based control of 
  SONET/SDH networks" the frames are not labeled instead it is the flow that is 
  being labelled. </FONT><FONT face=Arial>It also mentions that tunnels should 
  be used when switching from a different signal level i.e&nbsp;VC-12 to VC-4. 
  </FONT></DIV>
  <DIV><FONT face=Arial>With this in mind, I would assume that a LSP as 
  mentioned should be possible, because the signal type remains same&nbsp;i.e 
  VC-4 even the frames get interleaved from STS-12 to STS-48.</FONT></DIV>
  <DIV><FONT face=Arial>Please correct me if I am wrong.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial>Thanks in advance.</FONT></DIV>
  <DIV><FONT face=Arial>Regards</FONT></DIV>
  <DIV><FONT face=Arial>Vinay</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1E774.80C521B0--

Delivery-date: Thu, 18 Apr 2002 13:22:41 -0700
From: Jonathan Lang <[email-masked]>
To: 'S Ramesh' <[email-masked]>, [email-masked]
Cc: OIF <[email-masked]>
Subject: RE: LMP Doubt
Date: Thu, 18 Apr 2002 13:12:20 -0700

Ramesh,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 2:45 AM
> To: [email-masked]
> Cc: OIF; S R a m e s h
> Subject: LMP Doubt
> 
> 
> Hi,
> 
> Can anybody explain me the need of Interface id to be of type IPv4, v6
> and unnnumbered. Why do we need this kind of classification to a number
> which is assigned to a port or component link.
Component links can themselves be numbered or unnumbered (see link bundling
draft). The distinction is required in the Interface_ID object of signaling.

> 
> In the case of Neighbour discovery, it is going to be used to find the
> data plane connectivity and verify it. Just a 32 bit number is enough
> for that right. Why do we need a classification with different C-Types
> for this interface id.
see comment above.

> But the Test messages also in most of the cases
> it is IP encapsulated, i dont think we need to use this Interface ID as
> the destination IP address for the Test messages, because this is unique
> Node-wide only. If so we can use the Node ID as the destination IP
> address ( since data links are directly connected ) and send the Test
> message which contains the Interface ID.
The LMP spec does not say to use the destination IP address for the Test
messages. The Node Id is what you should be using.

> 
> Also in OIF UNI 1.0 agreement, in Service Discovery messages, they use
> Interface ID as 32bit number ( may be IPv4 or un numbered ). For other
> Interface ID related messages which are used in Verification procedure,
> they refered IETF LMP draft.
> 
> At this point of time am putting Kireeti's  comments on a discussion
> like this
> 
> "I see that the OIF UNI comes up over and over.  The OIF UNI is *NOT*
> specified by CCAMP; hence "required by OIF OUNI" has little official
> meaning to CCAMP. However, if what the OIF UNI needs comes for free (as
> in this case), that's fine."
> 
> Am accepting the point , but however, i could not understand the reasons
> for the extensions to such a classification with 3 C-Types for Interface
> ID. If it is functionality wise required for a protocol in future means
> its upto the OIF to upgrade or  we can know the specific reason for
> making a difference ( which i could not understand the usage or future
> use of those classication ) from OIF UNI which "comes for free"
> otherwise. Kindly explain on this regard.
see above comment.

> Thanks,
> Ramesh

Delivery-date: Thu, 18 Apr 2002 10:22:26 -0700
From: "Cheng, Dean" <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>, [email-masked]
Subject: RE: encoding link id for unnumbered interfaces
Date: Thu, 18 Apr 2002 10:19:22 -0700

Do we have to worry about the consistence with
the Local Interface IP Address sub-TLV and
Remote Interface IP Address sub-TLV ?

Dean

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 6:00 AM
> To: [email-masked]
> Subject: encoding link id for unnumbered interfaces
> 
> 
> Folks,
> 
> I'd like to suggest that we replace Link Local Identifier sub-TLV
> and Link Remote Identifier sub-TLV (in both ISIS and OSPF) with a
> single sub-TLV that would contain both Link Local Identifier and Link 
> Remote Identifier.
> 
> Any objections ?
> 
> Yakov.
> 

Delivery-date: Thu, 18 Apr 2002 06:03:24 -0700
To: [email-masked]
Subject: encoding link id for unnumbered interfaces
Date: Thu, 18 Apr 2002 06:00:04 -0700
From: Yakov Rekhter <[email-masked]>

Folks,

I'd like to suggest that we replace Link Local Identifier sub-TLV
and Link Remote Identifier sub-TLV (in both ISIS and OSPF) with a
single sub-TLV that would contain both Link Local Identifier and Link 
Remote Identifier.

Any objections ?

Yakov.

Delivery-date: Thu, 18 Apr 2002 02:50:19 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>, "Vinay Vernekar" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Need for hierarchical SONET/SDH LSPs.
Date: Thu, 18 Apr 2002 15:36:04 +1000

This is a multi-part message in MIME format.

------=_NextPartTM-000-acdc5fdf-52af-11d6-af80-0080c8048dde
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: quoted-printable

hai,

I have a question regarding the Sonet/SDH traffic bandwidth encoding

This is in continuation to the scenario which vinay has mentioned in his =
mail.
Consider three LSRs A, B and C as shown below.

A---------------B---------------C

Now at node A i initiate an LSP creation with SONET/SDH traffic =
parameters with elementary
signal type as VC-4 and all other fields as zero and MT field as 1 =
ofcourse. Precisely i am trying to=20
create a VC-4 lsp.

Some doubts on the above scene

1+AD4- Now assume that B supports some sort of concatenation. Will it =
matter in any way to the=20
LSP creation initiated at node A when the request reaches node B and =
further ??=20

2+AD4-  Now when the label request reaches the node C, the egress, and =
if that node satisfies the=20
      bandwidth asked for, then what label will it give to node B with =
respect to SUKLM schema
      if node C is capable of switching STS-1 level signal. Will it be =
with S+AD0-1, U+AD0-1 and others 0 ??
      If yes, it means that the label structure is guided by the type of =
signal being requested in the
      Sonet/Sdh bandwidth encoding.

3+AD4- Lastly when a label structure is formed, what sort of =
communication will GMPLS do with the link
      layer for creation of crossconnect ??

Please do clarify there doubts=20

thanks in advance

regards
venkat

-----Original Message-----
From: Maarten Vissers +ADw-mvissers+AEA-lucent.com+AD4-
To: Vinay Vernekar +ADw-vinay.vernekar+AEA-wipro.com+AD4-
Cc: ccamp+AEA-ops.ietf.org +ADw-ccamp+AEA-ops.ietf.org+AD4AOw- =
gmpls-ops+AEA-mplsrc.com +ADw-gmpls-ops+AEA-mplsrc.com+AD4-
Date: Wednesday, April 17, 2002 1:40 AM
Subject: Re: Need for hierarchical SONET/SDH LSPs.

+AD4-Vinay,
+AD4-
+AD4-I assume that the signal on the fiber between A and B is an =
OC-12/STM-4 optical
+AD4-signal (carrying the STM-4/STS-12 signal) and on the fiber between =
B and C it is
+AD4-a OC-48/STM-16 optical signal (carrying the STM-16/STS-48 signal). =
Nodes A, B
+AD4-and C will have HOVC/STS switch fabrics which may support a subset =
of
+AD4-VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c =
swtiching+ADs- e.g. A
+AD4-node may support VC-4 switching, where as B and C nodes may support =
VC-4 and
+AD4-VC-4-4c switching.
+AD4-
+AD4-If all nodes support VC-4/STS-3c switching (and they typically do) =
and the
+AD4-STM-N/STS-N links between the nodes also support VC-4/STS-3c link =
connections
+AD4-(also typically the case), then you can setup a VC-4/STS-3c =
connection between
+AD4-nodes A and C. The VC-4/STS-3c payload is totally unimportant for =
this
+AD4-connection+ADs- any payload can be present.
+AD4-
+AD4-Regards,
+AD4-
+AD4-Maarten
+AD4-
+AD4APg- Vinay Vernekar wrote:
+AD4APg-=20
+AD4APg- Hi,
+AD4APg- Can I have a SONET/SDH LSP that passes through a SONET ADM as =
its transit
+AD4APg- LSR??
+AD4APg- Consider a situation as shown below -
+AD4APg-=20
+AD4APg- A---------------B---------------C
+AD4APg-=20
+AD4APg- The link A-B is a STS-12 link, B does a byte-interleaved =
multiplexing of 4
+AD4APg- STS-12 and forms a STS-48, thus B-C is STS-48.
+AD4APg- Can a LSP for unstructured VC-4 be setup with A as ingress, B =
as transit and C
+AD4APg- as the egress??
+AD4APg- As per the draft +ACI-Framework for GMPLS based control of =
SONET/SDH networks+ACI- the
+AD4APg- frames are not labeled instead it is the flow that is being =
labelled. It also
+AD4APg- mentions that tunnels should be used when switching from a =
different signal
+AD4APg- level i.e VC-12 to VC-4.
+AD4APg- With this in mind, I would assume that a LSP as mentioned =
should be possible,
+AD4APg- because the signal type remains same i.e VC-4 even the frames =
get interleaved
+AD4APg- from STS-12 to STS-48.
+AD4APg- Please correct me if I am wrong.
+AD4APg-=20
+AD4APg- Thanks in advance.
+AD4APg- Regards
+AD4APg- Vinay
+AD4APg-=20
+AD4APg-=20
+AD4APg-                            Name: Wipro+AF8-Disclaimer.txt
+AD4APg-    Wipro+AF8-Disclaimer.txt    Type: Plain Text (text/plain)
+AD4APg-                        Encoding: 7bit

------=_NextPartTM-000-acdc5fdf-52af-11d6-af80-0080c8048dde
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-acdc5fdf-52af-11d6-af80-0080c8048dde--

Delivery-date: Thu, 18 Apr 2002 02:41:16 -0700
Date: Thu, 18 Apr 2002 15:14:55 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited.
To: "[email-masked]" <[email-masked]>
CC: OIF <[email-masked]>, S R a m e s h <[email-masked]>
Subject: LMP Doubt

Hi,

Can anybody explain me the need of Interface id to be of type IPv4, v6
and unnnumbered. Why do we need this kind of classification to a number
which is assigned to a port or component link.

In the case of Neighbour discovery, it is going to be used to find the
data plane connectivity and verify it. Just a 32 bit number is enough
for that right. Why do we need a classification with different C-Types
for this interface id.  But the Test messages also in most of the cases
it is IP encapsulated, i dont think we need to use this Interface ID as
the destination IP address for the Test messages, because this is unique
Node-wide only. If so we can use the Node ID as the destination IP
address ( since data links are directly connected ) and send the Test
message which contains the Interface ID.

Also in OIF UNI 1.0 agreement, in Service Discovery messages, they use
Interface ID as 32bit number ( may be IPv4 or un numbered ). For other
Interface ID related messages which are used in Verification procedure,
they
refered IETF LMP draft.

At this point of time am putting Kireeti's  comments on a discussion
like this

"I see that the OIF UNI comes up over and over.  The OIF UNI is *NOT*
specified by CCAMP; hence "required by OIF OUNI" has little official
meaning to CCAMP. However, if what the OIF UNI needs comes for free (as
in this case), that's fine."

Am accepting the point , but however, i could not understand the reasons
for the extensions to such a classification with 3 C-Types for Interface
ID. If it is functionality wise required for a protocol in future means
its upto the OIF to upgrade or  we can know the specific reason for
making a difference ( which i could not understand the usage or future
use of those classication ) from OIF UNI which "comes for free"
otherwise. Kindly explain on this regard.

Thanks,
Ramesh

Delivery-date: Wed, 17 Apr 2002 09:09:35 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "CCAMP" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Progressing draft-ietf-ccamp-sdhsonet-control-00.txt (WaspProgressing draft-ccamp-sdhsonet-control-frmwrk-00.txt)
Date: Wed, 17 Apr 2002 12:15:00 -0400

Hello Zhi,

I gave an incorrect name, and that has caused much confusion (received
quite a few off line emails :-)). Sorry about the goof-up.

The document I was referring to is:
draft-ietf-ccamp-sdhsonet-control-00.txt

and is available at
ftp://ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-00.txt

Hope this solves the confusion I created.

-Vishal

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 11:56 AM
> To: [email-masked]
> Cc: Kireeti Kompella; CCAMP; Greg Bernstein; Eric Mannie; Ronald P.
> Bonica
> Subject: Re: Progressing draft-ccamp-sdhsonet-control-frmwrk-00.txt
>
>
> Hi Vishal,
>
> I did not see the document you referred to in the subject line
> (draft-ccamp-sdhsonet-control-frmwrk-00.txt)...is it some other document
> you had in mind? Maybe you mean the sonet-sdh-extensions-01?
>
> Zhi
>
>
> Vishal Sharma wrote:
>
> >Hi Kireeti
> >
> >The latest version of the above draft is now available on the IETF
> >drafts directory. As per your email below, we'd like to request
> >that this document be taken up for Last Call by the WG.
> >
> >We'd be happy to make any modifications that emerge from the
> >last call, and prepare a final version of the document for
> >progressing it through the RFC process.
> >
> >Thanks,
> >-Vishal
> >
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]On
> >>Behalf Of Kireeti Kompella
> >>Sent: Tuesday, March 19, 2002 11:42 AM
> >>To: [email-masked]
> >>Subject: Document status
> >>
> >>
> >>Here is the document status as presented in CCAMP 53.  Please read,
> >>especially if you are an author, and send corrections to Ron and me.
> >>
> >>Thanks,
> >>Kireeti.
> >>-------
> >>Finished Last Call in MPLS and CCAMP WGs
> >>draft-ietf-mpls-generalized-cr-ldp-05.txt
> >>draft-ietf-mpls-generalized-rsvp-te-06.txt
> >>draft-ietf-mpls-generalized-signaling-07.txt
> >>have implementation status, so ready for IETF Last Call
> >>
> >>Call for consensus to send to IETF Last Call
> >>draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  -- informational
> >>draft-ietf-ccamp-gmpls-architecture-02.txt          -- informational
> >>draft-ietf-ccamp-sdhsonet-control-00.txt            -- informational
> >>
> >>One more WG Last Call for final changes, then IETF Last Call
> >>draft-ietf-ccamp-gmpls-sonet-sdh-03.txt             -- proposed standard
> >>draft-ietf-ccamp-lmp-03.txt                         -- proposed standard
> >>
> >>WG Last Call
> >>draft-ietf-ccamp-gmpls-routing-02.txt               -- proposed standard
> >>draft-ietf-ccamp-ospf-gmpls-extensions-04.txt       -- proposed standard
> >>
> >>Call for consensus for WG Last Call
> >>draft-ietf-ccamp-lmp-mib-01.txt ?                   -- proposed standard
> >>draft-ietf-ccamp-lmp-wdm-00.txt                     -- proposed standard
> >>draft-ietf-ccamp-oli-reqts-00.txt                   -- informational
> >>
> >>Any objections to making this a WG document?
> >>draft-fontana-ccamp-gmpls-g709-03.txt               -- proposed standard
> >>
> >>Call for consensus to make into WG documents
> >>draft-bellato-ccamp-g709-framework-01.txt           -- informational
> >>draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt --
> >>proposed standard
> >>draft-mannie-ccamp-gmpls-lbm-tdm-01.txt             -- proposed standard
> >>draft-mannie-gmpls-recovery-terminology-00.txt      -- informational
> >>draft-bonica-tuntrace-02.txt                        -- informational
> >>
> >>Update, followed by call for consensus to make WG docs
> >>draft-nadeau-ccamp-gmpls-label-mib-01.txt           -- proposed standard
> >>draft-nadeau-ccamp-gmpls-lsr-mib-01.txt             -- proposed standard
> >>draft-nadeau-ccamp-gmpls-tc-mib-01.txt              -- proposed standard
> >>draft-nadeau-ccamp-gmpls-te-mib-01.txt              -- proposed standard
> >>
> >>Call for Design Team for "GMPLS Profile for ASON/ASTN"
> >>  -- understand more clearly what needs to be done here
> >>  -- figure out if a design team is needed (or just a set of IDs)
> >>
> >
>

Delivery-date: Wed, 17 Apr 2002 08:59:47 -0700
Date: Wed, 17 Apr 2002 11:55:58 -0400
From: Zhi-Wei Lin <[email-masked]>
To: [email-masked]
CC: Kireeti Kompella <[email-masked]>, CCAMP <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, "Ronald P. Bonica" <[email-masked]>
Subject: Re: Progressing draft-ccamp-sdhsonet-control-frmwrk-00.txt

Hi Vishal,

I did not see the document you referred to in the subject line 
(draft-ccamp-sdhsonet-control-frmwrk-00.txt)...is it some other document 
you had in mind? Maybe you mean the sonet-sdh-extensions-01?

Zhi

Vishal Sharma wrote:

>Hi Kireeti
>
>The latest version of the above draft is now available on the IETF
>drafts directory. As per your email below, we'd like to request
>that this document be taken up for Last Call by the WG.
>
>We'd be happy to make any modifications that emerge from the 
>last call, and prepare a final version of the document for
>progressing it through the RFC process.
>
>Thanks,
>-Vishal
>
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Kireeti Kompella
>>Sent: Tuesday, March 19, 2002 11:42 AM
>>To: [email-masked]
>>Subject: Document status
>>
>>
>>Here is the document status as presented in CCAMP 53.  Please read,
>>especially if you are an author, and send corrections to Ron and me.
>>
>>Thanks,
>>Kireeti.
>>-------
>>Finished Last Call in MPLS and CCAMP WGs
>>draft-ietf-mpls-generalized-cr-ldp-05.txt
>>draft-ietf-mpls-generalized-rsvp-te-06.txt
>>draft-ietf-mpls-generalized-signaling-07.txt
>>have implementation status, so ready for IETF Last Call
>>
>>Call for consensus to send to IETF Last Call
>>draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  -- informational
>>draft-ietf-ccamp-gmpls-architecture-02.txt          -- informational
>>draft-ietf-ccamp-sdhsonet-control-00.txt            -- informational
>>
>>One more WG Last Call for final changes, then IETF Last Call
>>draft-ietf-ccamp-gmpls-sonet-sdh-03.txt             -- proposed standard
>>draft-ietf-ccamp-lmp-03.txt                         -- proposed standard
>>
>>WG Last Call
>>draft-ietf-ccamp-gmpls-routing-02.txt               -- proposed standard
>>draft-ietf-ccamp-ospf-gmpls-extensions-04.txt       -- proposed standard
>>
>>Call for consensus for WG Last Call
>>draft-ietf-ccamp-lmp-mib-01.txt ?                   -- proposed standard
>>draft-ietf-ccamp-lmp-wdm-00.txt                     -- proposed standard
>>draft-ietf-ccamp-oli-reqts-00.txt                   -- informational
>>
>>Any objections to making this a WG document?
>>draft-fontana-ccamp-gmpls-g709-03.txt               -- proposed standard
>>
>>Call for consensus to make into WG documents
>>draft-bellato-ccamp-g709-framework-01.txt           -- informational
>>draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt -- 
>>proposed standard
>>draft-mannie-ccamp-gmpls-lbm-tdm-01.txt             -- proposed standard
>>draft-mannie-gmpls-recovery-terminology-00.txt      -- informational
>>draft-bonica-tuntrace-02.txt                        -- informational
>>
>>Update, followed by call for consensus to make WG docs
>>draft-nadeau-ccamp-gmpls-label-mib-01.txt           -- proposed standard
>>draft-nadeau-ccamp-gmpls-lsr-mib-01.txt             -- proposed standard
>>draft-nadeau-ccamp-gmpls-tc-mib-01.txt              -- proposed standard
>>draft-nadeau-ccamp-gmpls-te-mib-01.txt              -- proposed standard
>>
>>Call for Design Team for "GMPLS Profile for ASON/ASTN"
>>  -- understand more clearly what needs to be done here
>>  -- figure out if a design team is needed (or just a set of IDs)
>>
>

Delivery-date: Wed, 17 Apr 2002 00:02:08 -0700
Date: Wed, 17 Apr 2002 00:00:48 -0700 (PDT)
From: Jianwu HE <[email-masked]>
Subject: about TE link (GMPLS) and SNPP link (ASON)
To: Zhi-Wei Lin <[email-masked]>
Cc: [email-masked], [email-masked]

Dr Lin,

In GMPLS architecture, TE Link is defined, and in G.8080(ASON), SNPP Link is defined.
I think TE Link and SNPP link have many same characteristics, all for routing. Can you 
described this problem in detail

Jianwu HE
[email-masked]
Beijing Univ.of Posts and Telecomm.

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Delivery-date: Tue, 16 Apr 2002 22:53:14 -0700
Date: Wed, 17 Apr 2002 01:41:28 -0400
To: Bala Rajagopalan <[email-masked]>, <[email-masked]>, [email-masked]
From: Zafar Ali <[email-masked]>
Subject: RE: UNI end-to-end sessions
Cc: <[email-masked]>, <[email-masked]>, Bala Rajagopalan <[email-masked]>

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

At 09:45 AM 4/10/2002 -0400, Bala Rajagopalan wrote:

>Please post UNI related messages to
>[email-masked] (not to ccamp).
>
>FYI, there is going to be a OIF contribution
>on UNI-GMPLS mapping for the coming meeting.
>
>Bala

FYI, I think Bala was referring to the following contribution, which has 
been uploaded to the OIF site,

Document data for oif2002.158.00:
Document Name: UNI/GMPLS Inter-working
Document Author: Basak, Debashis
Abstract:
This contribution considers the case when different vendors' gear in a 
transport network operate within the same instance of a single GMPLS TE 
area. Signaling and routing issues of UNI to GMPLS inter-working are 
discussed within the scope of such a network.

Thanks

Regards... Zafar

> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Wednesday, April 10, 2002 4:21 AM
> > To: [email-masked]
> > Cc: "Gino Carrozzo" <g.carrozzo; "ccamp" <ccamp; <braja
> > Subject: RE: UNI end-to-end sessions
> >
> >
> >
> > Hi Monica,
> >                         I agree with you that there isn't a
> > UNI end-to-end
> > session, but in my understanding what Gino was asking is how
> > to map UNI
> > information that has end-to-end significance.
> >
> > In fact it is written in the UNI doc (table 12-5) that there
> > are some UNI
> > objects that have end-to-end significance. For example Source and
> > Destination TNA addresses have end-to-end significance.   This doesn't
> > mean, as you pointed out, that there is an UNI session
> > between two UNI.
> >
> >  Anyway the question is (this is my interpretation of Gino's
> > message so
> > please, Gino, correct me if I'm wrong) how can I transport/map the UNI
> > end-to-end significative information between the two UNIs?
> >
> > AFAIK there is no room in GMPLS extended LDP and RSVP for
> > this purpose.
> >
> > Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
> > LDP/RSVP?
> >
> > Regards, Diego.
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Optical Network - ASON strategy
> > E-mail: [email-masked]
> > Tel: +39 0 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> >
> >
> >
> > "Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
> > 04.41.05
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   "Gino Carrozzo" <[email-masked]>, "ccamp"
> > <[email-masked]>
> > cc:   <[email-masked]>
> >
> > Subject:  RE: UNI end-to-end sessions
> >
> >
> > All,
> > I want to correct some mis-representations - There is no
> > end-to-end UNI
> > session. A UNI session is between a user and the network. There is a
> > separate UNI session at the other edge of the network,
> > between the other
> > client and the network. Further more, it should not be
> > assumed that the
> > same protocol must run over the 2 separate UNIs.
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gino Carrozzo [mailto:[email-masked]]
> > Sent: Tuesday, April 09, 2002 5:45 AM
> > To: ccamp
> > Cc: [email-masked]
> > Subject: UNI end-to-end sessions
> >
> > All,
> >
> > when establishing an end-to-end UNI-RSVP session between two
> > UNI-Cs (src &
> > dest. UNI clients),
> > I didn't found any reference in how to "transfer" UNI
> > end-to-end info from
> > the source client side (source UNI-C <--> UNI-N on source TNE) to the
> > destination client side (UNI-N on dest. TNE <-->dest UNI-C).
> > In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C
> > / UNI-N side
> > is considered.
> >
> > How the two UNI-N can exchange UNI infos in the transport network?
> > Is there any action in this WG (or in IETF) to fix this problem?
> >
> >
> > Thanks
> >
> > Gino
> >
> >
> >
> >
> >
> >

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

<html>
<font size=3>At 09:45 AM 4/10/2002 -0400, Bala Rajagopalan wrote:<br>
<br>
<blockquote type=cite cite>Please post UNI related messages to<br>
[email-masked] (not to ccamp).<br>
<br>
FYI, there is going to be a OIF contribution<br>
on UNI-GMPLS mapping for the coming meeting.<br>
<br>
Bala</blockquote><br>
FYI, I think Bala was referring to the following contribution, which has
been uploaded to the OIF site, <br>
<br>
Document data for oif2002.158.00: <br>
Document Name: UNI/GMPLS Inter-working <br>
Document Author: Basak, Debashis<br>
Abstract:<br>
This contribution considers the case when different vendors' gear in a
transport network operate within the same instance of a single GMPLS TE
area. Signaling and routing issues of UNI to GMPLS inter-working are
discussed within the scope of such a network. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<blockquote type=cite cite>&gt; -----Original Message-----<br>
&gt; From: Diego Caviglia
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
&gt; Sent: Wednesday, April 10, 2002 4:21 AM<br>
&gt; To: [email-masked]<br>
&gt; Cc: &quot;Gino Carrozzo&quot; &lt;g.carrozzo; &quot;ccamp&quot;
&lt;ccamp; &lt;braja<br>
&gt; Subject: RE: UNI end-to-end sessions<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Hi Monica,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
I agree with you that there isn't a <br>
&gt; UNI end-to-end<br>
&gt; session, but in my understanding what Gino was asking is how <br>
&gt; to map UNI<br>
&gt; information that has end-to-end significance.<br>
&gt; <br>
&gt; In fact it is written in the UNI doc (table 12-5) that there <br>
&gt; are some UNI<br>
&gt; objects that have end-to-end significance. For example Source
and<br>
&gt; Destination TNA addresses have end-to-end significance.&nbsp;&nbsp;
This doesn't<br>
&gt; mean, as you pointed out, that there is an UNI session <br>
&gt; between two UNI.<br>
&gt; <br>
&gt;&nbsp; Anyway the question is (this is my interpretation of Gino's
<br>
&gt; message so<br>
&gt; please, Gino, correct me if I'm wrong) how can I transport/map the
UNI<br>
&gt; end-to-end significative information between the two UNIs?<br>
&gt; <br>
&gt; AFAIK there is no room in GMPLS extended LDP and RSVP for <br>
&gt; this purpose.<br>
&gt; <br>
&gt; Are there any efforts in IETF to harmonize OIF UNI and GMPLS
extended<br>
&gt; LDP/RSVP?<br>
&gt; <br>
&gt; Regards, Diego.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt;
----------------------------------------------------------------<br>
&gt; Diego Caviglia<br>
&gt; Optical Network - ASON strategy<br>
&gt; E-mail: [email-masked]<br>
&gt; Tel: +39 0 10 6003 808<br>
&gt; Via A. Negrone 1A 16153 Genoa (Italy)<br>
&gt;
<a href="http://www.marconi.com/" eudora="autourl">http://www.marconi.com</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; &quot;Lazer, Monica A, ALCNS&quot;
&lt;[email-masked]&gt;@ops.ietf.org on 10/04/2002<br>
&gt; 04.41.05<br>
&gt; <br>
&gt; Sent by:&nbsp; [email-masked]<br>
&gt; <br>
&gt; <br>
&gt; To:&nbsp;&nbsp; &quot;Gino Carrozzo&quot; &lt;[email-masked]&gt;,
&quot;ccamp&quot; <br>
&gt; &lt;[email-masked]&gt;<br>
&gt; cc:&nbsp;&nbsp; &lt;[email-masked]&gt;<br>
&gt; <br>
&gt; Subject:&nbsp; RE: UNI end-to-end sessions<br>
&gt; <br>
&gt; <br>
&gt; All,<br>
&gt; I want to correct some mis-representations - There is no <br>
&gt; end-to-end UNI<br>
&gt; session. A UNI session is between a user and the network. There is
a<br>
&gt; separate UNI session at the other edge of the network, <br>
&gt; between the other<br>
&gt; client and the network. Further more, it should not be <br>
&gt; assumed that the<br>
&gt; same protocol must run over the 2 separate UNIs.<br>
&gt; <br>
&gt; Monica A. Lazer<br>
&gt; Advanced Transport Technology and Architecture Planning<br>
&gt; <br>
&gt; 908 234 8462<br>
&gt; [email-masked]<br>
&gt; <br>
&gt; -----Original Message-----<br>
&gt; From: Gino Carrozzo
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
&gt; Sent: Tuesday, April 09, 2002 5:45 AM<br>
&gt; To: ccamp<br>
&gt; Cc: [email-masked]<br>
&gt; Subject: UNI end-to-end sessions<br>
&gt; <br>
&gt; All,<br>
&gt; <br>
&gt; when establishing an end-to-end UNI-RSVP session between two <br>
&gt; UNI-Cs (src &amp;<br>
&gt; dest. UNI clients),<br>
&gt; I didn't found any reference in how to &quot;transfer&quot;
UNI&nbsp; <br>
&gt; end-to-end info from<br>
&gt; the source client side (source UNI-C &lt;--&gt; UNI-N on source TNE)
to the<br>
&gt; destination client side (UNI-N on dest. TNE &lt;--&gt;dest
UNI-C).<br>
&gt; In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C <br>
&gt; / UNI-N side<br>
&gt; is considered.<br>
&gt; <br>
&gt; How the two UNI-N can exchange UNI infos in the transport
network?<br>
&gt; Is there any action in this WG (or in IETF) to fix this
problem?<br>
&gt; <br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Gino<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; </font></blockquote></html>

--=====================_97277567==_.ALT--

Delivery-date: Tue, 16 Apr 2002 22:47:32 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "venkat" <[email-masked]>, <[email-masked]>
Subject: RE: Doubts regarding SONET/SDH label
Date: Wed, 17 Apr 2002 01:52:11 -0400

Venkat,

A number of your questions can be answered by looking at draft
draft-ccamp-sdhsonet-control-frmwrk-00.txt.

Please read through it, and see if you still have the same
questions.

Thanks,
-Vishal

+AD4- -----Original Message-----
+AD4- From: owner-ccamp+AEA-ops.ietf.org =
+AFs-mailto:owner-ccamp+AEA-ops.ietf.org+AF0-On
+AD4- Behalf Of Venkat Dabbara
+AD4- Sent: Monday, April 15, 2002 4:05 AM
+AD4- To: ccamp+AEA-ops.ietf.org
+AD4- Subject: Doubts regarding SONET/SDH label
+AD4-=20
+AD4-=20
+AD4- hai,
+AD4-    =20
+AD4-         Could someone explain me the correlation between the=20
+AD4- position of a particular signal in SONET/SDH
+AD4-         multiplexing structure which is indicated by the SUKLM=20
+AD4- numbering schema (SDH/SONET label) and the    =20
+AD4-         timeslot ???
+AD4-        =20
+AD4-         How do a SONET/SDH LSR maintain the label resource ??=20
+AD4- Does the SONET/SDH multiplexing structure=20
+AD4-         signifies the label resource with root as the signal=20
+AD4- level which the LSR switches ??
+AD4-=20
+AD4-         Does label set or the suggested label concept in GMPLS=20
+AD4- holds good for SONET/SDH LSPs also ??
+AD4-         If yes, can someone frame such a requirement where it is=20
+AD4- applicable ??
+AD4-=20
+AD4-         Please correct me if i am going wrong somewhere ?? Also=20
+AD4- do suggest some pointers where i can get
+AD4-         information about controlling and provisioning SONET/SDH =
LSPs
+AD4-=20
+AD4- thanks in advance=20
+AD4- regards
+AD4- venkat
+AD4-=20
+AD4-        =20
+AD4- =
+ACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAq=
ACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqA=
CoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACo-
+AD4- Experience is a wonderful thing. It enables you to recognize a
+AD4- mistake when you make it again.
+AD4-=20
+AD4-=20
+AD4-=20
+AD4-=20

Delivery-date: Tue, 16 Apr 2002 15:23:06 -0700
From: Jonathan Lang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: FW: LMP & neighbor discovery
Date: Tue, 16 Apr 2002 15:13:09 -0700

Michiel,

<snip>
> 
> Repeating my earlier questions:
> - Why is 'control channel management' mandatory ?
> - Why are normal (i.e. not LMP specific) network layer mechanisms not
>   sufficient ?
Why do you think they are sufficient?

Thanks,
Jonathan

> 
> 
> 
> Thanks,
> 
> Michiel
> 
> Jonathan Lang wrote:
> > 
> > Michiel,
> >   Please see inline.
> > 
> > Thanks,
> > Jonathan
> > 
> > > -----Original Message-----
> > > From: Michiel van Everdingen [mailto:[email-masked]]
> > > Sent: Thursday, April 11, 2002 9:03 AM
> > > To: Jonathan Lang
> > > Cc: [email-masked]
> > > Subject: Re: LMP & neighbor discovery
> > >
> > >
> > > Hello Jonathan,
> > >
> > >
> > > Your answer raises some questions in my mind:
> > >
> > > > This is what the Link Verification procedure provides. 
> As part of the
> > > > BeginVerify message exchange, certain Test parameters (such as
> > > > Verify_Interval, Verify_Dead_Interval, and 
> Verify_Transport_Mechanism)
> > are
> > > > exchanged.
> > >
> > > How do you start this link Verification procedure ? The 
> 'beginVerify'
> > message
> > > seems to assume that the neighbor is already known.
> > Sending the BeginVerify assumes you know where to send 
> control messages.
> > This is separate from discovering the data interfaces. This 
> is why using the
> > term Neighbor Discovery can often be confusing.  You 
> actually have discovery
> > at various levels. G.7714 talks about this in a little more detail.
> > 
> > >
> > > Please note that I'm discussing initial discovery. I 
> don't question the
> > use
> > > of subsequent test messages verifying the connectivity.
> > Noted.
> > 
> > >
> > >
> > > > As part of this discovery, NE-3 sends an acknowledgment 
> message carrying
> > the
> > > > local (near-end) identity of link B.
> > >
> > > Yes, agreed.
> > >
> > > In my proposal this acknowledgement is in the link 
> correlation procedure.
> > > The DATA_LINK object in the linkSummary message (which is 
> sent upon
> > detection
> > > of the neighbor) gives the association between 
> "Local_Interface_Id" and
> > > "Remote_Interface_Id".
> > Link correlation procedure also provides the local/remote 
> mapping for all
> > data links. The Ack message provides this mapping (in 
> addition to Test
> > message Ack) for each data channel individually.
> > 
> > >
> > >
> > > > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) 
> have agreed on the
> > > > verification mechanism in advance.
> > >
> > > I'm not discussing verification but initial discovery.
> > > If we could align on the used procedure for this initial 
> discovery,
> > > the neighboring NEs don't have to negotiate the mechanism :-)
> > Verification mechanism is used for data link discovery. 
> Without exchanging
> > this parameter, you'd have to configure it on both nodes 
> for each port/node
> > pair. Furthermore, if run LMP-WDM, you may have to 
> configure yet another
> > mechanism for your wdm neighbor if the termination capabilities are
> > different.
> > 
> > >
> > >
> > > > You could certainly create an LMP control channel 
> through a DCN network.
> > In
> > > > fact, this is probably the preferred configuration.
> > > >
> > > > > Is implementation of the LMP's 'control channel 
> management' mandatory
> > ?
> > > > yes, however you can choose not to run the Hellos by setting the
> > > > HelloInterval and HelloDeadInterval equal to zero.
> > >
> > > I don't understand why the normal network-layer 
> mechanisms (defined in
> > e.g.
> > > OSPF or I-ISIS) are not sufficient ?
> > > Why do we need the LMP specific 'Config' 'ConfigAck' and 
> 'ConfigNack'
> > > messages ?
> > These are used to configure the LMP Hellos that are used to 
> rapidly detect
> > failures along the control channel.
> > 
> > >
> > >
> > > Thanks !
> > >
> > > Michiel
> > >
> > >
> > > Jonathan Lang wrote:
> > > >
> > > > Michiel,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Michiel van Everdingen 
> [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 09, 2002 12:41 AM
> > > > > To: [email-masked]
> > > > > Subject: LMP & neighbor discovery
> > > > >
> > > > >
> > > > > Hello all,
> > > > >
> > > > > I found the concept of neighbor discovery mentioned
> > > several times in
> > > > > previous discussions on this list. However, I did not 
> find a final
> > > > > conclusion on how this neighbor discovery is done. Correct ?
> > > > >
> > > > > Could you please check my understanding below ?
> > > > >
> > > > > In my mind, reading the incoming 'access point
> > > identifier' [ITU-G.707]
> > > > > and subsequent LMP 'link property correlation' form a
> > > perfect fit. By
> > > > > simply encoding the sending node's IP address and local
> > > access point
> > > > > number in the access point identifier (see e.g.
> > > [OIF.2000.159.01]), the
> > > > > receiver can discover the data link (linkConnection in
> > > ITU  terminology).
> > > > > Subsequent 'link property correlation' could then a.o.
> > > check on bi-
> > > > > directional fibering, matching data link properties and
> > > grouping of data
> > > > > links into TE links.
> > > > >
> > > > > Example: the following figure shows 4 network 
> elements of which 2
> > > > terminate
> > > > > the data link (TTPs, T) and two are transparent to the
> > > data link (CTPs,
> > > > C).
> > > > > E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 
> and NE-3 are
> > > > transparent
> > > > > optical cross connects. The data link in this example is
> > > STM-N/OC-N.
> > > > >
> > > > > +------+      +------+      +------+      +------+
> > > > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > > > |      |   A  |      |   B  |      |   C  |      |
> > > > > |      |      |      |      |      |      |      |
> > > > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > > > +------+      +------+      +------+      +------+
> > > > >
> > > > > NE-2 should, when it wants to discover data link B,
> > > connect a test-set
> > > > that
> > > > > sends an access point identifier to identify the sending
> > > connection point
> > > > C
> > > > > in NE-2. This test-signal should be send long enough for
> > > NE-3 to detect
> > > > and
> > > > > read the test-signal (a fixed, agreed upon timer is
> > > needed). NE-3 will
> > > > > continuously scan all its not discovered input ports for
> > > a discovery
> > > > signal.
> > > > > At some point, it will detect the test-signal on data link B.
> > > > This is what the Link Verification procedure provides. As
> > > part of the
> > > > BeginVerify message exchange, certain Test parameters (such as
> > > > Verify_Interval, Verify_Dead_Interval, and
> > > Verify_Transport_Mechanism) are
> > > > exchanged.
> > > >
> > > > >
> > > > > +------+      +------+      +------+      +------+
> > > > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > > > |      |   A  |   /  |   B  |  \   |   C  |      |
> > > > > |      |      |  T   |      |   T  |      |      |
> > > > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > > > +------+      +------+      +------+      +------+
> > > > >
> > > > > When NE-3 has read the access point identifier in the
> > > test signal, data
> > > > > link B is discovered. Subsequent link property
> > > correlation can then be
> > > > > invoked.
> > > > As part of this discovery, NE-3 sends an acknowledgment
> > > message carrying the
> > > > local (near-end) identity of link B.
> > > >
> > > > >
> > > > > Discovery of data link A is similar, except that the 
> access point
> > > > identifier
> > > > > is continuously sent. Discovery of data link C is also
> > > similar, except
> > > > that
> > > > > the access point identifier is continuously monitored. In
> > > other words,
> > > > there
> > > > > is no need for a sending respectively monitoring
> > > 'test-set' in NE-1 and
> > > > NE-4.
> > > > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have
> > > agreed on the
> > > > verification mechanism in advance.
> > > >
> > > > >
> > > > > Data link type          Access point identifier to be used
> > > > > --------------          ----------------------------------
> > > > > STM-N, OC-N                            J0
> > > > > STS-1/3/.../VC-3/4/...                 J1
> > > > > VT-1.5/VC-11/12                        J2
> > > > >
> > > > >
> > > > > Notes:
> > > > > - I understand that LMP's link verification procedure is
> > > more efficient
> > > > for
> > > > >   *already discovered* data links. It does not need 
> the continuous
> > > > scanning
> > > > >   on received access point identifiers in undiscovered
> > > CTPs (in the
> > > > example:
> > > > >   in NE-3).
> > > > > - Discovering the address of the sending access point
> > > might also go via a
> > > > 'name
> > > > >   server'. This can, for example, be useful in case the
> > > address of this
> > > > access
> > > > >   point can not be encoded in the limited length of the
> > > access point
> > > > identifier.
> > > > >
> > > > > B.t.w., could you please explain why the linkSummary and
> > > linkSummaryAck
> > > > messages
> > > > > have to go over a point-to-point control channel ?
> > > > All LMP messages are sent over the LMP control channel; the
> > > health of which
> > > > is monitored using LMP Hello messages.
> > > >
> > > > > Is it also possible to
> > > > > use the generic DCN network (MCN/SCN, can be IP-based,
> > > see ITU-G.7712) ?
> > > > > In the latter case, we could simply use the normal UDP
> > > service of that
> > > > network
> > > > > to transport the linkSummary and linkSummaryAck messages ?
> > > > You could certainly create an LMP control channel through a
> > > DCN network. In
> > > > fact, this is probably the preferred configuration.
> > > >
> > > > > Is implementation of the LMP's 'control channel
> > > management' mandatory ?
> > > > yes, however you can choose not to run the Hellos by setting the
> > > > HelloInterval and HelloDeadInterval equal to zero.
> > > >
> > > > >
> > > > >
> > > > > Thanks !
> > > > >
> > > > > Michiel
> > > > >
> > > > > --
> > > > >
> > > 
> +------------------------------------------------------------------+
> > > > > | Michiel van Everdingen
> > >          |
> > > > > | Systems Engineer
> > >          |
> > > > > | Lucent Technologies - Optical Networking Group
> > >          |
> > > > > | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883
> > >          |
> > > > > | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976
> > >          |
> > > > > | Huizen, The Netherlands
> > > mailto:[email-masked]  |
> > > > >
> > > 
> +------------------------------------------------------------------+
> > > > >
> > >
> 

Delivery-date: Tue, 16 Apr 2002 08:20:37 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: "CCAMP" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>
Subject: Progressing draft-ccamp-sdhsonet-control-frmwrk-00.txt
Date: Tue, 16 Apr 2002 11:26:31 -0400

Hi Kireeti

The latest version of the above draft is now available on the IETF
drafts directory. As per your email below, we'd like to request
that this document be taken up for Last Call by the WG.

We'd be happy to make any modifications that emerge from the 
last call, and prepare a final version of the document for
progressing it through the RFC process.

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Tuesday, March 19, 2002 11:42 AM
> To: [email-masked]
> Subject: Document status
> 
> 
> Here is the document status as presented in CCAMP 53.  Please read,
> especially if you are an author, and send corrections to Ron and me.
> 
> Thanks,
> Kireeti.
> -------
> Finished Last Call in MPLS and CCAMP WGs
> draft-ietf-mpls-generalized-cr-ldp-05.txt
> draft-ietf-mpls-generalized-rsvp-te-06.txt
> draft-ietf-mpls-generalized-signaling-07.txt
> have implementation status, so ready for IETF Last Call
> 
> Call for consensus to send to IETF Last Call
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  -- informational
> draft-ietf-ccamp-gmpls-architecture-02.txt          -- informational
> draft-ietf-ccamp-sdhsonet-control-00.txt            -- informational
> 
> One more WG Last Call for final changes, then IETF Last Call
> draft-ietf-ccamp-gmpls-sonet-sdh-03.txt             -- proposed standard
> draft-ietf-ccamp-lmp-03.txt                         -- proposed standard
> 
> WG Last Call
> draft-ietf-ccamp-gmpls-routing-02.txt               -- proposed standard
> draft-ietf-ccamp-ospf-gmpls-extensions-04.txt       -- proposed standard
> 
> Call for consensus for WG Last Call
> draft-ietf-ccamp-lmp-mib-01.txt ?                   -- proposed standard
> draft-ietf-ccamp-lmp-wdm-00.txt                     -- proposed standard
> draft-ietf-ccamp-oli-reqts-00.txt                   -- informational
> 
> Any objections to making this a WG document?
> draft-fontana-ccamp-gmpls-g709-03.txt               -- proposed standard
> 
> Call for consensus to make into WG documents
> draft-bellato-ccamp-g709-framework-01.txt           -- informational
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt -- 
> proposed standard
> draft-mannie-ccamp-gmpls-lbm-tdm-01.txt             -- proposed standard
> draft-mannie-gmpls-recovery-terminology-00.txt      -- informational
> draft-bonica-tuntrace-02.txt                        -- informational
> 
> Update, followed by call for consensus to make WG docs
> draft-nadeau-ccamp-gmpls-label-mib-01.txt           -- proposed standard
> draft-nadeau-ccamp-gmpls-lsr-mib-01.txt             -- proposed standard
> draft-nadeau-ccamp-gmpls-tc-mib-01.txt              -- proposed standard
> draft-nadeau-ccamp-gmpls-te-mib-01.txt              -- proposed standard
> 
> Call for Design Team for "GMPLS Profile for ASON/ASTN"
>   -- understand more clearly what needs to be done here
>   -- figure out if a design team is needed (or just a set of IDs)

Delivery-date: Tue, 16 Apr 2002 08:09:35 -0700
Cc: [email-masked], [email-masked]
Date: Tue, 16 Apr 2002 17:08:26 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Vinay Vernekar <[email-masked]>
Original-CC: [email-masked], [email-masked]
Subject: Re: Need for hierarchical SONET/SDH LSPs.

This is a multi-part message in MIME format.
--------------1EC28BB1FFF446944CCE43C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vinay,

I assume that the signal on the fiber between A and B is an OC-12/STM-4 optical
signal (carrying the STM-4/STS-12 signal) and on the fiber between B and C it is
a OC-48/STM-16 optical signal (carrying the STM-16/STS-48 signal). Nodes A, B
and C will have HOVC/STS switch fabrics which may support a subset of
VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c swtiching; e.g. A
node may support VC-4 switching, where as B and C nodes may support VC-4 and
VC-4-4c switching.

If all nodes support VC-4/STS-3c switching (and they typically do) and the
STM-N/STS-N links between the nodes also support VC-4/STS-3c link connections
(also typically the case), then you can setup a VC-4/STS-3c connection between
nodes A and C. The VC-4/STS-3c payload is totally unimportant for this
connection; any payload can be present.

Regards,

Maarten

> Vinay Vernekar wrote:
> 
> Hi,
> Can I have a SONET/SDH LSP that passes through a SONET ADM as its transit
> LSR??
> Consider a situation as shown below -
> 
> A---------------B---------------C
> 
> The link A-B is a STS-12 link, B does a byte-interleaved multiplexing of 4
> STS-12 and forms a STS-48, thus B-C is STS-48.
> Can a LSP for unstructured VC-4 be setup with A as ingress, B as transit and C
> as the egress??
> As per the draft "Framework for GMPLS based control of SONET/SDH networks" the
> frames are not labeled instead it is the flow that is being labelled. It also
> mentions that tunnels should be used when switching from a different signal
> level i.e VC-12 to VC-4.
> With this in mind, I would assume that a LSP as mentioned should be possible,
> because the signal type remains same i.e VC-4 even the frames get interleaved
> from STS-12 to STS-48.
> Please correct me if I am wrong.
> 
> Thanks in advance.
> Regards
> Vinay
> 
> 
>                            Name: Wipro_Disclaimer.txt
>    Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
>                        Encoding: 7bit
--------------1EC28BB1FFF446944CCE43C7
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------1EC28BB1FFF446944CCE43C7--

Delivery-date: Tue, 16 Apr 2002 06:44:44 -0700
Date: Tue, 16 Apr 2002 09:43:32 -0400
To: Michiel van Everdingen <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]

--=====================_39133400==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

At 02:56 PM 4/16/2002 +0200, Michiel van Everdingen wrote:
>Zafar,
>
>Could you please clarify what is 'CC' ?

Sorry Michiel, I should have been more clear on this...

CC =3D Control Channel in my message.

Thanks

Regards... Zafar
>I've tried to read your email assuming 'CC'=3DCross Connect and
>assuming 'CC'=3DConnection Controller, but failed.
>
>I assume
>   'SDCC' =3D section DCC / RS-DCC (D1-D3)
>   'LDCC' =3D line DCC / MS-DCC (D4-D12)
>correct ?
>
>What is an SDCC/LDCC based CC ?
>What is an interface bound IPCC ?
>
>
>Please accept my apologies if these terms are well-known to this
>group.
>
>
>Thanks,
>
>Michiel
>
>
>Zafar Ali wrote:
> >
> > At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> >
> > > Hi Jonathan,
> > >
> > > Thanks for the quick response. Please see my comments inline.
> > >
> > > Manoj
> > >
> > > Jonathan Lang wrote:
> > > >
> > > > Manoj,
> > > >   Please see inline.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Manoj Sontakke [mailto:[email-masked]]
> > > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > > To: [email-masked]
> > > > > Subject: Question on LMP.
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have two questions on LMP.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > -----------------------------
> > > > > Q1.  Control Channel Question
> > > > >
> > > > > Assuming a configuration as shown.
> > > > >
> > > > >
> > > > >                 -----------------               -----------------
> > > > >                 |               |               |               |
> > > > >                 |            if1|---------------|if1            |
> > > > >                 |            if2|---------------|if2            |
> > > > >                 |     OXC 1     |               |     OXC 2     |
> > > > >                 |             d1|---------------|d1             |
> > > > >                 |             d2|---------------|d2             |
> > > > >                 -----------------
> > > > > -----------------
> > > > >
> > > > >
> > > > > I have two OXCs connected by four links. Consider d1, d2 are=20
> configured
> > > > > to carry data and if1 and if2 are configured to carry control=20
> data ( LMP
> > > > > messages and RSVP and OSPF messages).
> > > > >
> > > > > The LMP document defines control channels with an unique=
 identifier (
> > > > > control channel identifier ) between the negibouring nodes.
> > > > > So also, the LMP messages are IP encapsulated.
> > > > >
> > > > > Now, I have a couple of questions
> > > > >
> > > > > 1. Is there any association between the LMP control channels to=
 the
> > > > > physical interfaces( if1, if2). Because all the IP packets are=20
> routed on
> > > > > the physical interfaces according to the routing table. The=
 control
> > > > > channel messages like  ( config and configAck etc.. ) can go on=20
> the any
> > > > > physical interface which is decided by the routing table.
> > > > >
> > > > > In such case, are the control channels a pure logical concept or=
=20
> do they
> > > > > have any physical interface significance & correlation [ mapping=
=20
> between
> > > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> > >
> > > > Control channels are associated with interfaces.
> > >
> > > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > > messages are IP encoded. So the routing table decides the outgoing
> > > interface for sending the LMP messages (any packet for that matter)
> > > depending upon the destination IP address.
> > >
> > > So is it possible to make such an association between the LMP control
> > > channel and a physical interface (though it is desirable)?
> >
> > Hi Manoj, et all:
> >
> > The association between the CC and data bearer link is neither=20
> prevented nor enforced by the specification, as you also mentioned. IMO,=
=20
> the association between the CC and data bearer link is a vendor specific=
=20
> question. Vendors can manage the available set of CCs in the way they=20
> would like to.
> > I.e., a vendor may choose a specific CC to send all messages that are=20
> pertaining to a data bearer link, etc. The key is that the receiver node=
=20
> for the LMP messages should be able to receive LMP messages from any CC=20
> that it=92s running with a given neighbor. This is of course with the=20
> exception of
> > LMP Hellos messages.
> >
> > > Are we
> > > deviating from the standard IP implementation ?
> >
> > In selecting the CC by making an association between the CC and the=20
> data link, one will NOT be diverting from IP. Specifically, one may=20
> consider CC to be of two different types: interface bound or routed.=20
> E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP=
=20
> application can
> > select a specific egress interface while using interface bound CCs, etc.
> >
> > Thanks
> >
> > Regards=85 Zafar
> >
> > <snip>

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

<html>
<font size=3D3>At 02:56 PM 4/16/2002 +0200, Michiel van Everdingen
wrote:<br>
<blockquote type=3Dcite cite>Zafar,<br>
<br>
Could you please clarify what is 'CC' ?</font></blockquote><br>
Sorry Michiel, I should have been more clear on this... <br>
<br>
CC =3D Control Channel in my message.<br>
<br>
<font size=3D3>Thanks<br>
<br>
Regards... Zafar <br>
<blockquote type=3Dcite cite>I've tried to read your email assuming
'CC'=3DCross Connect and<br>
assuming 'CC'=3DConnection Controller, but failed.<br>
<br>
I assume<br>
&nbsp; 'SDCC' =3D section DCC / RS-DCC (D1-D3)<br>
&nbsp; 'LDCC' =3D line DCC / MS-DCC (D4-D12)<br>
correct ?<br>
<br>
What is an SDCC/LDCC based CC ?<br>
What is an interface bound IPCC ?<br>
<br>
<br>
Please accept my apologies if these terms are well-known to this<br>
group.<br>
<br>
<br>
Thanks,<br>
<br>
Michiel<br>
<br>
<br>
Zafar Ali wrote:<br>
&gt; <br>
&gt; At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:<br>
&gt; <br>
&gt; &gt; Hi Jonathan,<br>
&gt; &gt;<br>
&gt; &gt; Thanks for the quick response. Please see my comments
inline.<br>
&gt; &gt;<br>
&gt; &gt; Manoj<br>
&gt; &gt;<br>
&gt; &gt; Jonathan Lang wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Manoj,<br>
&gt; &gt; &gt;&nbsp;&nbsp; Please see inline.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; &gt; From: Manoj Sontakke
[<a href=3D"mailto:[email-masked]"=
 eudora=3D"autourl">mailto:[email-masked]</a>]<br>
&gt; &gt; &gt; &gt; Sent: Thursday, April 11, 2002 7:02 AM<br>
&gt; &gt; &gt; &gt; To: [email-masked]<br>
&gt; &gt; &gt; &gt; Subject: Question on LMP.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I have two questions on LMP.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;
--------------------------------------------------------------<br>
&gt; &gt; &gt; &gt; -----------------------------<br>
&gt; &gt; &gt; &gt; Q1.&nbsp; Control Channel Question<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Assuming a configuration as shown.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if1|---------------|if1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if2|---------------|if2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 1&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 2&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d1|---------------|d1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d2|---------------|d2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt; &gt; &gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt; &gt; &gt; &gt; -----------------<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I have two OXCs connected by four links. Consider d1,
d2 are configured<br>
&gt; &gt; &gt; &gt; to carry data and if1 and if2 are configured to carry
control data ( LMP<br>
&gt; &gt; &gt; &gt; messages and RSVP and OSPF messages).<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The LMP document defines control channels with an
unique identifier (<br>
&gt; &gt; &gt; &gt; control channel identifier ) between the negibouring
nodes.<br>
&gt; &gt; &gt; &gt; So also, the LMP messages are IP encapsulated.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Now, I have a couple of questions<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 1. Is there any association between the LMP control
channels to the<br>
&gt; &gt; &gt; &gt; physical interfaces( if1, if2). Because all the IP
packets are routed on<br>
&gt; &gt; &gt; &gt; the physical interfaces according to the routing
table. The control<br>
&gt; &gt; &gt; &gt; channel messages like&nbsp; ( config and configAck
etc.. ) can go on the any<br>
&gt; &gt; &gt; &gt; physical interface which is decided by the routing
table.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; In such case, are the control channels a pure logical
concept or do they<br>
&gt; &gt; &gt; &gt; have any physical interface significance &amp;
correlation [ mapping between<br>
&gt; &gt; &gt; &gt; control channles ( ccid ) and interfaces ( if1 and
if2 )] ?<br>
&gt; &gt;<br>
&gt; &gt; &gt; Control channels are associated with interfaces.<br>
&gt; &gt;<br>
&gt; &gt; Manoj-&gt; The draft does not say so explicitly. Besides, all
the LMP<br>
&gt; &gt; messages are IP encoded. So the routing table decides the
outgoing<br>
&gt; &gt; interface for sending the LMP messages (any packet for that
matter)<br>
&gt; &gt; depending upon the destination IP address.<br>
&gt; &gt;<br>
&gt; &gt; So is it possible to make such an association between the LMP
control<br>
&gt; &gt; channel and a physical interface (though it is=20
desirable)?<br>
&gt; <br>
&gt; Hi Manoj, et all:<br>
&gt; <br>
&gt; The association between the CC and data bearer link is neither
prevented nor enforced by the specification, as you also mentioned. IMO,
the association between the CC and data bearer link is a vendor specific
question. Vendors can manage the available set of CCs in the way they
would like to.<br>
&gt; I.e., a vendor may choose a specific CC to send all messages that
are pertaining to a data bearer link, etc. The key is that the receiver
node for the LMP messages should be able to receive LMP messages from any
CC that it=92s running with a given neighbor. This is of course with the
exception of<br>
&gt; LMP Hellos messages.<br>
&gt; <br>
&gt; &gt; Are we<br>
&gt; &gt; deviating from the standard IP implementation ?<br>
&gt; <br>
&gt; In selecting the CC by making an association between the CC and the
data link, one will NOT be diverting from IP. Specifically, one may
consider CC to be of two different types: interface bound or routed.
E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP
application can<br>
&gt; select a specific egress interface while using interface bound CCs,
etc.<br>
&gt; <br>
&gt; Thanks<br>
&gt; <br>
&gt; Regards=85 Zafar<br>
&gt; <br>
&gt; &lt;snip&gt;</font></blockquote></html>

--=====================_39133400==_.ALT--

Delivery-date: Tue, 16 Apr 2002 06:26:08 -0700
content-class: urn:content-classes:message
Subject: RE: Question on LMP-MIB ?
Date: Tue, 16 Apr 2002 09:24:27 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Zafar Ali" <[email-masked]>, "Loc Chu" <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1E54A.08853F52
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Zafar,
=20
You could keep the remote IPCC address in the LMP MIB (after I add this =
field to the control channel table).
=20
Martin

-----Original Message-----
From: Zafar Ali [mailto:[email-masked]]
Sent: Monday, April 15, 2002 5:36 PM
To: Loc Chu; [email-masked]; [email-masked]
Subject: Re: Question on LMP-MIB ?

At 04:13 PM 4/15/2002 -0500, Loc Chu wrote:

Hi all,=20

The Section 3 of the LMP draft states:=20

"To establish a control channel, the destination IP address on the  far =
end of=20
 the control channel must be known. This knowledge may be manually =
configured=20
 or automatically discovered."=20

Also, Section 9 of the LMP draft states:=20

"The manner in which a Config message is addressed may depend on the =
signaling=20
 transport mechanism.  When the transport mechanism is a point-to-point =
link, Config=20
 messages SHOULD be sent to the Multicast address (224.0.0.1).  =
Otherwise, Config=20
 messages MUST be sent to an IP address on the neighboring node.  This =
is configured=20
 at both ends of the control channel."=20

In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point =
link, we have to=20
use a specific IP address for the remote end of the IPCC.  Where do we =
keep the remote=20
IPCC Address ?=20

Hi Loc,=20

I think, the IP address of the neighboring node should also be used, in =
this case as well. Why you feel that IPCC address need to be different =
from IP address of the neighboring node?=20

Thanks

Regards... Zafar=20

if not, is it possible to have a field in lmpControlChannelEntry MIB for =
configuring=20
the remote IPCC address such as:=20

lmpCcRemoteIpAddr OBJECT-TYPE=20
   SYNTAX               InetAddress=20
   MAX-ACCESS    read-create=20
   STATUS               current=20
   DESCRIPTION "IP address associated with remote IPCC."=20
   ::=3D { lmpControlChannelEntry 23 }=20

Thanks in advance for your help or any clarification since my question =
is too=20
implementation specific.=20

Regards,=20

--=20

Loc Chu

Software Development

Engineer         Alcatel, USA=20

Research &

Innovation               =20

1000 Coit Rd. Plano, TX 75075 M/S:CTO2

Advanced Routers and Cross Connects   Phone: 972-477-2463=20

Fax:

972-477-2972
 =20

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

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

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

size=3D2>Zafar,</FONT></SPAN></DIV>
<DIV><SPAN class=3D749562313-16042002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D749562313-16042002><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
could keep the remote IPCC address in the LMP MIB (after I add this =
field to the=20
control channel table).</FONT></SPAN></DIV>
<DIV><SPAN class=3D749562313-16042002><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Martin</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Zafar Ali=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, April 15, 2002 5:36=20
  PM<BR><B>To:</B> Loc Chu; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> Re: Question on =
LMP-MIB=20
  ?<BR><BR></FONT></DIV><FONT size=3D3>At 04:13 PM 4/15/2002 -0500, Loc =
Chu=20
  wrote:<BR>
  <BLOCKQUOTE cite type=3D"cite">Hi all, <BR><BR>The Section 3 of the =
LMP draft=20
    states: <BR><BR>"To establish a control channel, the destination IP =
address=20
    on the&nbsp; far end of <BR>&nbsp;the control channel must be known. =
This=20
    knowledge may be manually configured <BR>&nbsp;or automatically =
discovered."=20
    <BR><BR>Also, Section 9 of the LMP draft states: <BR><BR>"The manner =
in=20
    which a Config message is addressed may depend on the signaling=20
    <BR>&nbsp;transport mechanism.&nbsp; When the transport mechanism is =
a=20
    point-to-point link, Config <BR>&nbsp;messages SHOULD be sent to the =

    Multicast address (224.0.0.1).&nbsp; Otherwise, Config =
<BR>&nbsp;messages=20
    MUST be sent to an IP address on the neighboring node.&nbsp; This is =

    configured <BR>&nbsp;at both ends of the control channel." =
<BR><BR>In case=20
    of IPCC's are out-of-fiber/out-of-band and NOT point-to-point link, =
we have=20
    to <BR>use a specific IP address for the remote end of the =
IPCC.&nbsp; Where=20
    do we keep the remote <BR>IPCC Address ? =
</FONT></BLOCKQUOTE><BR><FONT=20
  size=3D3>Hi Loc, <BR><BR>I think, the IP address of the neighboring =
node should=20
  also be used, in this case as well. Why you feel that IPCC address =
need to be=20
  different from IP address of the neighboring node?=20
  <BR><BR>Thanks<BR><BR>Regards... Zafar <BR><BR><BR>
  <BLOCKQUOTE cite type=3D"cite">if not, is it possible to have a field =
in=20
    lmpControlChannelEntry MIB for configuring <BR>the remote IPCC =
address such=20
    as: <BR><BR>lmpCcRemoteIpAddr OBJECT-TYPE <BR>&nbsp;&nbsp;=20
    =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
    InetAddress <BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-create=20
    <BR>&nbsp;&nbsp;=20
    =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
    current <BR>&nbsp;&nbsp; DESCRIPTION "IP address associated with =
remote=20
    IPCC." <BR>&nbsp;&nbsp; ::=3D { lmpControlChannelEntry 23 } =
<BR><BR>Thanks in=20
    advance for your help or any clarification since my question is too=20
    <BR>implementation specific. <BR><BR>Regards, <BR></FONT><PRE>--=20
Loc Chu
Software Development
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alcatel, USA=20
Research &amp;
Innovation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects&nbsp;&nbsp; Phone: =
972-477-2463&nbsp;
Fax:
972-477-2972</PRE><FONT face=3D"Courier New, Courier" =
size=3D3></FONT>&nbsp;=20
  </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1E54A.08853F52--

Delivery-date: Tue, 16 Apr 2002 06:20:33 -0700
From: "Vinay Vernekar" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Need for hierarchical SONET/SDH LSPs.
Date: Tue, 16 Apr 2002 18:48:19 +0530

This is a multi-part message in MIME format.

------=_NextPartTM-000-49e12798-512e-11d6-af80-0080c8048dde
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00EE_01C1E577.46FAE040"

------=_NextPart_000_00EE_01C1E577.46FAE040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
Can I have a SONET/SDH LSP that passes through a SONET ADM as its =
transit LSR??
Consider a situation as shown below -

A---------------B---------------C

The link A-B is a STS-12 link, B does a byte-interleaved multiplexing of =
4 STS-12 and forms a STS-48, thus B-C is STS-48.
Can a LSP for unstructured VC-4 be setup with A as ingress, B as transit =
and C as the egress??=20
As per the draft "Framework for GMPLS based control of SONET/SDH =
networks" the frames are not labeled instead it is the flow that is =
being labelled. It also mentions that tunnels should be used when =
switching from a different signal level i.e VC-12 to VC-4.=20
With this in mind, I would assume that a LSP as mentioned should be =
possible, because the signal type remains same i.e VC-4 even the frames =
get interleaved from STS-12 to STS-48.
Please correct me if I am wrong.

Thanks in advance.
Regards
Vinay

------=_NextPart_000_00EE_01C1E577.46FAE040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hi,</FONT></DIV>
<DIV><FONT face=3DArial>Can I have a SONET/SDH LSP that passes through a =
SONET ADM=20
as its transit LSR??</FONT></DIV>
<DIV><FONT face=3DArial>Consider a situation as shown below =
-</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>A---------------B---------------C</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>The link A-B is a STS-12 link, B does a =
byte-interleaved=20
multiplexing of 4 STS-12 and forms a STS-48, thus B-C is =
STS-48.</FONT></DIV>
<DIV><FONT face=3DArial>Can a LSP for unstructured VC-4 be setup with A =
as=20
ingress, B as transit and C as the egress?? </FONT></DIV>
<DIV><FONT face=3DArial>As per the draft "Framework for GMPLS based =
control of=20
SONET/SDH networks" the frames are not labeled instead it is the flow =
that is=20
being labelled. </FONT><FONT face=3DArial>It also mentions that tunnels =
should be=20
used when switching from a different signal level i.e&nbsp;VC-12 to =
VC-4.=20
</FONT></DIV>
<DIV><FONT face=3DArial>With this in mind, I would assume that a LSP as =
mentioned=20
should be possible, because the signal type remains same&nbsp;i.e VC-4 =
even the=20
frames get interleaved from STS-12 to STS-48.</FONT></DIV>
<DIV><FONT face=3DArial>Please correct me if I am wrong.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Thanks in advance.</FONT></DIV>
<DIV><FONT face=3DArial>Regards</FONT></DIV>
<DIV><FONT face=3DArial>Vinay</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00EE_01C1E577.46FAE040--

------=_NextPartTM-000-49e12798-512e-11d6-af80-0080c8048dde
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-49e12798-512e-11d6-af80-0080c8048dde--

Delivery-date: Tue, 16 Apr 2002 05:57:00 -0700
Cc: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Tue, 16 Apr 2002 14:56:14 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Zafar Ali <[email-masked]>
Original-CC: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Zafar,

Could you please clarify what is 'CC' ?
I've tried to read your email assuming 'CC'=3DCross Connect and
assuming 'CC'=3DConnection Controller, but failed.

I assume
  'SDCC' =3D section DCC / RS-DCC (D1-D3)
  'LDCC' =3D line DCC / MS-DCC (D4-D12)
correct ?

What is an SDCC/LDCC based CC ?
What is an interface bound IPCC ?

Please accept my apologies if these terms are well-known to this
group.

Thanks,

Michiel

Zafar Ali wrote:
> =

> At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
> =

> > Hi Jonathan,
> >
> > Thanks for the quick response. Please see my comments inline.
> >
> > Manoj
> >
> > Jonathan Lang wrote:
> > >
> > > Manoj,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Manoj Sontakke [mailto:[email-masked]]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: [email-masked]
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > > --------------------------------------------------------------
> > > > -----------------------------
> > > > Q1.  Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > > >                 -----------------               -----------------=

> > > >                 |               |               |               |=

> > > >                 |            if1|---------------|if1            |=

> > > >                 |            if2|---------------|if2            |=

> > > >                 |     OXC 1     |               |     OXC 2     |=

> > > >                 |             d1|---------------|d1             |=

> > > >                 |             d2|---------------|d2             |=

> > > >                 -----------------
> > > > -----------------
> > > >
> > > >
> > > > I have two OXCs connected by four links. Consider d1, d2 are conf=
igured
> > > > to carry data and if1 and if2 are configured to carry control dat=
a ( LMP
> > > > messages and RSVP and OSPF messages).
> > > >
> > > > The LMP document defines control channels with an unique identifi=
er (
> > > > control channel identifier ) between the negibouring nodes.
> > > > So also, the LMP messages are IP encapsulated.
> > > >
> > > > Now, I have a couple of questions
> > > >
> > > > 1. Is there any association between the LMP control channels to t=
he
> > > > physical interfaces( if1, if2). Because all the IP packets are ro=
uted on
> > > > the physical interfaces according to the routing table. The contr=
ol
> > > > channel messages like  ( config and configAck etc.. ) can go on t=
he any
> > > > physical interface which is decided by the routing table.
> > > >
> > > > In such case, are the control channels a pure logical concept or =
do they
> > > > have any physical interface significance & correlation [ mapping =
between
> > > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
> >
> > > Control channels are associated with interfaces.
> >
> > Manoj-> The draft does not say so explicitly. Besides, all the LMP
> > messages are IP encoded. So the routing table decides the outgoing
> > interface for sending the LMP messages (any packet for that matter)
> > depending upon the destination IP address.
> >
> > So is it possible to make such an association between the LMP control=

> > channel and a physical interface (though it is desirable)?
> =

> Hi Manoj, et all:
> =

> The association between the CC and data bearer link is neither prevente=
d nor enforced by the specification, as you also mentioned. IMO, the asso=
ciation between the CC and data bearer link is a vendor specific question=
=2E Vendors can manage the available set of CCs in the way they would lik=
e to.
> I.e., a vendor may choose a specific CC to send all messages that are p=
ertaining to a data bearer link, etc. The key is that the receiver node f=
or the LMP messages should be able to receive LMP messages from any CC th=
at it=92s running with a given neighbor. This is of course with the excep=
tion of
> LMP Hellos messages.
> =

> > Are we
> > deviating from the standard IP implementation ?
> =

> In selecting the CC by making an association between the CC and the dat=
a link, one will NOT be diverting from IP. Specifically, one may consider=
 CC to be of two different types: interface bound or routed. E.g., SDCC/ =
LDCC based CCs can be regarded as interface bound IPCCs. LMP application =
can
> select a specific egress interface while using interface bound CCs, etc=
=2E
> =

> Thanks
> =

> Regards=85 Zafar
> =

> <snip>

Delivery-date: Tue, 16 Apr 2002 05:38:44 -0700
Cc: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Tue, 16 Apr 2002 14:33:43 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Ravi Ravindran <[email-masked]>
Original-CC: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hello Ravi,

Thanks for your email.

I guess I can agree that Control Channel Management can be a 'light weight'
protocol. But wouldn't it then make sense to make Control Channel Management
optional ? Maybe some products want to use a standard routing protocol like
OSPF, RIP, I-ISIS etc.

On the 'faster' part of Control Channel Management: why does it need to be
fast (assuming it is indeed faster, which can be questioned) ?

My feeling is that the only answer you can give is 'for fault management'.
Correct ?
However, fault management is an optional procedure in LMP. It does not make
sense to me to make something mandatory that is only useful for something
that is optional.

Declaring fault management optional makes sense in my mind because a lot
of products don't need LMP's fault management. They can do with SONET/SDH
in-band 'RDI/REI' (Remote Defect Indication/Remote Error Indication)
or with OTN in-band 'BDI/BEI' (Backward Defect Indication/Backward Error
indication).

Best regards,

Michiel

> Ravi Ravindran wrote:
> 
> michiel,
> i don't think i could really respond to your query's relating to SONET/SDH. Coming to the usage of control channel management, its only that one could leverage on the faster light weighted hellos of LMP  which is order msec, compared to sec's in normal routing protocol, for faster recovery of
> control channel failures.
> 
> Ravi S. Ravindran
> Nortel Networks, Ottawa
> 
> -----Original Message-----
> From: Michiel van Everdingen [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 10:54 AM
> To: Ravindran, Ravi [CAR:0V13:EXCH]
> Cc: 'Manoj Sontakke'; Jonathan Lang; [email-masked]
> Subject: Re: Question on LMP.
> 
> Hello Ravi, Manoj,
> 
> > This is reiterating manoj's question, do we need some kind of association
> > between the routing protocol and the LMP which is supposed to provide a
> > reliable control channel for the control plane protocols.
> 
> 1. Do you also set up a control channel between neighbors switching at VC-12 /
>    VT-1.5 level ? In this case there is no DCC channel between the neighbors.
> 
> 2. Do you also set up a control channel between neighbors in case there is
>    a transparent cross connect in between that does not implement LMP/GMPLS ?
>    I.e. the data link is actually a 'serial compound link'.
> 
> Example of my second point, assume e.g. datalink is VC-4:
> +------+      +------+      +------+      +------+
> |    T-|--->--|-C--C-|--->--|-C  C-|--->--|-T    |
> |      |   A  |      |   B  |      |   C  |      |
> |      |      |      |      |      |      |      |
> | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> +------+      +------+      +------+      +------+
> 
> NE-2 does not implement LMP nor GMPLS. It simply is a fixed through-cross-
> connect for this data link. In this case, I'm assuming NE-1 and NE-3 need to be
> considered as switching neighbors that switch under GMPLS control.
> 
> > If we do not have
> > this, during a control channel failure (assuming a case where we have
> > multiple active control channels and physical interfaces between two
> > nodes), the control plane  protocols would have to rely on  the routing
> > protocol to detect the failure and reroute the packets, making the control
> > channel management of LMP less efficient.
> 
> *If* we need for some reason a control channel between switching neighbors,
> why don't we use an LSP to implement this control channel ? Why inventing
> again a new mechanism ?
> 
> But stepping back a bit, why do we need a 'reliable control channel' at
> all ? Why are normal routing protocols not sufficient ?
> 
> Thanks,
> 
> Michiel
> 
> --
> +------------------------------------------------------------------+
> | Michiel van Everdingen                                           |
> | Systems Engineer                                                 |
> | Lucent Technologies - Optical Networking Group                   |
> | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> | Huizen, The Netherlands        mailto:[email-masked]  |
> +------------------------------------------------------------------+

Delivery-date: Mon, 15 Apr 2002 20:45:24 -0700
Date: Mon, 15 Apr 2002 17:36:00 -0400
To: Loc Chu <[email-masked]>, [email-masked], [email-masked]
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP-MIB ?

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

At 04:13 PM 4/15/2002 -0500, Loc Chu wrote:
>Hi all,
>
>The Section 3 of the LMP draft states:
>
>"To establish a control channel, the destination IP address on the  far 
>end of
>  the control channel must be known. This knowledge may be manually 
> configured
>  or automatically discovered."
>
>Also, Section 9 of the LMP draft states:
>
>"The manner in which a Config message is addressed may depend on the 
>signaling
>  transport mechanism.  When the transport mechanism is a point-to-point 
> link, Config
>  messages SHOULD be sent to the Multicast address 
> (224.0.0.1).  Otherwise, Config
>  messages MUST be sent to an IP address on the neighboring node.  This is 
> configured
>  at both ends of the control channel."
>
>In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point 
>link, we have to
>use a specific IP address for the remote end of the IPCC.  Where do we 
>keep the remote
>IPCC Address ?

Hi Loc,

I think, the IP address of the neighboring node should also be used, in 
this case as well. Why you feel that IPCC address need to be different from 
IP address of the neighboring node?

Thanks

Regards... Zafar

>if not, is it possible to have a field in lmpControlChannelEntry MIB for 
>configuring
>the remote IPCC address such as:
>
>lmpCcRemoteIpAddr OBJECT-TYPE
>    SYNTAX               InetAddress
>    MAX-ACCESS    read-create
>    STATUS               current
>    DESCRIPTION "IP address associated with remote IPCC."
>    ::= { lmpControlChannelEntry 23 }
>
>Thanks in advance for your help or any clarification since my question is too
>implementation specific.
>
>Regards,
>--
>Loc Chu
>Software Development Engineer         Alcatel, USA
>Research & Innovation                 1000 Coit Rd. Plano, TX 75075 M/S:CTO2
>Advanced Routers and Cross Connects   Phone: 972-477-2463  Fax: 972-477-2972

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

<html>
<font size=3>At 04:13 PM 4/15/2002 -0500, Loc Chu wrote:<br>
<blockquote type=cite cite>Hi all, <br>
<br>
The Section 3 of the LMP draft states: <br>
<br>
&quot;To establish a control channel, the destination IP address on
the&nbsp; far end of <br>
&nbsp;the control channel must be known. This knowledge may be manually
configured <br>
&nbsp;or automatically discovered.&quot; <br>
<br>
Also, Section 9 of the LMP draft states: <br>
<br>
&quot;The manner in which a Config message is addressed may depend on the
signaling <br>
&nbsp;transport mechanism.&nbsp; When the transport mechanism is a
point-to-point link, Config <br>
&nbsp;messages SHOULD be sent to the Multicast address (224.0.0.1).&nbsp;
Otherwise, Config <br>
&nbsp;messages MUST be sent to an IP address on the neighboring
node.&nbsp; This is configured <br>
&nbsp;at both ends of the control channel.&quot; <br>
<br>
In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point
link, we have to <br>
use a specific IP address for the remote end of the IPCC.&nbsp; Where do
we keep the remote <br>
IPCC Address ? </font></blockquote><br>
<font size=3>Hi Loc, <br>
<br>
I think, the IP address of the neighboring node should also be used, in
this case as well. Why you feel that IPCC address need to be different
from IP address of the neighboring node? <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite>if not, is it possible to have a field in
lmpControlChannelEntry MIB for configuring <br>
the remote IPCC address such as: <br>
<br>
lmpCcRemoteIpAddr OBJECT-TYPE <br>
&nbsp;&nbsp;
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
InetAddress <br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create <br>
&nbsp;&nbsp;
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current <br>
&nbsp;&nbsp; DESCRIPTION &quot;IP address associated with remote
IPCC.&quot; <br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 23 } <br>
<br>
Thanks in advance for your help or any clarification since my question is
too <br>
implementation specific. <br>
<br>
Regards, <br>
</font><pre>-- 
Loc Chu
Software Development
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alcatel, USA 
Research &amp;
Innovation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects&nbsp;&nbsp; Phone: 972-477-2463&nbsp;
Fax:
972-477-2972</pre><font face="Courier New, Courier" size=3></font>&nbsp;
</blockquote></html>

--=====================_3052419==_.ALT--

Delivery-date: Mon, 15 Apr 2002 14:37:04 -0700
Date: Mon, 15 Apr 2002 17:35:16 -0400
To: Loc Chu <[email-masked]>, [email-masked], [email-masked]
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP-MIB ?

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

At 04:13 PM 4/15/2002 -0500, Loc Chu wrote:
>Hi all,
>
>The Section 3 of the LMP draft states:
>
>"To establish a control channel, the destination IP address on the  far 
>end of
>  the control channel must be known. This knowledge may be manually 
> configured
>  or automatically discovered."
>
>Also, Section 9 of the LMP draft states:
>
>"The manner in which a Config message is addressed may depend on the 
>signaling
>  transport mechanism.  When the transport mechanism is a point-to-point 
> link, Config
>  messages SHOULD be sent to the Multicast address 
> (224.0.0.1).  Otherwise, Config
>  messages MUST be sent to an IP address on the neighboring node.  This is 
> configured
>  at both ends of the control channel."
>
>In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point 
>link, we have to
>use a specific IP address for the remote end of the IPCC.  Where do we 
>keep the remote
>IPCC Address ?

Hi Loc,

I think, the IP address of the neighboring node should also be used, in 
this case as well. Why you feel that IPCC address need to be different from 
IP address of the neighboring node?

Thanks

Regards... Zafar

>if not, is it possible to have a field in lmpControlChannelEntry MIB for 
>configuring
>the remote IPCC address such as:
>
>lmpCcRemoteIpAddr OBJECT-TYPE
>    SYNTAX               InetAddress
>    MAX-ACCESS    read-create
>    STATUS               current
>    DESCRIPTION "IP address associated with remote IPCC."
>    ::= { lmpControlChannelEntry 23 }
>
>Thanks in advance for your help or any clarification since my question is too
>implementation specific.
>
>Regards,
>--
>Loc Chu
>Software Development Engineer         Alcatel, USA
>Research & Innovation                 1000 Coit Rd. Plano, TX 75075 M/S:CTO2
>Advanced Routers and Cross Connects   Phone: 972-477-2463  Fax: 972-477-2972

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

<html>
<font size=3>At 04:13 PM 4/15/2002 -0500, Loc Chu wrote:<br>
<blockquote type=cite cite>Hi all, <br>
<br>
The Section 3 of the LMP draft states: <br>
<br>
&quot;To establish a control channel, the destination IP address on
the&nbsp; far end of <br>
&nbsp;the control channel must be known. This knowledge may be manually
configured <br>
&nbsp;or automatically discovered.&quot; <br>
<br>
Also, Section 9 of the LMP draft states: <br>
<br>
&quot;The manner in which a Config message is addressed may depend on the
signaling <br>
&nbsp;transport mechanism.&nbsp; When the transport mechanism is a
point-to-point link, Config <br>
&nbsp;messages SHOULD be sent to the Multicast address (224.0.0.1).&nbsp;
Otherwise, Config <br>
&nbsp;messages MUST be sent to an IP address on the neighboring
node.&nbsp; This is configured <br>
&nbsp;at both ends of the control channel.&quot; <br>
<br>
In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point
link, we have to <br>
use a specific IP address for the remote end of the IPCC.&nbsp; Where do
we keep the remote <br>
IPCC Address ? </font></blockquote><br>
Hi Loc, <br>
<br>
I think, the <font size=3>IP address of the neighboring node should also
be used, in this case as well. Why you feel that IPCC address need to be
different from IP address of the neighboring node? <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite>if not, is it possible to have a field in
lmpControlChannelEntry MIB for configuring <br>
the remote IPCC address such as: <br>
<br>
lmpCcRemoteIpAddr OBJECT-TYPE <br>
&nbsp;&nbsp;
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
InetAddress <br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create <br>
&nbsp;&nbsp;
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current <br>
&nbsp;&nbsp; DESCRIPTION &quot;IP address associated with remote
IPCC.&quot; <br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 23 } <br>
<br>
Thanks in advance for your help or any clarification since my question is
too <br>
implementation specific. <br>
<br>
Regards, <br>
</font><pre>-- 
Loc Chu
Software Development
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alcatel, USA 
Research &amp;
Innovation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects&nbsp;&nbsp; Phone: 972-477-2463&nbsp;
Fax:
972-477-2972</pre><font face="Courier New, Courier" size=3></font>&nbsp;
</blockquote></html>

--=====================_24540397==_.ALT--

Delivery-date: Mon, 15 Apr 2002 14:15:23 -0700
Date: Mon, 15 Apr 2002 16:13:54 -0500
From: Loc Chu <[email-masked]>
Organization: Research & Innovation
To: [email-masked], [email-masked]
Subject: Question on LMP-MIB ?

--------------4D851535EE0E6DB39204E4CD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

The Section 3 of the LMP draft states:

"To establish a control channel, the destination IP address on the  far end
of
 the control channel must be known. This knowledge may be manually
configured
 or automatically discovered."

Also, Section 9 of the LMP draft states:

"The manner in which a Config message is addressed may depend on the
signaling
 transport mechanism.  When the transport mechanism is a point-to-point
link, Config
 messages SHOULD be sent to the Multicast address (224.0.0.1).  Otherwise,
Config
 messages MUST be sent to an IP address on the neighboring node.  This is
configured
 at both ends of the control channel."

In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point link,
we have to
use a specific IP address for the remote end of the IPCC.  Where do we keep
the remote
IPCC Address ?

if not, is it possible to have a field in lmpControlChannelEntry MIB for
configuring
the remote IPCC address such as:

lmpCcRemoteIpAddr OBJECT-TYPE
   SYNTAX               InetAddress
   MAX-ACCESS    read-create
   STATUS               current
   DESCRIPTION "IP address associated with remote IPCC."
   ::= { lmpControlChannelEntry 23 }

Thanks in advance for your help or any clarification since my question is
too
implementation specific.

Regards,

--
Loc Chu
Software Development Engineer         Alcatel, USA
Research & Innovation                 1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects   Phone: 972-477-2463  Fax: 972-477-2972

--------------4D851535EE0E6DB39204E4CD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi all,
<p>The Section 3 of the LMP draft states:
<p>"To establish a control channel, the destination IP address on the&nbsp;
far end of
<br>&nbsp;the control channel must be known. This knowledge may be manually
configured
<br>&nbsp;or automatically discovered."
<p>Also, Section 9 of the LMP draft states:
<p>"The manner in which a Config message is addressed may depend on the
signaling
<br>&nbsp;transport mechanism.&nbsp; When the transport mechanism is a
point-to-point link, Config
<br>&nbsp;messages SHOULD be sent to the Multicast address (224.0.0.1).&nbsp;
Otherwise, Config
<br>&nbsp;messages MUST be sent to an IP address on the neighboring node.&nbsp;
This is configured
<br>&nbsp;at both ends of the control channel."
<p>In case of IPCC's are out-of-fiber/out-of-band and NOT point-to-point
link, we have to
<br>use a specific IP address for the remote end of the IPCC.&nbsp; Where
do we keep the remote
<br>IPCC Address ?
<p>if not, is it possible to have a field in lmpControlChannelEntry MIB
for configuring
<br>the remote IPCC address such as:
<p>lmpCcRemoteIpAddr OBJECT-TYPE
<br>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
InetAddress
<br>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create
<br>&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current
<br>&nbsp;&nbsp; DESCRIPTION "IP address associated with remote IPCC."
<br>&nbsp;&nbsp; ::= { lmpControlChannelEntry 23 }
<p>Thanks in advance for your help or any clarification since my question
is too
<br>implementation specific.
<p>Regards,
<pre>--&nbsp;
Loc Chu
Software Development Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alcatel, USA&nbsp;
Research &amp; Innovation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects&nbsp;&nbsp; Phone: 972-477-2463&nbsp; Fax: 972-477-2972</pre>
&nbsp;</html>

--------------4D851535EE0E6DB39204E4CD--

Envelope-to: [email-masked]
Delivery-date: Mon, 15 Apr 2002 13:53:02 -0700
Date: Mon, 15 Apr 2002 13:50:18 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: SONET/SDH and PDH

Hi,

The following changes have been proposed for the generalized
signaling documents:
a) the SONET and SDH values for LSP encoding be merged to a single
   code point; ditto for ANSI and ETSI PDH.
b) the SONET and SDH values for Generalized PID (G-PID) be merged to
   a single code point; ditto for ANSI and ETSI PDH.

Current LSP encoding values:
            3         ANSI PDH
            4         ETSI PDH
            5         SDH ITU-T G.707
            6         SONET ANSI T1.105

New LSP encoding:
            x         ANSI/ETSI PDH
            y         SDH ITU-T G.707/SONET ANSI T1.105

(x and y to be determined)

Current G-PID values:
         34     SDH                                    Lambda, Fiber
         35     SONET                                  Lambda, Fiber
...
         38     ETSI PDH                               SDH
         39     ANSI PDH                               SONET, SDH

New G-PID values:
          p     SDH/SONET                              Lambda, Fiber
          q     ANSI/ETSI PDH                          SONET, SDH

(p and q to be determined).

Any objections to these changes?

Kireeti.

Delivery-date: Mon, 15 Apr 2002 10:15:47 -0700
Date: Mon, 15 Apr 2002 13:13:21 -0400
To: Manoj Sontakke <[email-masked]>, Jonathan Lang <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Question on LMP.
Cc: [email-masked]

--=====================_8825029==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
>Hi Jonathan,
>
>Thanks for the quick response. Please see my comments inline.
>
>Manoj
>
>Jonathan Lang wrote:
> >
> > Manoj,
> >   Please see inline.
> >
> > Thanks,
> > Jonathan
> >
> > > -----Original Message-----
> > > From: Manoj Sontakke [mailto:[email-masked]]
> > > Sent: Thursday, April 11, 2002 7:02 AM
> > > To: [email-masked]
> > > Subject: Question on LMP.
> > >
> > >
> > > Hi,
> > >
> > > I have two questions on LMP.
> > >
> > > --------------------------------------------------------------
> > > -----------------------------
> > > Q1.  Control Channel Question
> > >
> > > Assuming a configuration as shown.
> > >
> > >
> > >                 -----------------               -----------------
> > >                 |               |               |               |
> > >                 |            if1|---------------|if1            |
> > >                 |            if2|---------------|if2            |
> > >                 |     OXC 1     |               |     OXC 2     |
> > >                 |             d1|---------------|d1             |
> > >                 |             d2|---------------|d2             |
> > >                 -----------------
> > > -----------------
> > >
> > >
> > > I have two OXCs connected by four links. Consider d1, d2 are=
 configured
> > > to carry data and if1 and if2 are configured to carry control data (=
 LMP
> > > messages and RSVP and OSPF messages).
> > >
> > > The LMP document defines control channels with an unique identifier (
> > > control channel identifier ) between the negibouring nodes.
> > > So also, the LMP messages are IP encapsulated.
> > >
> > > Now, I have a couple of questions
> > >
> > > 1. Is there any association between the LMP control channels to the
> > > physical interfaces( if1, if2). Because all the IP packets are routed=
 on
> > > the physical interfaces according to the routing table. The control
> > > channel messages like  ( config and configAck etc.. ) can go on the=
 any
> > > physical interface which is decided by the routing table.
> > >
> > > In such case, are the control channels a pure logical concept or do=
 they
> > > have any physical interface significance & correlation [ mapping=
 between
> > > control channles ( ccid ) and interfaces ( if1 and if2 )] ?
>
> > Control channels are associated with interfaces.
>
>Manoj-> The draft does not say so explicitly. Besides, all the LMP
>messages are IP encoded. So the routing table decides the outgoing
>interface for sending the LMP messages (any packet for that matter)
>depending upon the destination IP address.
>
>So is it possible to make such an association between the LMP control
>channel and a physical interface (though it is desirable)?

Hi Manoj, et all:

The association between the CC and data bearer link is neither prevented=20
nor enforced by the specification, as you also mentioned. IMO, the=20
association between the CC and data bearer link is a vendor specific=20
question. Vendors can manage the available set of CCs in the way they would=
=20
like to. I.e., a vendor may choose a specific CC to send all messages that=
=20
are pertaining to a data bearer link, etc. The key is that the receiver=20
node for the LMP messages should be able to receive LMP messages from any=20
CC that it=92s running with a given neighbor. This is of course with the=20
exception of LMP Hellos messages.

>Are we
>deviating from the standard IP implementation ?

In selecting the CC by making an association between the CC and the data=20
link, one will NOT be diverting from IP. Specifically, one may consider CC=
=20
to be of two different types: interface bound or routed. E.g., SDCC/ LDCC=20
based CCs can be regarded as interface bound IPCCs. LMP application can=20
select a specific egress interface while using interface bound CCs, etc.

Thanks

Regards=85 Zafar

<snip>
--=====================_8825029==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<font size=3D3>At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:<br>
<blockquote type=3Dcite cite>Hi Jonathan,<br>
<br>
Thanks for the quick response. Please see my comments inline.<br>
<br>
Manoj<br>
<br>
Jonathan Lang wrote:<br>
&gt; <br>
&gt; Manoj,<br>
&gt;&nbsp;&nbsp; Please see inline.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; Jonathan<br>
&gt; <br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Manoj Sontakke
[<a href=3D"mailto:[email-masked]"=
 eudora=3D"autourl">mailto:[email-masked]</a>]<br>
&gt; &gt; Sent: Thursday, April 11, 2002 7:02 AM<br>
&gt; &gt; To: [email-masked]<br>
&gt; &gt; Subject: Question on LMP.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; I have two questions on LMP.<br>
&gt; &gt;<br>
&gt; &gt;
--------------------------------------------------------------<br>
&gt; &gt; -----------------------------<br>
&gt; &gt; Q1.&nbsp; Control Channel Question<br>
&gt; &gt;<br>
&gt; &gt; Assuming a configuration as shown.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if1|---------------|if1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if2|---------------|if2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
|<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 1&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; OXC 2&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d1|---------------|d1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
d2|---------------|d2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
|<br>
&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
-----------------<br>
&gt; &gt; -----------------<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I have two OXCs connected by four links. Consider d1, d2 are
configured<br>
&gt; &gt; to carry data and if1 and if2 are configured to carry control
data ( LMP<br>
&gt; &gt; messages and RSVP and OSPF messages).<br>
&gt; &gt;<br>
&gt; &gt; The LMP document defines control channels with an unique
identifier (<br>
&gt; &gt; control channel identifier ) between the negibouring
nodes.<br>
&gt; &gt; So also, the LMP messages are IP encapsulated.<br>
&gt; &gt;<br>
&gt; &gt; Now, I have a couple of questions<br>
&gt; &gt;<br>
&gt; &gt; 1. Is there any association between the LMP control channels to
the<br>
&gt; &gt; physical interfaces( if1, if2). Because all the IP packets are
routed on<br>
&gt; &gt; the physical interfaces according to the routing table. The
control<br>
&gt; &gt; channel messages like&nbsp; ( config and configAck etc.. ) can
go on the any<br>
&gt; &gt; physical interface which is decided by the routing table.<br>
&gt; &gt;<br>
&gt; &gt; In such case, are the control channels a pure logical concept
or do they<br>
&gt; &gt; have any physical interface significance &amp; correlation [
mapping between<br>
&gt; &gt; control channles ( ccid ) and interfaces ( if1 and if2 )]
?<br>
<br>
&gt; Control channels are associated with interfaces.<br>
<br>
Manoj-&gt; The draft does not say so explicitly. Besides, all the
LMP<br>
messages are IP encoded. So the routing table decides the outgoing<br>
interface for sending the LMP messages (any packet for that matter)<br>
depending upon the destination IP address.<br>
<br>
So is it possible to make such an association between the LMP
control<br>
channel and a physical interface (though it is desirable)?
</font></blockquote><br>
Hi Manoj, et all:<br>
<br>
<font face=3D"Arial, Helvetica" size=3D3>The association between the CC and
data bearer link is neither prevented nor enforced by the specification,
as you also mentioned. IMO, the association between the CC and data
bearer link is a vendor specific question. Vendors can manage the
available set of CCs in the way they would like to. I.e., a vendor may
choose a specific CC to send all messages that are pertaining to a data
bearer link, etc. The key is that the receiver node for the LMP messages
should be able to receive LMP messages from any CC that it=92s running with
a given neighbor. This is of course with the exception of LMP Hellos
messages. <br>
<br>
</font><blockquote type=3Dcite cite>Are we<br>
deviating from the standard IP implementation
?</blockquote><font face=3D"Arial, Helvetica" size=3D3><br>
In selecting the CC by making an association between the CC and the data
link, one will NOT be diverting from IP. Specifically, one may consider
CC to be of two different types: interface bound or routed. E.g., SDCC/
LDCC based CCs can be regarded as interface bound IPCCs. LMP application
can select a specific egress interface while using interface bound CCs,
etc. <br>
<br>
Thanks<br>
<br>
Regards=85 Zafar <br>
<br>
</font>&lt;snip&gt;</html>

--=====================_8825029==_.ALT--

Delivery-date: Mon, 15 Apr 2002 09:56:01 -0700
Date: Mon, 15 Apr 2002 09:54:02 -0700
To: [email-masked]
From: Suresh Katukam <[email-masked]>
Subject: Re: Fwd: Re: SE style in optical networks
Cc: [email-masked]

Zhi, Sudheer and others,

Looks like this was lost in all other mails.. So please take a look
at this..

At 03:03 PM 4/12/2002 -0700, Suresh Katukam wrote:

>>Tom and all,
>>
>>I think everyone seemed to pick on my terminology or misinterpreted
>>what I said.
>>
>>Here is an example:
>>
>>          1+1                        1+1
>>A ----------------B --------- C ------------D
>>                      \          /
>>                        \       /
>>                           E
>>
>>
>>A - B & C - D 1+1 line protected
>>B - C, C - E, B - E are all unprotected links.
>>
>>Say, one wants to create a protected LSP from A to D.
>>then, you would create one primary LSP from A to D via
>>A - B - C - D, and then you would create another LSP
>>from A to D using SE style ( to indicate that this is an
>>alternate path for same Tunnel ) via A - B - E - C - D.
>>This way B - C is protected by B - E - C.
>>
>>B - C - E is not configured as a UPSR. All unprotected links.
>>Virtual UPSR can be created such a way that B has a bridge
>>and C has a selector. Ofcourse, for bidirectional LSP, you need
>>the same thing in the opposite direction too.
>>
>>Now, what do you call this kind of protection? Protected LSP?
>>But not 1+1 path protected  - since it is not end-to-end path
>>protected.
>>
>>To clarify again, this is when you would use SE style.
>>
>>Thanks
>>Suresh
>>
>>
>>At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote:
>>
>>
>>>>This can be used to set up Protected circuits which may contain
>>>>1+1 lines and 1+1 path protected segments. So on 1+1 line
>>>>protected segments, you Share the bandwidth among primary
>>>>and alternate paths.
>>>
>>>         You do not share the bandwidth across 1+1 circuits. You
>>>double-book the bandwidth because the same packets are
>>>sent twice: once over each LSP.  You only share bandwidth
>>>with 1:N.
>>>
>>>         --Tom
>>>
>>>
>>>>Setting up protected circuits is not considered
>>>>in detail so far. Hopefully, P&R design team will consider this..
>>>>
>>>>Thanks,
>>>>Suresh
>>>>
>>>>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote:
>>>>>Hi,
>>>>>
>>>>>How does SE style of RSVP signalling fits in the optical nature of network
>>>>>i.e. in wavelength, TDM switching etc.
>>>>>
>>>>>  In other words, How two lsp can share resource in optical networks??
>>>>>
>>>>>Regards,
>>>>>Khuzema.
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>Mathematics is the supreme nostalgia of our time.
>

Delivery-date: Mon, 15 Apr 2002 09:44:06 -0700
From: "Ravi Ravindran"<[email-masked]>
To: "'Michiel van Everdingen'" <[email-masked]>
Cc: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: RE: Question on LMP.
Date: Mon, 15 Apr 2002 12:40:16 -0400

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

------_=_NextPart_001_01C1E49C.393012CC
Content-Type: text/plain;
	charset="iso-8859-1"

michiel,
i don't think i could really respond to your query's relating to SONET/SDH.
Coming to the usage of control channel management, its only that one could
leverage on the faster light weighted hellos of LMP  which is order msec,
compared to sec's in normal routing protocol, for faster recovery of control
channel failures. 

Ravi S. Ravindran
Nortel Networks, Ottawa

-----Original Message-----
From: Michiel van Everdingen [mailto:[email-masked]]
Sent: Monday, April 15, 2002 10:54 AM
To: Ravindran, Ravi [CAR:0V13:EXCH]
Cc: 'Manoj Sontakke'; Jonathan Lang; [email-masked]
Subject: Re: Question on LMP.

Hello Ravi, Manoj,

> This is reiterating manoj's question, do we need some kind of association
> between the routing protocol and the LMP which is supposed to provide a
> reliable control channel for the control plane protocols.

1. Do you also set up a control channel between neighbors switching at VC-12
/
   VT-1.5 level ? In this case there is no DCC channel between the
neighbors.

2. Do you also set up a control channel between neighbors in case there is
   a transparent cross connect in between that does not implement LMP/GMPLS
?
   I.e. the data link is actually a 'serial compound link'.

Example of my second point, assume e.g. datalink is VC-4:
+------+      +------+      +------+      +------+
|    T-|--->--|-C--C-|--->--|-C  C-|--->--|-T    |
|      |   A  |      |   B  |      |   C  |      |
|      |      |      |      |      |      |      |
| NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
+------+      +------+      +------+      +------+

NE-2 does not implement LMP nor GMPLS. It simply is a fixed through-cross-
connect for this data link. In this case, I'm assuming NE-1 and NE-3 need to
be
considered as switching neighbors that switch under GMPLS control.

> If we do not have
> this, during a control channel failure (assuming a case where we have
> multiple active control channels and physical interfaces between two
> nodes), the control plane  protocols would have to rely on  the routing
> protocol to detect the failure and reroute the packets, making the control
> channel management of LMP less efficient.

*If* we need for some reason a control channel between switching neighbors,
why don't we use an LSP to implement this control channel ? Why inventing
again a new mechanism ?

But stepping back a bit, why do we need a 'reliable control channel' at
all ? Why are normal routing protocols not sufficient ?

Thanks,

Michiel

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

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

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

<P><FONT SIZE=3D2>michiel,</FONT>
<BR><FONT SIZE=3D2>i don't think i could really respond to your query's =
relating to SONET/SDH. Coming to the usage of control channel =
management, its only that one could leverage on the faster light =
weighted hellos of LMP&nbsp; which is order msec, compared to sec's in =
normal routing protocol, for faster recovery of control channel =
failures. </FONT></P>

<P><FONT SIZE=3D2>Ravi S. Ravindran</FONT>
<BR><FONT SIZE=3D2>Nortel Networks, Ottawa</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michiel van Everdingen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 15, 2002 10:54 AM</FONT>
<BR><FONT SIZE=3D2>To: Ravindran, Ravi [CAR:0V13:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'Manoj Sontakke'; Jonathan Lang; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Question on LMP.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Ravi, Manoj,</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; This is reiterating manoj's question, do we need =
some kind of association</FONT>
<BR><FONT SIZE=3D2>&gt; between the routing protocol and the LMP which =
is supposed to provide a</FONT>
<BR><FONT SIZE=3D2>&gt; reliable control channel for the control plane =
protocols.</FONT>
</P>

<P><FONT SIZE=3D2>1. Do you also set up a control channel between =
neighbors switching at VC-12 /</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; VT-1.5 level ? In this case there is no =
DCC channel between the neighbors.</FONT>
</P>

<P><FONT SIZE=3D2>2. Do you also set up a control channel between =
neighbors in case there is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; a transparent cross connect in between =
that does not implement LMP/GMPLS ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I.e. the data link is actually a =
'serial compound link'.</FONT>
</P>

<P><FONT SIZE=3D2>Example of my second point, assume e.g. datalink is =
VC-4:</FONT>
<BR><FONT SIZE=3D2>+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------+</FONT>
<BR><FONT SIZE=3D2>|&nbsp;&nbsp;&nbsp; =
T-|---&gt;--|-C--C-|---&gt;--|-C&nbsp; =
C-|---&gt;--|-T&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; =
A&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; B&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; C&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>| NE-1 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | NE-2 =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | NE-3 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| NE-4 |</FONT>
<BR><FONT SIZE=3D2>+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------+</FONT>
</P>

<P><FONT SIZE=3D2>NE-2 does not implement LMP nor GMPLS. It simply is a =
fixed through-cross-</FONT>
<BR><FONT SIZE=3D2>connect for this data link. In this case, I'm =
assuming NE-1 and NE-3 need to be</FONT>
<BR><FONT SIZE=3D2>considered as switching neighbors that switch under =
GMPLS control.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; If we do not have</FONT>
<BR><FONT SIZE=3D2>&gt; this, during a control channel failure =
(assuming a case where we have</FONT>
<BR><FONT SIZE=3D2>&gt; multiple active control channels and physical =
interfaces between two</FONT>
<BR><FONT SIZE=3D2>&gt; nodes), the control plane&nbsp; protocols would =
have to rely on&nbsp; the routing</FONT>
<BR><FONT SIZE=3D2>&gt; protocol to detect the failure and reroute the =
packets, making the control</FONT>
<BR><FONT SIZE=3D2>&gt; channel management of LMP less =
efficient.</FONT>
</P>

<P><FONT SIZE=3D2>*If* we need for some reason a control channel =
between switching neighbors,</FONT>
<BR><FONT SIZE=3D2>why don't we use an LSP to implement this control =
channel ? Why inventing</FONT>
<BR><FONT SIZE=3D2>again a new mechanism ?</FONT>
</P>

<P><FONT SIZE=3D2>But stepping back a bit, why do we need a 'reliable =
control channel' at</FONT>
<BR><FONT SIZE=3D2>all ? Why are normal routing protocols not =
sufficient ?</FONT>
</P>
<BR>

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

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

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>+--------------------------------------------------------------=
----+</FONT>
<BR><FONT SIZE=3D2>| Michiel van =
Everdingen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>| Systems =
Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>| Lucent Technologies - Optical Networking =
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>| Botterstraat 45, 1271 =
XL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone : +31 35 687 =
4883&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>| P.O. Box 18, 1270 =
AA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax&nbsp;&nbsp; : +31 35 687 =
5976&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>| Huizen, The =
Netherlands&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
om</A>&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>+--------------------------------------------------------------=
----+</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E49C.393012CC--

Delivery-date: Mon, 15 Apr 2002 07:55:30 -0700
Cc: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Date: Mon, 15 Apr 2002 16:53:36 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Ravi Ravindran <[email-masked]>
Original-CC: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: Question on LMP.

Hello Ravi, Manoj,

> This is reiterating manoj's question, do we need some kind of association
> between the routing protocol and the LMP which is supposed to provide a
> reliable control channel for the control plane protocols.

1. Do you also set up a control channel between neighbors switching at VC-12 /
   VT-1.5 level ? In this case there is no DCC channel between the neighbors.

2. Do you also set up a control channel between neighbors in case there is
   a transparent cross connect in between that does not implement LMP/GMPLS ?
   I.e. the data link is actually a 'serial compound link'.

Example of my second point, assume e.g. datalink is VC-4:
+------+      +------+      +------+      +------+
|    T-|--->--|-C--C-|--->--|-C  C-|--->--|-T    |
|      |   A  |      |   B  |      |   C  |      |
|      |      |      |      |      |      |      |
| NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
+------+      +------+      +------+      +------+

NE-2 does not implement LMP nor GMPLS. It simply is a fixed through-cross-
connect for this data link. In this case, I'm assuming NE-1 and NE-3 need to be
considered as switching neighbors that switch under GMPLS control.

> If we do not have
> this, during a control channel failure (assuming a case where we have
> multiple active control channels and physical interfaces between two
> nodes), the control plane  protocols would have to rely on  the routing
> protocol to detect the failure and reroute the packets, making the control
> channel management of LMP less efficient.

*If* we need for some reason a control channel between switching neighbors,
why don't we use an LSP to implement this control channel ? Why inventing
again a new mechanism ?

But stepping back a bit, why do we need a 'reliable control channel' at
all ? Why are normal routing protocols not sufficient ?

Thanks,

Michiel

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Mon, 15 Apr 2002 07:31:22 -0700
Cc: [email-masked]
Date: Mon, 15 Apr 2002 16:29:54 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Jonathan,

Let me start with a general question:

Does this working group think it is useful to extend LMP with neighbor
discovery (at the transmission layer) yes or no ?
If 'no', where do you want to get it defined ?

Specific reactions to your email:

> Sending the BeginVerify assumes you know where to send control messages.
> This is separate from discovering the data interfaces. This is why using the
> term Neighbor Discovery can often be confusing.  You actually have discovery
> at various levels. G.7714 talks about this in a little more detail.

Why is the term "Neighbor Discovery" confusing ? Neighbor discovery simply
discovers the other end of the data link.
(data link = component link = linkConnection)

I'm discussing neighbor discovery at the transmission layer on the levels I
mentioned in my first email in this thread:
STM-N, OC-N, STS-1/3/.../VC-3/4/...,VT-1.5/VC-11/12.

My proposal that started this thread allows the same procedure to be used,
regardless of the transmission layer. E.g. (using LMP terminology):
- by using J0 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
  it is possible to discover OC-n data links.
- similarly: by using J1 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
  it is possible to discover STS-1 data links.
- similarly: by using J2 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
  it is possible to discover VT-1.5 data links.

> Link correlation procedure also provides the local/remote mapping for all
> data links. The Ack message provides this mapping (in addition to Test
> message Ack) for each data channel individually.

OK. So you agree that link correlation (the linkSummary message) can be used
to reveal the locally discovered mapping
  <Local_Node_Id, Local_Interface_Id, Remote_Node_Id, Remote_Interface_Id>
to the remote node. Correct ?

> Verification mechanism is used for data link discovery. Without exchanging
> this parameter, you'd have to configure it on both nodes for each port/node
> pair.

Could you please be specific on what is wrong with the proposal that started
this thread ? In this proposal, I don't use the verification mechanism, yet
I don't have to configure the neighbor information on both nodes for each
port/node pair.

> Furthermore, if run LMP-WDM, you may have to configure yet another
> mechanism for your wdm neighbor if the termination capabilities are
> different.

Can we please focus on the mechanism for discovering switching neighbors
first ?
If you don't agree, please be specific on the problems you foresee.
Personally, I don't see a problem to extend the discovery mechanism as
I proposed to discover adjacency between a switching node and a
multiplexing node.

> > I don't understand why the normal network-layer mechanisms (defined in
> e.g.
> > OSPF or I-ISIS) are not sufficient ?
> > Why do we need the LMP specific 'Config' 'ConfigAck' and 'ConfigNack'
> > messages ?
> These are used to configure the LMP Hellos that are used to rapidly detect
> failures along the control channel.

Earlier in this thread you stated that I can turn off the LMP Hellos...
so in this case 'Config' 'ConfigAck' and 'ConfigNack' are useless ?

Are normal network layer Hellos not good enough ?
Are you aware that the DCN network layer can be extended with MPLS ?
Are you aware that MS/line failure indications (e.g. MS-TSF or line-TSF)
can be used to 'rapidly detect failures' in DCC channels. ?

Are LMP Hellos faster than normal network layer Hellos ?

Repeating my earlier questions:
- Why is 'control channel management' mandatory ?
- Why are normal (i.e. not LMP specific) network layer mechanisms not
  sufficient ?

Thanks,

Michiel

Jonathan Lang wrote:
> 
> Michiel,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Michiel van Everdingen [mailto:[email-masked]]
> > Sent: Thursday, April 11, 2002 9:03 AM
> > To: Jonathan Lang
> > Cc: [email-masked]
> > Subject: Re: LMP & neighbor discovery
> >
> >
> > Hello Jonathan,
> >
> >
> > Your answer raises some questions in my mind:
> >
> > > This is what the Link Verification procedure provides. As part of the
> > > BeginVerify message exchange, certain Test parameters (such as
> > > Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism)
> are
> > > exchanged.
> >
> > How do you start this link Verification procedure ? The 'beginVerify'
> message
> > seems to assume that the neighbor is already known.
> Sending the BeginVerify assumes you know where to send control messages.
> This is separate from discovering the data interfaces. This is why using the
> term Neighbor Discovery can often be confusing.  You actually have discovery
> at various levels. G.7714 talks about this in a little more detail.
> 
> >
> > Please note that I'm discussing initial discovery. I don't question the
> use
> > of subsequent test messages verifying the connectivity.
> Noted.
> 
> >
> >
> > > As part of this discovery, NE-3 sends an acknowledgment message carrying
> the
> > > local (near-end) identity of link B.
> >
> > Yes, agreed.
> >
> > In my proposal this acknowledgement is in the link correlation procedure.
> > The DATA_LINK object in the linkSummary message (which is sent upon
> detection
> > of the neighbor) gives the association between "Local_Interface_Id" and
> > "Remote_Interface_Id".
> Link correlation procedure also provides the local/remote mapping for all
> data links. The Ack message provides this mapping (in addition to Test
> message Ack) for each data channel individually.
> 
> >
> >
> > > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> > > verification mechanism in advance.
> >
> > I'm not discussing verification but initial discovery.
> > If we could align on the used procedure for this initial discovery,
> > the neighboring NEs don't have to negotiate the mechanism :-)
> Verification mechanism is used for data link discovery. Without exchanging
> this parameter, you'd have to configure it on both nodes for each port/node
> pair. Furthermore, if run LMP-WDM, you may have to configure yet another
> mechanism for your wdm neighbor if the termination capabilities are
> different.
> 
> >
> >
> > > You could certainly create an LMP control channel through a DCN network.
> In
> > > fact, this is probably the preferred configuration.
> > >
> > > > Is implementation of the LMP's 'control channel management' mandatory
> ?
> > > yes, however you can choose not to run the Hellos by setting the
> > > HelloInterval and HelloDeadInterval equal to zero.
> >
> > I don't understand why the normal network-layer mechanisms (defined in
> e.g.
> > OSPF or I-ISIS) are not sufficient ?
> > Why do we need the LMP specific 'Config' 'ConfigAck' and 'ConfigNack'
> > messages ?
> These are used to configure the LMP Hellos that are used to rapidly detect
> failures along the control channel.
> 
> >
> >
> > Thanks !
> >
> > Michiel
> >
> >
> > Jonathan Lang wrote:
> > >
> > > Michiel,
> > >   Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Michiel van Everdingen [mailto:[email-masked]]
> > > > Sent: Tuesday, April 09, 2002 12:41 AM
> > > > To: [email-masked]
> > > > Subject: LMP & neighbor discovery
> > > >
> > > >
> > > > Hello all,
> > > >
> > > > I found the concept of neighbor discovery mentioned
> > several times in
> > > > previous discussions on this list. However, I did not find a final
> > > > conclusion on how this neighbor discovery is done. Correct ?
> > > >
> > > > Could you please check my understanding below ?
> > > >
> > > > In my mind, reading the incoming 'access point
> > identifier' [ITU-G.707]
> > > > and subsequent LMP 'link property correlation' form a
> > perfect fit. By
> > > > simply encoding the sending node's IP address and local
> > access point
> > > > number in the access point identifier (see e.g.
> > [OIF.2000.159.01]), the
> > > > receiver can discover the data link (linkConnection in
> > ITU  terminology).
> > > > Subsequent 'link property correlation' could then a.o.
> > check on bi-
> > > > directional fibering, matching data link properties and
> > grouping of data
> > > > links into TE links.
> > > >
> > > > Example: the following figure shows 4 network elements of which 2
> > > terminate
> > > > the data link (TTPs, T) and two are transparent to the
> > data link (CTPs,
> > > C).
> > > > E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
> > > transparent
> > > > optical cross connects. The data link in this example is
> > STM-N/OC-N.
> > > >
> > > > +------+      +------+      +------+      +------+
> > > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > > |      |   A  |      |   B  |      |   C  |      |
> > > > |      |      |      |      |      |      |      |
> > > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > > +------+      +------+      +------+      +------+
> > > >
> > > > NE-2 should, when it wants to discover data link B,
> > connect a test-set
> > > that
> > > > sends an access point identifier to identify the sending
> > connection point
> > > C
> > > > in NE-2. This test-signal should be send long enough for
> > NE-3 to detect
> > > and
> > > > read the test-signal (a fixed, agreed upon timer is
> > needed). NE-3 will
> > > > continuously scan all its not discovered input ports for
> > a discovery
> > > signal.
> > > > At some point, it will detect the test-signal on data link B.
> > > This is what the Link Verification procedure provides. As
> > part of the
> > > BeginVerify message exchange, certain Test parameters (such as
> > > Verify_Interval, Verify_Dead_Interval, and
> > Verify_Transport_Mechanism) are
> > > exchanged.
> > >
> > > >
> > > > +------+      +------+      +------+      +------+
> > > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > > |      |   A  |   /  |   B  |  \   |   C  |      |
> > > > |      |      |  T   |      |   T  |      |      |
> > > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > > +------+      +------+      +------+      +------+
> > > >
> > > > When NE-3 has read the access point identifier in the
> > test signal, data
> > > > link B is discovered. Subsequent link property
> > correlation can then be
> > > > invoked.
> > > As part of this discovery, NE-3 sends an acknowledgment
> > message carrying the
> > > local (near-end) identity of link B.
> > >
> > > >
> > > > Discovery of data link A is similar, except that the access point
> > > identifier
> > > > is continuously sent. Discovery of data link C is also
> > similar, except
> > > that
> > > > the access point identifier is continuously monitored. In
> > other words,
> > > there
> > > > is no need for a sending respectively monitoring
> > 'test-set' in NE-1 and
> > > NE-4.
> > > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have
> > agreed on the
> > > verification mechanism in advance.
> > >
> > > >
> > > > Data link type          Access point identifier to be used
> > > > --------------          ----------------------------------
> > > > STM-N, OC-N                            J0
> > > > STS-1/3/.../VC-3/4/...                 J1
> > > > VT-1.5/VC-11/12                        J2
> > > >
> > > >
> > > > Notes:
> > > > - I understand that LMP's link verification procedure is
> > more efficient
> > > for
> > > >   *already discovered* data links. It does not need the continuous
> > > scanning
> > > >   on received access point identifiers in undiscovered
> > CTPs (in the
> > > example:
> > > >   in NE-3).
> > > > - Discovering the address of the sending access point
> > might also go via a
> > > 'name
> > > >   server'. This can, for example, be useful in case the
> > address of this
> > > access
> > > >   point can not be encoded in the limited length of the
> > access point
> > > identifier.
> > > >
> > > > B.t.w., could you please explain why the linkSummary and
> > linkSummaryAck
> > > messages
> > > > have to go over a point-to-point control channel ?
> > > All LMP messages are sent over the LMP control channel; the
> > health of which
> > > is monitored using LMP Hello messages.
> > >
> > > > Is it also possible to
> > > > use the generic DCN network (MCN/SCN, can be IP-based,
> > see ITU-G.7712) ?
> > > > In the latter case, we could simply use the normal UDP
> > service of that
> > > network
> > > > to transport the linkSummary and linkSummaryAck messages ?
> > > You could certainly create an LMP control channel through a
> > DCN network. In
> > > fact, this is probably the preferred configuration.
> > >
> > > > Is implementation of the LMP's 'control channel
> > management' mandatory ?
> > > yes, however you can choose not to run the Hellos by setting the
> > > HelloInterval and HelloDeadInterval equal to zero.
> > >
> > > >
> > > >
> > > > Thanks !
> > > >
> > > > Michiel
> > > >
> > > > --
> > > >
> > +------------------------------------------------------------------+
> > > > | Michiel van Everdingen
> >          |
> > > > | Systems Engineer
> >          |
> > > > | Lucent Technologies - Optical Networking Group
> >          |
> > > > | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883
> >          |
> > > > | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976
> >          |
> > > > | Huizen, The Netherlands
> > mailto:[email-masked]  |
> > > >
> > +------------------------------------------------------------------+
> > > >
> >

Delivery-date: Mon, 15 Apr 2002 06:41:28 -0700
Date: Mon, 15 Apr 2002 09:41:18 -0400
From: Zhi-Wei Lin <[email-masked]>
To: Suresh Katukam <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Fwd: Re: SE style in optical neyworks

Hi Suresh,

Sorry. Wasn't picking on terminology, anyway, some more comments below...

Suresh Katukam wrote:

>
>>
>> Tom and all,
>>
>> I think everyone seemed to pick on my terminology or misinterpreted
>> what I said.
>>
>> Here is an example:
>>
>>          1+1                        1+1
>> A ----------------B --------- C ------------D
>>                      \          /
>>                        \       /
>>                           E
>>
>>
>> A - B & C - D 1+1 line protected
>> B - C, C - E, B - E are all unprotected links.
>
So this network you drew assumes a single point of interconnect at B and 
C...that's fine

>>
>> Say, one wants to create a protected LSP from A to D.
>> then, you would create one primary LSP from A to D via
>> A - B - C - D, and then you would create another LSP
>> from A to D using SE style ( to indicate that this is an
>> alternate path for same Tunnel ) via A - B - E - C - D.
>> This way B - C is protected by B - E - C. 
>
By creating a new LSP A-B-E-C-D, this circuit is completely separate 
from the original A-B-C-D circuit. There is no sharing at all. It is 
just incidental that they carry the same traffic (i.e., you just happen 
to have set up the A-B-E-C-D to carry the same traffic as in A-B-C-D). 
Again this is not merging (as represented by SE), unless you are 
re-defining what SE means...

>>
>>
>> B - C - E is not configured as a UPSR. All unprotected links.
>> Virtual UPSR can be created such a way that B has a bridge
>> and C has a selector. Ofcourse, for bidirectional LSP, you need
>> the same thing in the opposite direction too.
>
Yes, just as the two LSPs making up the 1+1 from A-B are both 
unprotected LSPs, but taken together provide the 1+1 service. As such, 
if B-E-C is carrying the same traffic as B-C *all the time*, then it's 
still 1+1, but more specifically, it is a 1+1 SNC (sub-network 
connection). 1+1 doesn't necessary only apply to 1+1 path (when you say 
path, I think you mean trail? -- G.805 terminology).

However, if B-E-C is not carrying the same traffic, but may be used to 
support *extra traffic*, then this is a 1:1 type protection.

And if B-E-C LSP is actually supporting multiple LSPs going over B-C, 
then it's 1:N protection. However, note that even in this case it is 
still NOT SE, since the B-E-C LSP at any given time is only ever 
carrying one single traffic.

Hope this clarifies.

Zhi

>>
>> Now, what do you call this kind of protection? Protected LSP?
>> But not 1+1 path protected  - since it is not end-to-end path
>> protected.
>>
>> To clarify again, this is when you would use SE style.
>>
>> Thanks
>> Suresh
>>
>>
>> At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote:
>>
>>
>>>> This can be used to set up Protected circuits which may contain
>>>> 1+1 lines and 1+1 path protected segments. So on 1+1 line
>>>> protected segments, you Share the bandwidth among primary
>>>> and alternate paths.
>>>
>>>
>>>         You do not share the bandwidth across 1+1 circuits. You
>>> double-book the bandwidth because the same packets are
>>> sent twice: once over each LSP.  You only share bandwidth
>>> with 1:N.
>>>
>>>         --Tom
>>>
>>>
>>>> Setting up protected circuits is not considered
>>>> in detail so far. Hopefully, P&R design team will consider this..
>>>>
>>>> Thanks,
>>>> Suresh
>>>>
>>>> At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> How does SE style of RSVP signalling fits in the optical nature of 
>>>>> network
>>>>> i.e. in wavelength, TDM switching etc.
>>>>>
>>>>>  In other words, How two lsp can share resource in optical networks??
>>>>>
>>>>> Regards,
>>>>> Khuzema.
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>> Mathematics is the supreme nostalgia of our time.
>>
>
>

Delivery-date: Mon, 15 Apr 2002 06:37:39 -0700
From: "Ravi Ravindran"<[email-masked]>
To: "'Manoj Sontakke'" <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: [email-masked]
Subject: RE: Question on LMP.
Date: Mon, 15 Apr 2002 09:36:32 -0400

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

------_=_NextPart_001_01C1E482.8E453A2C
Content-Type: text/plain;
	charset="iso-8859-1"

hi,
This is reiterating manoj's question, do we need some kind of association
between the routing protocol and the LMP which is supposed to provide a
reliable control channel for the control plane protocols. If we do not have
this, during a control channel failure (assuming a case where we have
multiple active control channels and physical interfaces between two nodes),
the control plane  protocols would have to rely on  the routing protocol to
detect the failure and reroute the packets, making the control channel
management of LMP less efficient.

Ravi S. Ravindran
Nortel Networks, Ottawa

-----Original Message-----
From: Manoj Sontakke [mailto:[email-masked]]
Sent: Monday, April 15, 2002 5:53 AM
To: Jonathan Lang
Cc: [email-masked]
Subject: Re: Question on LMP.

Hi Jonathan,

Thanks for the quick response. Please see my comments inline.

Manoj

Jonathan Lang wrote:
> 
> Manoj,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Manoj Sontakke [mailto:[email-masked]]
> > Sent: Thursday, April 11, 2002 7:02 AM
> > To: [email-masked]
> > Subject: Question on LMP.
> >
> >
> > Hi,
> >
> > I have two questions on LMP.
> >
> > --------------------------------------------------------------
> > -----------------------------
> > Q1.  Control Channel Question
> >
> > Assuming a configuration as shown.
> >
> >
> >                 -----------------               -----------------
> >                 |               |               |               |
> >                 |            if1|---------------|if1            |
> >                 |            if2|---------------|if2            |
> >                 |     OXC 1     |               |     OXC 2     |
> >                 |             d1|---------------|d1             |
> >                 |             d2|---------------|d2             |
> >                 -----------------
> > -----------------
> >
> >
> > I have two OXCs connected by four links. Consider d1, d2 are configured
> > to carry data and if1 and if2 are configured to carry control data ( LMP
> > messages and RSVP and OSPF messages).
> >
> > The LMP document defines control channels with an unique identifier (
> > control channel identifier ) between the negibouring nodes.
> > So also, the LMP messages are IP encapsulated.
> >
> > Now, I have a couple of questions
> >
> > 1. Is there any association between the LMP control channels to the
> > physical interfaces( if1, if2). Because all the IP packets are routed on
> > the physical interfaces according to the routing table. The control
> > channel messages like  ( config and configAck etc.. ) can go on the any
> > physical interface which is decided by the routing table.
> >
> > In such case, are the control channels a pure logical concept or do they
> > have any physical interface significance & correlation [ mapping between
> > control channles ( ccid ) and interfaces ( if1 and if2 )] ?

> Control channels are associated with interfaces.

Manoj-> The draft does not say so explicitly. Besides, all the LMP
messages are IP encoded. So the routing table decides the outgoing
interface for sending the LMP messages (any packet for that matter)
depending upon the destination IP address.

So is it possible to make such an association between the LMP control
channel and a physical interface (though it is desirable)? Are we
deviating from the standard IP implementation ?

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

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

<P><FONT SIZE=3D2>hi,</FONT>
<BR><FONT SIZE=3D2>This is reiterating manoj's question, do we need =
some kind of association between the routing protocol and the LMP which =
is supposed to provide a reliable control channel for the control plane =
protocols. If we do not have this, during a control channel failure =
(assuming a case where we have multiple active control channels and =
physical interfaces between two nodes), the control plane&nbsp; =
protocols would have to rely on&nbsp; the routing protocol to detect =
the failure and reroute the packets, making the control channel =
management of LMP less efficient.</FONT></P>

<P><FONT SIZE=3D2>Ravi S. Ravindran</FONT>
<BR><FONT SIZE=3D2>Nortel Networks, Ottawa</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Manoj Sontakke [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 15, 2002 5:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Jonathan Lang</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Question on LMP.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the quick response. Please see my comments =
inline.</FONT>
</P>

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

<P><FONT SIZE=3D2>Jonathan Lang wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Manoj,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Please see inline.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Manoj Sontakke [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, April 11, 2002 7:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Question on LMP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have two questions on LMP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Q1.&nbsp; Control Channel Question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Assuming a configuration as shown.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-----------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----------------</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
if1|---------------|if1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
if2|---------------|if2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; OXC =
1&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; OXC 2&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
d1|---------------|d1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
d2|---------------|d2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; -----------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have two OXCs connected by four links. =
Consider d1, d2 are configured</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to carry data and if1 and if2 are =
configured to carry control data ( LMP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; messages and RSVP and OSPF =
messages).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The LMP document defines control channels =
with an unique identifier (</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; control channel identifier ) between the =
negibouring nodes.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So also, the LMP messages are IP =
encapsulated.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Now, I have a couple of questions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. Is there any association between the =
LMP control channels to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; physical interfaces( if1, if2). Because =
all the IP packets are routed on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the physical interfaces according to the =
routing table. The control</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; channel messages like&nbsp; ( config and =
configAck etc.. ) can go on the any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; physical interface which is decided by the =
routing table.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In such case, are the control channels a =
pure logical concept or do they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have any physical interface significance =
&amp; correlation [ mapping between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; control channles ( ccid ) and interfaces ( =
if1 and if2 )] ?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Control channels are associated with =
interfaces.</FONT>
</P>

<P><FONT SIZE=3D2>Manoj-&gt; The draft does not say so explicitly. =
Besides, all the LMP</FONT>
<BR><FONT SIZE=3D2>messages are IP encoded. So the routing table =
decides the outgoing</FONT>
<BR><FONT SIZE=3D2>interface for sending the LMP messages (any packet =
for that matter)</FONT>
<BR><FONT SIZE=3D2>depending upon the destination IP address.</FONT>
</P>

<P><FONT SIZE=3D2>So is it possible to make such an association between =
the LMP control</FONT>
<BR><FONT SIZE=3D2>channel and a physical interface (though it is =
desirable)? Are we</FONT>
<BR><FONT SIZE=3D2>deviating from the standard IP implementation =
?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E482.8E453A2C--

Delivery-date: Mon, 15 Apr 2002 05:21:34 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: <[email-masked]>
Subject: Doubts regarding SONET/SDH label
Date: Mon, 15 Apr 2002 18:04:30 +1000

This is a multi-part message in MIME format.

------=_NextPartTM-000-db77ff03-505c-11d6-af80-0080c8048dde
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: quoted-printable

hai,
   =20
        Could someone explain me the correlation between the position of =
a particular signal in SONET/SDH
        multiplexing structure which is indicated by the SUKLM numbering =
schema (SDH/SONET label) and the    =20
        timeslot ???
       =20
        How do a SONET/SDH LSR maintain the label resource ?? Does the =
SONET/SDH multiplexing structure=20
        signifies the label resource with root as the signal level which =
the LSR switches ??

        Does label set or the suggested label concept in GMPLS holds =
good for SONET/SDH LSPs also ??
        If yes, can someone frame such a requirement where it is =
applicable ??

        Please correct me if i am going wrong somewhere ?? Also do =
suggest some pointers where i can get
        information about controlling and provisioning SONET/SDH LSPs

thanks in advance=20
regards
venkat

       =20
+ACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAq=
ACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqA=
CoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACo-
Experience is a wonderful thing. It enables you to recognize a
mistake when you make it again.

------=_NextPartTM-000-db77ff03-505c-11d6-af80-0080c8048dde
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-db77ff03-505c-11d6-af80-0080c8048dde--

Delivery-date: Mon, 15 Apr 2002 02:53:09 -0700
Date: Mon, 15 Apr 2002 15:22:31 +0530
From: Manoj Sontakke <[email-masked]>
Organization: Sasken Communication Technologies Ltd.
To: Jonathan Lang <[email-masked]>
CC: [email-masked]
Subject: Re: Question on LMP.

Hi Jonathan,

Thanks for the quick response. Please see my comments inline.

Manoj

Jonathan Lang wrote:
> 
> Manoj,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Manoj Sontakke [mailto:[email-masked]]
> > Sent: Thursday, April 11, 2002 7:02 AM
> > To: [email-masked]
> > Subject: Question on LMP.
> >
> >
> > Hi,
> >
> > I have two questions on LMP.
> >
> > --------------------------------------------------------------
> > -----------------------------
> > Q1.  Control Channel Question
> >
> > Assuming a configuration as shown.
> >
> >
> >                 -----------------               -----------------
> >                 |               |               |               |
> >                 |            if1|---------------|if1            |
> >                 |            if2|---------------|if2            |
> >                 |     OXC 1     |               |     OXC 2     |
> >                 |             d1|---------------|d1             |
> >                 |             d2|---------------|d2             |
> >                 -----------------
> > -----------------
> >
> >
> > I have two OXCs connected by four links. Consider d1, d2 are configured
> > to carry data and if1 and if2 are configured to carry control data ( LMP
> > messages and RSVP and OSPF messages).
> >
> > The LMP document defines control channels with an unique identifier (
> > control channel identifier ) between the negibouring nodes.
> > So also, the LMP messages are IP encapsulated.
> >
> > Now, I have a couple of questions
> >
> > 1. Is there any association between the LMP control channels to the
> > physical interfaces( if1, if2). Because all the IP packets are routed on
> > the physical interfaces according to the routing table. The control
> > channel messages like  ( config and configAck etc.. ) can go on the any
> > physical interface which is decided by the routing table.
> >
> > In such case, are the control channels a pure logical concept or do they
> > have any physical interface significance & correlation [ mapping between
> > control channles ( ccid ) and interfaces ( if1 and if2 )] ?

> Control channels are associated with interfaces.

Manoj-> The draft does not say so explicitly. Besides, all the LMP
messages are IP encoded. So the routing table decides the outgoing
interface for sending the LMP messages (any packet for that matter)
depending upon the destination IP address.

So is it possible to make such an association between the LMP control
channel and a physical interface (though it is desirable)? Are we
deviating from the standard IP implementation ?

> 
> >
> > --------------------------------------------------------------
> > -----------------------------
> > Q2. MessageId question
> >
> > In the LMP document, the config Message & config ack messages are
> > defined as
> >
> >         <configMessage> ::= <common header> <LOCAL_CCID> <MESSGAE_ID>
> > <LOCAL_NODE_ID>                           <CONFIG>
> >
> >         <configAckMessage> ::= <common header> <LOCAL_CCID>
> > <LOCAL_NODE_ID> <REMOTE_CCID>
> > <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
> >
> > Assume the following sequence.
> >
> >                                    ConfigMessage
> >                 OXC1    ---------------------------------->     OXC2
> >
> >                                    ConfigMessage
> >                 OXC1    ---------------------------------->     OXC2
> >
> >                                    ConfigMessage
> >                 OXC1    ---------------------------------->     OXC2
> >
> >                                   ConfigAckMessage
> >                 OXC1    <----------------------------------     OXC2
> >
> > On the OXC1 when the configAck Message is received then the OXC1 can
> > come to know that the config Message has been received by the OXC2 and
> > it can identify that it received the ack for a LOCAL_CCID.
> > Any configAck
> > recevied will result in bringing that control channel UP.
> >
> > So how does the <MESSAGE_ID> and <MESSAGE_ID_ACK> helps improve the
> > message realiability ?
> Message_ID helps identify new Config/ConfigAck messages for the same control
> channel.

Manoj-> Isn't the CCID enough ?

> 
> >
> > --------------------------------------------------------------
> > ---------------------------
> >
> > Any comments in this regard will be appreciated.
> >
> > Thanks,
> > Manoj
> >

Delivery-date: Mon, 15 Apr 2002 01:33:40 -0700
Cc: John Ellson <[email-masked]>, CCAMP WG <[email-masked]>
Date: Mon, 15 Apr 2002 10:31:59 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
Original-CC: John Ellson <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: SE style in optical neyworks

This is a multi-part message in MIME format.
--------------F7F455C8377629472E8BC2AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sudheer,

In a layered network approach, a connection request for e.g. a VC-4 connection
will use the VC-4 layer network with its established VC-4 links (G.805
terminology) and VC-4 fabrics.

Some VC-4 links may have higher availability than others. This may be due to
(but is not at all limited to) supporting such VC-4 link by a protected server
layer trail (e.g. MS/Line protected, MS SPring/BLSR protected). The availability
of the link could be a parameter in the route selection process.

If the VC-4 connection is to be protected (i.e. requirement is to go via two
diverse routes), 1+1 VC-4 SNC protection is to be applied between e.g.
ingress/egress of the network independent of the individual availability figures
(and possible protection underneath) of the VC-4 links.

If there is just a requirement to meet a particular availability value for the
requested connection, then VC-4 links and VC-4 fabrics should be selected such
that the total availability figure doesn't exceed the requested value. Now it
may not be required to have complete diverse routed working and protection
connections; i.e. intermediate nodes may be common, which allows to use server
layer protection for some parts of the VC-4 connection.

Instead of using 1+1 VC-4 SNC protection, you can use VC-4 restoration. VC-4
restoration may require an alternative VC-4 connection to be reserved. In this
case once again the VC-4 alternative connection should be computed using the
VC-4 links and VC-4 fabrics. How these links are supported doesn't matter, as
long as they are disjoint from the VC-4 links used for the normal connection.
You may oversubscribe VC-4 links with alternate/backup VC-4 connections, as long
as a single fault in the network will not cause an overflow of the VC-4 link
while too many reserved VC-4 connections must be turned into actual connections.

Regards,

Maarten

Sudheer Dharanikota wrote:
> 
> Hi John:
> 
> John Ellson wrote:
> 
> > Sudheer Dharanikota wrote:
> > > Hi Gentelmen:
> > >
> > > I changed this list to camp, as it is more appropriate
> > > for this discussion.
> > >
> > > I would like to understand the following..
> > >
> > > Assumptions:
> > >
> > > - Segments of network are inherantly made protected.
> > >   For example, as suresh said, span/UPSR/BLSR etc protected.
> > >
> > > - PAth request contains requirements to set up a path
> > >   of *certain* protection guarantees without knowing the
> > >  topoogy and its capability
> > >
> > > Now ...
> > >
> > > If i want to set up an end-to-end *backup* path, it is the network
> > > (intermediate nodes) which has to decide if a *backup*
> > > link or a segment need to be overloaded. Don't you think in this
> > > case SE may make sense.
> >
> > I the circuit world, if you obtain a second circuit for use as backup
> > you don't need to tell the network about it.  Its just going to
> > give you a dedicated circuit, with whatever reliability guarantees
> > you have in your service contract, and with an expectation of being
> > paid for the circuit wether or not the end-system chooses to
> > put bits on it.
> 
> Not necessarily. Establishment of a secondary circuit could be a
> policy decision based on the customer SLA.
> 
> Shared mesh restoration is one case where you can see the need
> for SE based reservation for backup path.
> 
> BLSR etc where both the primary and secondary take the same
> span protected ring can be another case.
> 
> >
> >
> > In the packet world its different.  I suppose you could obtain
> > a second circuit with a service contract that allowed the network
> > to stat-mux the bandwidth with other traffic.   I still don't
> > know why you would tell the network what you wanted it for.
> 
> Agreed on this explanation.
> 
> >
> >
> > BTW. If you used such a circuit for protection it would have to be
> > 1:1, not 1+1, because the sharing on the standby channel clearly
> > means that you can't duplicate the working channel data.
> 
> Agreed. May be UPSR is a bad example.
> 
> - sudheer
> 
> >
> >
> > John
> >
> > > Thanks for your input.
> > >
> > > sudheer
> > >
> > > John Ellson wrote:
> > >
> > >
> > >>Suresh Katukam wrote:
> > >>
> > >>>Zhi,
> > >>>
> > >>>You are correct about 1+1 path protected...
> > >>>
> > >>>But if you have a LSP that is protected by some 1+1 links and some
> > >>>UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes
> > >>>(I am not sure what you call this LSP - 1+1 protected, just Protected
> > >>>circuit).
> > >>>In this case, SE style can be used..
> > >>
> > >>If you're talking about nodes other than the nodes that are
> > >>at the the ends of the protection span, then I suggest that you just refer
> > >>to it as a "reliable segment".  It shouldn't matter
> > >>to the end-systems how that segment reliability is achieved.
> > >>
> > >>Protection is only interesting to nodes that have to take part in it,
> > >>otherwise its just a segment of a connection with a greater or
> > >>lesser propensity to failure.
> > >>
> > >>John Ellson
> > >
--------------F7F455C8377629472E8BC2AE
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------F7F455C8377629472E8BC2AE--

Delivery-date: Sun, 14 Apr 2002 23:23:54 -0700
Date: Mon, 15 Apr 2002 02:19:05 -0400
To: Kireeti Kompella <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt 
Cc: Yakov Rekhter <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

--=====================_45743045==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

At 01:39 AM 4/12/2002 -0700, Kireeti Kompella wrote:

>On Fri, 12 Apr 2002, Zafar Ali wrote:
>
> > A way of exchanging the Link Identifiers for Unnumbered TE links (with
> > interface switching cap of PSC-1 to PSC-4) is missing from the draft. In
> > ISIS, the unnumbered TE link identifiers can be exchanged using Link
> > Identifies in the Extended Local Circuit ID field of the "Point-to-Point
> > Three-Way Adjacency" IS-IS Option type [draft-ietf-isis-3way-05.txt].=
 Can
> > you please define an equivalent mechanism for the OSPF in the draft?
>
>Excellent point.  We have a way of doing this (namely, a link-local
>opaque LSA, similar to grace-LSAs), but we weren't sure whether to put
>it in this draft or a companion draft.

Hi Kireeti,

Thanks for your reply. The use of Opaque LSAs with flooding scope of=20
=93link-local=94 makes much sense for exchanging the interface identifiers=
 for=20
the unnumbered interfaces.

As far as encoding details for this LSA is concerned, would you like to get=
=20
it reviewed as part of this review processes, or would you like to get it=20
reviewed as part of the review for the upcoming version of the document. In=
=20
either case, I think it will be quite useful if you can email the expected=
=20
format.

Thanks

Regards=85. Zafar

>To keep the parallelism with the ISIS draft, we should probably just
>add this specification to this draft ...
>
>Kireeti.

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

<html>
<font size=3D3>At 01:39 AM 4/12/2002 -0700, Kireeti Kompella wrote:<br>
<br>
<blockquote type=3Dcite cite>On Fri, 12 Apr 2002, Zafar Ali wrote:<br>
<br>
&gt; A way of exchanging the Link Identifiers for Unnumbered TE links
(with<br>
&gt; interface switching cap of PSC-1 to PSC-4) is missing from the
draft. In<br>
&gt; ISIS, the unnumbered TE link identifiers can be exchanged using
Link<br>
&gt; Identifies in the Extended Local Circuit ID field of the
&quot;Point-to-Point<br>
&gt; Three-Way Adjacency&quot; IS-IS Option type
[draft-ietf-isis-3way-05.txt]. Can<br>
&gt; you please define an equivalent mechanism for the OSPF in the
draft?<br>
<br>
Excellent point.&nbsp; We have a way of doing this (namely, a
link-local<br>
opaque LSA, similar to grace-LSAs), but we weren't sure whether to
put<br>
it in this draft or a companion draft.<br>
</font></blockquote><br>
Hi Kireeti, <br>
<br>
<font face=3D"Arial, Helvetica" size=3D3>Thanks for your reply. The use of
Opaque LSAs with flooding scope of
=93</font>link-local<font face=3D"Arial, Helvetica" size=3D3>=94 makes much =
sense
for exchanging the interface identifiers for the unnumbered interfaces.
<br>
<br>
As far as encoding details for this LSA is concerned, would you like to
get it reviewed as part of this review processes, or would you like to
get it reviewed as part of the review for the upcoming version of the
document. In either case, I think it will be quite useful if you can
email the expected format. <br>
<br>
Thanks<br>
<br>
Regards=85. Zafar <br>
<br>
</font><blockquote type=3Dcite cite>To keep the parallelism with the ISIS
draft, we should probably just<br>
add this specification to this draft ...<br>
<br>
Kireeti.</blockquote></html>

--=====================_45743045==_.ALT--

Delivery-date: Fri, 12 Apr 2002 20:13:08 -0700
Date: Fri, 12 Apr 2002 20:09:42 -0700
From: Sudheer Dharanikota <[email-masked]>
To: John Ellson <[email-masked]>
CC: Suresh Katukam <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Khuzema Pithewan <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: SE style in optical neyworks

Hi John:

John Ellson wrote:

> Sudheer Dharanikota wrote:
> > Hi Gentelmen:
> >
> > I changed this list to camp, as it is more appropriate
> > for this discussion.
> >
> > I would like to understand the following..
> >
> > Assumptions:
> >
> > - Segments of network are inherantly made protected.
> >   For example, as suresh said, span/UPSR/BLSR etc protected.
> >
> > - PAth request contains requirements to set up a path
> >   of *certain* protection guarantees without knowing the
> >  topoogy and its capability
> >
> > Now ...
> >
> > If i want to set up an end-to-end *backup* path, it is the network
> > (intermediate nodes) which has to decide if a *backup*
> > link or a segment need to be overloaded. Don't you think in this
> > case SE may make sense.
>
> I the circuit world, if you obtain a second circuit for use as backup
> you don't need to tell the network about it.  Its just going to
> give you a dedicated circuit, with whatever reliability guarantees
> you have in your service contract, and with an expectation of being
> paid for the circuit wether or not the end-system chooses to
> put bits on it.

Not necessarily. Establishment of a secondary circuit could be a
policy decision based on the customer SLA.

Shared mesh restoration is one case where you can see the need
for SE based reservation for backup path.

BLSR etc where both the primary and secondary take the same
span protected ring can be another case.

>
>
> In the packet world its different.  I suppose you could obtain
> a second circuit with a service contract that allowed the network
> to stat-mux the bandwidth with other traffic.   I still don't
> know why you would tell the network what you wanted it for.

Agreed on this explanation.

>
>
> BTW. If you used such a circuit for protection it would have to be
> 1:1, not 1+1, because the sharing on the standby channel clearly
> means that you can't duplicate the working channel data.

Agreed. May be UPSR is a bad example.

- sudheer

>
>
> John
>
> > Thanks for your input.
> >
> > sudheer
> >
> > John Ellson wrote:
> >
> >
> >>Suresh Katukam wrote:
> >>
> >>>Zhi,
> >>>
> >>>You are correct about 1+1 path protected...
> >>>
> >>>But if you have a LSP that is protected by some 1+1 links and some
> >>>UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes
> >>>(I am not sure what you call this LSP - 1+1 protected, just Protected
> >>>circuit).
> >>>In this case, SE style can be used..
> >>
> >>If you're talking about nodes other than the nodes that are
> >>at the the ends of the protection span, then I suggest that you just refer
> >>to it as a "reliable segment".  It shouldn't matter
> >>to the end-systems how that segment reliability is achieved.
> >>
> >>Protection is only interesting to nodes that have to take part in it,
> >>otherwise its just a segment of a connection with a greater or
> >>lesser propensity to failure.
> >>
> >>John Ellson
> >

Delivery-date: Fri, 12 Apr 2002 16:36:29 -0700
Date: Fri, 12 Apr 2002 19:30:54 -0400
From: John Ellson <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Suresh Katukam <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Khuzema Pithewan <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: SE style in optical neyworks

[ post by non-subscriber ]

Sudheer Dharanikota wrote:
> Hi Gentelmen:
> 
> I changed this list to camp, as it is more appropriate
> for this discussion.
> 
> I would like to understand the following..
> 
> Assumptions:
> 
> - Segments of network are inherantly made protected.
>   For example, as suresh said, span/UPSR/BLSR etc protected.
> 
> - PAth request contains requirements to set up a path
>   of *certain* protection guarantees without knowing the
>  topoogy and its capability
> 
> Now ...
> 
> If i want to set up an end-to-end *backup* path, it is the network
> (intermediate nodes) which has to decide if a *backup*
> link or a segment need to be overloaded. Don't you think in this
> case SE may make sense.

I the circuit world, if you obtain a second circuit for use as backup
you don't need to tell the network about it.  Its just going to
give you a dedicated circuit, with whatever reliability guarantees
you have in your service contract, and with an expectation of being
paid for the circuit wether or not the end-system chooses to
put bits on it.

In the packet world its different.  I suppose you could obtain
a second circuit with a service contract that allowed the network
to stat-mux the bandwidth with other traffic.   I still don't
know why you would tell the network what you wanted it for.

BTW. If you used such a circuit for protection it would have to be
1:1, not 1+1, because the sharing on the standby channel clearly
means that you can't duplicate the working channel data.

John

> Thanks for your input.
> 
> sudheer
> 
> John Ellson wrote:
> 
> 
>>Suresh Katukam wrote:
>>
>>>Zhi,
>>>
>>>You are correct about 1+1 path protected...
>>>
>>>But if you have a LSP that is protected by some 1+1 links and some
>>>UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes
>>>(I am not sure what you call this LSP - 1+1 protected, just Protected
>>>circuit).
>>>In this case, SE style can be used..
>>
>>If you're talking about nodes other than the nodes that are
>>at the the ends of the protection span, then I suggest that you just refer
>>to it as a "reliable segment".  It shouldn't matter
>>to the end-systems how that segment reliability is achieved.
>>
>>Protection is only interesting to nodes that have to take part in it,
>>otherwise its just a segment of a connection with a greater or
>>lesser propensity to failure.
>>
>>John Ellson
> 

Delivery-date: Fri, 12 Apr 2002 16:22:48 -0700
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang' <[email-masked]>
Cc: "ccamp (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-lmp-03.txt, CHANNEL_STATUS
Date: Fri, 12 Apr 2002 16:15:24 -0700

Fugui,
  You are correct. These are bad edits.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 4:21 PM
> To: Jonathan Lang
> Cc: ccamp (E-mail)
> Subject: draft-ietf-ccamp-lmp-03.txt, CHANNEL_STATUS
> 
> 
> Hi, Jonathan,
> 
> In page 63: 
> Active bit: 1 bit 
>     
> This indicates that the Channel is allocated to user traffic and the 
> data link should be actively monitored. 
>     
> Direction bit: 1 bit 
>     
> This indicates the direction (transmit/receive) of the data channel 
> referred to in the Channel_Status object.  If set, this indicates 
> the data channel is in the transmit direction. 
> Channel_Status: 31 bits 
> 
> However, only the Unnumbered case has both A bit and D bit. 
> The IPV4 and IPV6 case only have A bit. Is it simply an edit error? Also,
shouldn't the 
> Channel_Status be 30 bits instead of 31 bits?
> 
> Thanks,
> Fugui
> 

Delivery-date: Fri, 12 Apr 2002 16:22:09 -0700
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "ccamp (E-mail)" <[email-masked]>
Subject: draft-ietf-ccamp-lmp-03.txt, CHANNEL_STATUS
Date: Fri, 12 Apr 2002 19:20:38 -0400

Hi, Jonathan,

In page 63: 
Active bit: 1 bit 
    
This indicates that the Channel is allocated to user traffic and the 
data link should be actively monitored. 
    
Direction bit: 1 bit 
    
This indicates the direction (transmit/receive) of the data channel 
referred to in the Channel_Status object.  If set, this indicates 
the data channel is in the transmit direction. 
Channel_Status: 31 bits 

However, only the Unnumbered case has both A bit and D bit. The IPV4 and
IPV6 case only
have A bit. Is it simply an edit error? Also, shouldn't the Channel_Status
be 30 bits instead of 31 bits?

Thanks,
Fugui

Delivery-date: Fri, 12 Apr 2002 16:22:06 -0700
From: Jonathan Lang <[email-masked]>
To: 'Manoj Sontakke' <[email-masked]>, [email-masked]
Subject: RE: Question on LMP.
Date: Fri, 12 Apr 2002 16:13:10 -0700

Manoj,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Manoj Sontakke [mailto:[email-masked]]
> Sent: Thursday, April 11, 2002 7:02 AM
> To: [email-masked]
> Subject: Question on LMP.
> 
> 
> Hi,
> 
> I have two questions on LMP.
> 
> --------------------------------------------------------------
> -----------------------------
> Q1.  Control Channel Question
> 
> Assuming a configuration as shown.
> 
> 
>                 -----------------               -----------------
>                 |               |               |               |
>                 |            if1|---------------|if1            |
>                 |            if2|---------------|if2            |
>                 |     OXC 1     |               |     OXC 2     |
>                 |             d1|---------------|d1             |
>                 |             d2|---------------|d2             |
>                 -----------------               
> -----------------       
>                 
>                 
> I have two OXCs connected by four links. Consider d1, d2 are configured
> to carry data and if1 and if2 are configured to carry control data ( LMP 
> messages and RSVP and OSPF messages).
> 
> The LMP document defines control channels with an unique identifier (
> control channel identifier ) between the negibouring nodes. 
> So also, the LMP messages are IP encapsulated.
> 
> Now, I have a couple of questions
> 
> 1. Is there any association between the LMP control channels to the
> physical interfaces( if1, if2). Because all the IP packets are routed on
> the physical interfaces according to the routing table. The control
> channel messages like  ( config and configAck etc.. ) can go on the any
> physical interface which is decided by the routing table.
> 
> In such case, are the control channels a pure logical concept or do they
> have any physical interface significance & correlation [ mapping between
> control channles ( ccid ) and interfaces ( if1 and if2 )] ?
Control channels are associated with interfaces.

> 
> --------------------------------------------------------------
> -----------------------------
> Q2. MessageId question
> 
> In the LMP document, the config Message & config ack messages are
> defined as 
> 
>         <configMessage> ::= <common header> <LOCAL_CCID> <MESSGAE_ID>
> <LOCAL_NODE_ID> 			    <CONFIG>
>         
>         <configAckMessage> ::= <common header> <LOCAL_CCID>
> <LOCAL_NODE_ID> <REMOTE_CCID> 				
> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
> 
> Assume the following sequence.
> 
>                                    ConfigMessage        
>                 OXC1    ---------------------------------->     OXC2
> 
>                                    ConfigMessage        
>                 OXC1    ---------------------------------->     OXC2
> 
>                                    ConfigMessage        
>                 OXC1    ---------------------------------->     OXC2
> 
>                                   ConfigAckMessage      
>                 OXC1    <----------------------------------     OXC2
> 
> On the OXC1 when the configAck Message is received then the OXC1 can
> come to know that the config Message has been received by the OXC2 and
> it can identify that it received the ack for a LOCAL_CCID. 
> Any configAck
> recevied will result in bringing that control channel UP.
> 
> So how does the <MESSAGE_ID> and <MESSAGE_ID_ACK> helps improve the
> message realiability ?
Message_ID helps identify new Config/ConfigAck messages for the same control
channel.

> 
> --------------------------------------------------------------
> ---------------------------
> 
> Any comments in this regard will be appreciated.
> 
> Thanks,
> Manoj
> 

Delivery-date: Fri, 12 Apr 2002 15:06:37 -0700
Date: Fri, 12 Apr 2002 15:05:36 -0700
To: Sudheer Dharanikota <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: Re: SE style in optical neyworks
Cc: John Ellson <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Khuzema Pithewan <[email-masked]>, CCAMP WG <[email-masked]>

Sudheer,

You are correct.  I just sent a mail before reading your mail
and it should clarify in detail to others..

-- Suresh

At 02:11 PM 4/12/2002 -0700, Sudheer Dharanikota wrote:

>Hi Gentelmen:
>
>I changed this list to camp, as it is more appropriate
>for this discussion.
>
>I would like to understand the following..
>
>Assumptions:
>
>- Segments of network are inherantly made protected.
>   For example, as suresh said, span/UPSR/BLSR etc protected.
>
>- PAth request contains requirements to set up a path
>   of *certain* protection guarantees without knowing the
>  topoogy and its capability
>
>Now ...
>
>If i want to set up an end-to-end *backup* path, it is the network
>(intermediate nodes) which has to decide if a *backup*
>link or a segment need to be overloaded. Don't you think in this
>case SE may make sense.
>
>Thanks for your input.
>
>sudheer
>
>John Ellson wrote:
>
> > Suresh Katukam wrote:
> > >
> > > Zhi,
> > >
> > > You are correct about 1+1 path protected...
> > >
> > > But if you have a LSP that is protected by some 1+1 links and some
> > > UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes
> > > (I am not sure what you call this LSP - 1+1 protected, just Protected
> > > circuit).
> > > In this case, SE style can be used..
> >
> > If you're talking about nodes other than the nodes that are
> > at the the ends of the protection span, then I suggest that you just refer
> > to it as a "reliable segment".  It shouldn't matter
> > to the end-systems how that segment reliability is achieved.
> >
> > Protection is only interesting to nodes that have to take part in it,
> > otherwise its just a segment of a connection with a greater or
> > lesser propensity to failure.
> >
> > John Ellson

Delivery-date: Fri, 12 Apr 2002 15:04:27 -0700
Date: Fri, 12 Apr 2002 15:03:46 -0700
To: [email-masked], [email-masked]
From: Suresh Katukam <[email-masked]>
Subject: Fwd: Re: SE style in optical neyworks

>
>Tom and all,
>
>I think everyone seemed to pick on my terminology or misinterpreted
>what I said.
>
>Here is an example:
>
>          1+1                        1+1
>A ----------------B --------- C ------------D
>                      \          /
>                        \       /
>                           E
>
>
>A - B & C - D 1+1 line protected
>B - C, C - E, B - E are all unprotected links.
>
>Say, one wants to create a protected LSP from A to D.
>then, you would create one primary LSP from A to D via
>A - B - C - D, and then you would create another LSP
>from A to D using SE style ( to indicate that this is an
>alternate path for same Tunnel ) via A - B - E - C - D.
>This way B - C is protected by B - E - C.
>
>B - C - E is not configured as a UPSR. All unprotected links.
>Virtual UPSR can be created such a way that B has a bridge
>and C has a selector. Ofcourse, for bidirectional LSP, you need
>the same thing in the opposite direction too.
>
>Now, what do you call this kind of protection? Protected LSP?
>But not 1+1 path protected  - since it is not end-to-end path
>protected.
>
>To clarify again, this is when you would use SE style.
>
>Thanks
>Suresh
>
>
>At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote:
>
>
>>>This can be used to set up Protected circuits which may contain
>>>1+1 lines and 1+1 path protected segments. So on 1+1 line
>>>protected segments, you Share the bandwidth among primary
>>>and alternate paths.
>>
>>         You do not share the bandwidth across 1+1 circuits. You
>>double-book the bandwidth because the same packets are
>>sent twice: once over each LSP.  You only share bandwidth
>>with 1:N.
>>
>>         --Tom
>>
>>
>>>Setting up protected circuits is not considered
>>>in detail so far. Hopefully, P&R design team will consider this..
>>>
>>>Thanks,
>>>Suresh
>>>
>>>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote:
>>>>Hi,
>>>>
>>>>How does SE style of RSVP signalling fits in the optical nature of network
>>>>i.e. in wavelength, TDM switching etc.
>>>>
>>>>  In other words, How two lsp can share resource in optical networks??
>>>>
>>>>Regards,
>>>>Khuzema.
>>
>>
>>
>>------------------------------------------------------------------------
>>Mathematics is the supreme nostalgia of our time.

Delivery-date: Fri, 12 Apr 2002 14:40:07 -0700
From: Jonathan Lang <[email-masked]>
To: 'Michiel van Everdingen' <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Fri, 12 Apr 2002 14:32:19 -0700

Michiel,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Michiel van Everdingen [mailto:[email-masked]]
> Sent: Thursday, April 11, 2002 9:03 AM
> To: Jonathan Lang
> Cc: [email-masked]
> Subject: Re: LMP & neighbor discovery
> 
> 
> Hello Jonathan,
> 
> 
> Your answer raises some questions in my mind:
> 
> > This is what the Link Verification procedure provides. As part of the
> > BeginVerify message exchange, certain Test parameters (such as
> > Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism)
are
> > exchanged.
> 
> How do you start this link Verification procedure ? The 'beginVerify'
message
> seems to assume that the neighbor is already known.
Sending the BeginVerify assumes you know where to send control messages.
This is separate from discovering the data interfaces. This is why using the
term Neighbor Discovery can often be confusing.  You actually have discovery
at various levels. G.7714 talks about this in a little more detail.

> 
> Please note that I'm discussing initial discovery. I don't question the
use
> of subsequent test messages verifying the connectivity.
Noted.

> 
> 
> > As part of this discovery, NE-3 sends an acknowledgment message carrying
the
> > local (near-end) identity of link B.
> 
> Yes, agreed.
> 
> In my proposal this acknowledgement is in the link correlation procedure.
> The DATA_LINK object in the linkSummary message (which is sent upon
detection
> of the neighbor) gives the association between "Local_Interface_Id" and
> "Remote_Interface_Id".
Link correlation procedure also provides the local/remote mapping for all
data links. The Ack message provides this mapping (in addition to Test
message Ack) for each data channel individually.

> 
> 
> > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> > verification mechanism in advance.
> 
> I'm not discussing verification but initial discovery.
> If we could align on the used procedure for this initial discovery,
> the neighboring NEs don't have to negotiate the mechanism :-)
Verification mechanism is used for data link discovery. Without exchanging
this parameter, you'd have to configure it on both nodes for each port/node
pair. Furthermore, if run LMP-WDM, you may have to configure yet another
mechanism for your wdm neighbor if the termination capabilities are
different.

> 
> 
> > You could certainly create an LMP control channel through a DCN network.
In
> > fact, this is probably the preferred configuration.
> > 
> > > Is implementation of the LMP's 'control channel management' mandatory
?
> > yes, however you can choose not to run the Hellos by setting the
> > HelloInterval and HelloDeadInterval equal to zero.
> 
> I don't understand why the normal network-layer mechanisms (defined in
e.g.
> OSPF or I-ISIS) are not sufficient ?
> Why do we need the LMP specific 'Config' 'ConfigAck' and 'ConfigNack'
> messages ?
These are used to configure the LMP Hellos that are used to rapidly detect
failures along the control channel.

> 
> 
> Thanks !
> 
> Michiel
> 
> 
> Jonathan Lang wrote:
> > 
> > Michiel,
> >   Please see inline.
> > 
> > Thanks,
> > Jonathan
> > 
> > > -----Original Message-----
> > > From: Michiel van Everdingen [mailto:[email-masked]]
> > > Sent: Tuesday, April 09, 2002 12:41 AM
> > > To: [email-masked]
> > > Subject: LMP & neighbor discovery
> > >
> > >
> > > Hello all,
> > >
> > > I found the concept of neighbor discovery mentioned 
> several times in
> > > previous discussions on this list. However, I did not find a final
> > > conclusion on how this neighbor discovery is done. Correct ?
> > >
> > > Could you please check my understanding below ?
> > >
> > > In my mind, reading the incoming 'access point 
> identifier' [ITU-G.707]
> > > and subsequent LMP 'link property correlation' form a 
> perfect fit. By
> > > simply encoding the sending node's IP address and local 
> access point
> > > number in the access point identifier (see e.g. 
> [OIF.2000.159.01]), the
> > > receiver can discover the data link (linkConnection in 
> ITU  terminology).
> > > Subsequent 'link property correlation' could then a.o. 
> check on bi-
> > > directional fibering, matching data link properties and 
> grouping of data
> > > links into TE links.
> > >
> > > Example: the following figure shows 4 network elements of which 2
> > terminate
> > > the data link (TTPs, T) and two are transparent to the 
> data link (CTPs,
> > C).
> > > E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
> > transparent
> > > optical cross connects. The data link in this example is 
> STM-N/OC-N.
> > >
> > > +------+      +------+      +------+      +------+
> > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > |      |   A  |      |   B  |      |   C  |      |
> > > |      |      |      |      |      |      |      |
> > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > +------+      +------+      +------+      +------+
> > >
> > > NE-2 should, when it wants to discover data link B, 
> connect a test-set
> > that
> > > sends an access point identifier to identify the sending 
> connection point
> > C
> > > in NE-2. This test-signal should be send long enough for 
> NE-3 to detect
> > and
> > > read the test-signal (a fixed, agreed upon timer is 
> needed). NE-3 will
> > > continuously scan all its not discovered input ports for 
> a discovery
> > signal.
> > > At some point, it will detect the test-signal on data link B.
> > This is what the Link Verification procedure provides. As 
> part of the
> > BeginVerify message exchange, certain Test parameters (such as
> > Verify_Interval, Verify_Dead_Interval, and 
> Verify_Transport_Mechanism) are
> > exchanged.
> > 
> > >
> > > +------+      +------+      +------+      +------+
> > > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > > |      |   A  |   /  |   B  |  \   |   C  |      |
> > > |      |      |  T   |      |   T  |      |      |
> > > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > > +------+      +------+      +------+      +------+
> > >
> > > When NE-3 has read the access point identifier in the 
> test signal, data
> > > link B is discovered. Subsequent link property 
> correlation can then be
> > > invoked.
> > As part of this discovery, NE-3 sends an acknowledgment 
> message carrying the
> > local (near-end) identity of link B.
> > 
> > >
> > > Discovery of data link A is similar, except that the access point
> > identifier
> > > is continuously sent. Discovery of data link C is also 
> similar, except
> > that
> > > the access point identifier is continuously monitored. In 
> other words,
> > there
> > > is no need for a sending respectively monitoring 
> 'test-set' in NE-1 and
> > NE-4.
> > This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have 
> agreed on the
> > verification mechanism in advance.
> > 
> > >
> > > Data link type          Access point identifier to be used
> > > --------------          ----------------------------------
> > > STM-N, OC-N                            J0
> > > STS-1/3/.../VC-3/4/...                 J1
> > > VT-1.5/VC-11/12                        J2
> > >
> > >
> > > Notes:
> > > - I understand that LMP's link verification procedure is 
> more efficient
> > for
> > >   *already discovered* data links. It does not need the continuous
> > scanning
> > >   on received access point identifiers in undiscovered 
> CTPs (in the
> > example:
> > >   in NE-3).
> > > - Discovering the address of the sending access point 
> might also go via a
> > 'name
> > >   server'. This can, for example, be useful in case the 
> address of this
> > access
> > >   point can not be encoded in the limited length of the 
> access point
> > identifier.
> > >
> > > B.t.w., could you please explain why the linkSummary and 
> linkSummaryAck
> > messages
> > > have to go over a point-to-point control channel ?
> > All LMP messages are sent over the LMP control channel; the 
> health of which
> > is monitored using LMP Hello messages.
> > 
> > > Is it also possible to
> > > use the generic DCN network (MCN/SCN, can be IP-based, 
> see ITU-G.7712) ?
> > > In the latter case, we could simply use the normal UDP 
> service of that
> > network
> > > to transport the linkSummary and linkSummaryAck messages ?
> > You could certainly create an LMP control channel through a 
> DCN network. In
> > fact, this is probably the preferred configuration.
> > 
> > > Is implementation of the LMP's 'control channel 
> management' mandatory ?
> > yes, however you can choose not to run the Hellos by setting the
> > HelloInterval and HelloDeadInterval equal to zero.
> > 
> > >
> > >
> > > Thanks !
> > >
> > > Michiel
> > >
> > > --
> > > 
> +------------------------------------------------------------------+
> > > | Michiel van Everdingen                                  
>          |
> > > | Systems Engineer                                        
>          |
> > > | Lucent Technologies - Optical Networking Group          
>          |
> > > | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883  
>          |
> > > | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976  
>          |
> > > | Huizen, The Netherlands        
> mailto:[email-masked]  |
> > > 
> +------------------------------------------------------------------+
> > >
> 

Delivery-date: Fri, 12 Apr 2002 14:15:42 -0700
Date: Fri, 12 Apr 2002 14:11:16 -0700
From: Sudheer Dharanikota <[email-masked]>
To: John Ellson <[email-masked]>
CC: Suresh Katukam <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Khuzema Pithewan <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: SE style in optical neyworks

Hi Gentelmen:

I changed this list to camp, as it is more appropriate
for this discussion.

I would like to understand the following..

Assumptions:

- Segments of network are inherantly made protected.
  For example, as suresh said, span/UPSR/BLSR etc protected.

- PAth request contains requirements to set up a path
  of *certain* protection guarantees without knowing the
 topoogy and its capability

Now ...

If i want to set up an end-to-end *backup* path, it is the network
(intermediate nodes) which has to decide if a *backup*
link or a segment need to be overloaded. Don't you think in this
case SE may make sense.

Thanks for your input.

sudheer

John Ellson wrote:

> Suresh Katukam wrote:
> >
> > Zhi,
> >
> > You are correct about 1+1 path protected...
> >
> > But if you have a LSP that is protected by some 1+1 links and some
> > UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes
> > (I am not sure what you call this LSP - 1+1 protected, just Protected
> > circuit).
> > In this case, SE style can be used..
>
> If you're talking about nodes other than the nodes that are
> at the the ends of the protection span, then I suggest that you just refer
> to it as a "reliable segment".  It shouldn't matter
> to the end-systems how that segment reliability is achieved.
>
> Protection is only interesting to nodes that have to take part in it,
> otherwise its just a segment of a connection with a greater or
> lesser propensity to failure.
>
> John Ellson

Delivery-date: Fri, 12 Apr 2002 09:24:01 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: [email-masked]
Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents 
Date: Fri, 12 Apr 2002 09:22:45 -0700

Concur with Zhi and Yakov.  As one of the authors who brought in the
SONET/SDH stuff, the intent was not to create additional code points or
rates.  I was rather SONET centric at the time and Eric represented SDH.
Now we are both fully internationalized/americanized...

Greg B.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Friday, April 12, 2002 7:09 AM
To: Zhi-Wei Lin
Cc: [email-masked]
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents 

Zhi,

> Given that for the GMPLS signaling work, we have agreed (I think) to use 
> SDH terminology (but possibly appended with SONET terminology as well), 
> then I believe the -routing-03 document should be revised to include the 
> SDH signal rates along with SONET, e.g., in Section 6.4.2, last 
> paragraph, the rates "VT1.5" and "VT2", VT1.5 should be replaced with 
> "VC-11/VT1.5", and similarly for VT2.
> 
> This of course needs to be done throughout the document.

My suggestion would be just to replace SONET signal rates with SDH
signal rates (rather than including both) throughout the document.

Yakov.

Delivery-date: Fri, 12 Apr 2002 09:04:54 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: LMP MIB
Date: Fri, 12 Apr 2002 18:03:11 +0200

> >Below is the report. PLEASE PLEASE fix those things FIRST.
> >And I did not look at the content at all yet.
> 
> Will do ASAP.  I used smilint and found only warnings, but
> I could be wrong.   Could you post those two URLs that one
> can send MIBs to so that they can be processed?  Others may
> find this useful.
> 
I have now attached the SMIlint errors/warnings as well.
The list is impressive. The wng about length of a descriptor
being lonbger than 32 is one that you can take with a grain
of salt, but many of the other better be checked. Some of
those warnings do not always mean REALLY BROKEN, but in many
cases it is an indication of possible SLOPPY WORK (if I may
be so rude). Why don't you guys try to make the list as short
as possible (or disappear). Or do you want the MIB Doctor 
review or the AD review to be triggered with "red alert
signals" ??

I am not aware you can email a MIB to a SMICng server.
I have a copy and I check all MIBs with the it. So does the
RFC-Editor these days just before a MIB RFC is published.
It is a very strict syntax checker, but that helps me/us pay 
attention to all the incorrect and even to some possibly correct
but questionable uses of syntax. Info at:

   http://www.snmpinfo.com  (sorry it is a bit commercial)

The mail address for SMIlint is as follows:

    [email-masked]

Just put your MIB in the body of the email and it will check
the MIB (highest severity level) and return results.
SMIlint is also available for free and can be downloaded from:

   http://www.ibr.cs.tu-bs.de/projects/libsmi/

>          In any event, a new version will be published after
> the last call period is over that includes all of the suggested
> changes AND compiles cleanly with SmicNg AND SmiLint.
> 
Great Thank you.
But I wanted all people to try and be aware that it might actually
be a VERY GOOD THING to get the syntax correct before even
thinking of a WG Last Call and certainly before sending anything
to the AD for consideration on standards track.

Bert
----- smilint output ------------
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 12, 2002 5:36 PM
To: Wijnen, Bert (Bert)
Subject: Your smilint job

output of smilint -l 9 follows,
empty output means everything is fine.
--start--
81: date specification `200105223200Z' contains an illegal hour
749: warning: object identifier name `dataBearingChannelLinkMuxCapability' longer than 32 characters
770: warning: object identifier name `dataBearingChannelPreferredProtection' longer than 32 characters
782: warning: object identifier name `dataBearingChannelCurrentProtection' longer than 32 characters
820: warning: object identifier name `dataBearingChannelDescriptorTable' longer than 32 characters
903: warning: object identifier name `dataBearingChannelMinReservableBandwidth' longer than 32 characters
918: warning: object identifier name `dataBearingChannelMaxReservableBandwidth' longer than 32 characters
944: warning: object identifier name `dataBearingChannelDescrStorageType' longer than 32 characters
1007: warning: object identifier name `dataBearingChannelUnreservedBandwidth' longer than 32 characters
1022: warning: object identifier name `dataBearingChannelMaximumLspBandwidth' longer than 32 characters
1243: warning: object identifier name `linkBundlingMonitoringModuleCompliance' longer than 32 characters
829: warning: row identifier `dataBearingChannelDescrEntry' should have the same prefix as table identifier `dataBearingChannelDescriptorTable'
1100: warning: refined object `dataBearingChannelDescrRowStatus' not listed in a mandatory or optional group
1100: warning: refined object `dataBearingChannelDescrStorageType' not listed in a mandatory or optional group
1100: warning: refined object `dataBearingChannelBwRowStatus' not listed in a mandatory or optional group
1100: warning: refined object `dataBearingChannelBwStorageType' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelEncodingType' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelDescrPriority' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelMinReservableBandwidth' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelDescrRowStatus' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelDescrStorageType' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelBwRowStatus' not listed in a mandatory or optional group
1243: warning: refined object `dataBearingChannelBwStorageType' not listed in a mandatory or optional group
1495: warning: current group `dataBearingChannelBandwidthGroup' is unconditionally optional
1514: warning: current group `linkBundlingNotificationGroup' is unconditionally optional
5: warning: identifier `Integer32' imported from module `SNMPv2-SMI' is never used
11: warning: identifier `TEXTUAL-CONVENTION' imported from module `SNMPv2-TC' is never used
12: warning: identifier `RowPointer' imported from module `SNMPv2-TC' is never used
12: warning: identifier `TimeStamp' imported from module `SNMPv2-TC' is never used
15: warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used
22: warning: identifier `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used
165: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
174: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
2708: warning: object identifier name `lmpCcChannelStatusRequestReceived' longer than 32 characters
2726: warning: object identifier name `lmpCcChannelStatusRequestRetransmit' longer than 32 characters
2735: warning: object identifier name `lmpCcChannelStatusResponseReceived' longer than 32 characters
3125: warning: object identifier name `lmpDataBearingLinkRemoteIpAddress' longer than 32 characters
3162: warning: object identifier name `lmpDataBearingLinkActiveOperStatus' longer than 32 characters
3180: warning: object identifier name `lmpDataBearingLinkPassiveOperStatus' longer than 32 characters
3272: warning: object identifier name `lmpDataBearingLinkActiveTestSuccess' longer than 32 characters
3282: warning: object identifier name `lmpDataBearingLinkActiveTestFailure' longer than 32 characters
3291: warning: object identifier name `lmpDataBearingLinkPassiveTestSuccess' longer than 32 characters
3301: warning: object identifier name `lmpDataBearingLinkPassiveTestFailure' longer than 32 characters
3311: warning: object identifier name `lmpDataBearingLinkCounterDiscontinuityTime' longer than 32 characters
3330: warning: object identifier name `lmpLinkPropertyMismatchNotifEnable' longer than 32 characters
3403: warning: object identifier name `lmpDataBearingLinkPropertyMismatch' longer than 32 characters
3459: warning: object identifier name `lmpDataBearingLinkVerificationFailure' longer than 32 characters
3978: warning: object identifier name `lmpControlChannelIsInterfaceGroup' longer than 32 characters
3986: warning: object identifier name `lmpControlChannelIsNotInterfaceGroup' longer than 32 characters
1713: warning: index element `lmpNbrNodeId' of row `lmpNbrEntry' should be not-accessible in SMIv2 MIB
1713: warning: index of row `lmpNbrEntry' can exceed OID size limit by 138 subidentifier(s)
1903: warning: index element `lmpCcId' of row `lmpControlChannelEntry' should be not-accessible in SMIv2 MIB
3403: warning: object `ifStackHigherLayer' of notification `lmpDataBearingLinkPropertyMismatch' must not be `not-accessible'
2434: warning: node `lmpCcBeginVerifyRetransmit' must be contained in at least one conformance group
2498: warning: node `lmpCcEndVerifyRetransmit' must be contained in at least one conformance group
2544: warning: node `lmpCcTestStatusSuccessRetransmit' must be contained in at least one conformance group
2571: warning: node `lmpCcTestStatusFailureRetransmit' must be contained in at least one conformance group
2580: warning: node `lmpCcTestStatusAckReceived' must be contained in at least one conformance group
2589: warning: node `lmpCcTestStatusAckSent' must be contained in at least one conformance group
4124: warning: current group `lmpNotificationGroup' is unconditionally optional
1656: warning: textual convention `NodeID' can not be derived from the textual convention `InetAddress'
1530: warning: identifier `Integer32' imported from module `SNMPv2-SMI' is never used
1537: warning: identifier `RowPointer' imported from module `SNMPv2-TC' is never used
1540: warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used
1543: warning: identifier `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used
1733: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
1972: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
2809: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
3125: warning: `InetAddress' object should have an accompanied preceding `InetAdressType' object
--end--

Delivery-date: Fri, 12 Apr 2002 07:51:08 -0700
Date: Fri, 12 Apr 2002 10:49:43 -0400
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: LMP MIB
Cc: Kireeti Kompella <[email-masked]>, [email-masked]

At 04:24 PM 4/12/2002 +0200, Wijnen, Bert (Bert) wrote:
>I guess I don't understand the process of WGs.
>And I think I should udnerstand it as an AD should I not?
>
>But if I were a document author/editor, or if I were a WG
>co-chair, then, before I would even consider a MIB document
>to be ready for WG last call, then I would make SURE that
>the MIB in that document compiles clean.
>
>I fed the MIB to SMICng. It causes lots of trouble, errors,
>warnings. It also depends on the mpls bundle mib. Which in
>turn also cause lots of trouble and warnings. 21 Errors
>and 51 warnings all together.
>
>Below is the report. PLEASE PLEASE fix those things FIRST.
>And I did not look at the content at all yet.

         Will do ASAP.  I used smilint and found only warnings, but
I could be wrong.   Could you post those two URLs that one
can send MIBs to so that they can be processed?  Others may
find this useful.

         In any event, a new version will be published after
the last call period is over that includes all of the suggested
changes AND compiles cleanly with SmicNg AND SmiLint.

         --Tom

>Bert
>
>--------- SMICng report ----------
>In file mplsbundle.mi2
>     80:    REVISION
>     81:        "200105223200Z"  -- 22 May 2001 12:00:00 EST
>                ^
>W: REVISION value "200105223200Z" is not a valid extended UTC time
>   1124:
>   1125:       OBJECT      teLinkRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "teLinkRowStatus"
>   1132:
>   1133:       OBJECT      teLinkStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "teLinkStorageType"
>   1140:
>   1141:       OBJECT      teLinkDescrRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "teLinkDescrRowStatus"
>   1147:
>   1148:       OBJECT      teLinkDescrStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "teLinkDescrStorageType"
>   1156:       OBJECT      teLinkOspfLinkId
>   1157:       SYNTAX      INTEGER { pointToPoint(1) }
>                           ^
>E: Syntax type does not match that for "teLinkOspfLinkId"
>   1155:
>   1156:       OBJECT      teLinkOspfLinkId
>                           ^
>E: MIN-ACCESS value incompatible with access specified for "teLinkOspfLinkId"
>   1163:
>   1164:       OBJECT      srlgRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "srlgRowStatus"
>   1171:
>   1172:       OBJECT      srlgStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "srlgStorageType"
>   1179:
>   1180:       OBJECT      teLinkBandwidthRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"teLinkBandwidthRowStatus"
>   1187:
>   1188:       OBJECT      teLinkBandwidthStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"teLinkBandwidthStorageType"
>   1195:
>   1196:       OBJECT      dataBearingChannelRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelRowStatus"
>   1203:
>   1204:       OBJECT      dataBearingChannelStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelStorageType"
>   1211:
>   1212:       OBJECT      dataBearingChannelDescrRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelDescrRowStatus"
>   1218:
>   1219:       OBJECT      dataBearingChannelDescrStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelDescrStorageType"
>   1226:
>   1227:       OBJECT      dataBearingChannelBwRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelBwRowStatus"
>   1234:
>   1235:       OBJECT      dataBearingChannelBwStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"dataBearingChannelBwStorageType"
>   1211:
>   1212:       OBJECT      dataBearingChannelDescrRowStatus
>                           ^
>E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1218:
>   1219:       OBJECT      dataBearingChannelDescrStorageType
>                           ^
>E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY 
>or conditional group for module "LINK-BUNDLING-MIB"
>   1226:
>   1227:       OBJECT      dataBearingChannelBwRowStatus
>                           ^
>E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1234:
>   1235:       OBJECT      dataBearingChannelBwStorageType
>                           ^
>E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1314:       OBJECT      teLinkOspfLinkId
>   1315:       SYNTAX      INTEGER { pointToPoint(1) }
>                           ^
>E: Syntax type does not match that for "teLinkOspfLinkId"
>   1313:
>   1314:       OBJECT      teLinkOspfLinkId
>                           ^
>W: MIN-ACCESS value identical to access specified for "teLinkOspfLinkId"
>   1375:
>   1376:       OBJECT      dataBearingChannelEncodingType
>                           ^
>E: OBJECT-TYPE "dataBearingChannelEncodingType" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1380:
>   1381:       OBJECT      dataBearingChannelDescrPriority
>                           ^
>E: OBJECT-TYPE "dataBearingChannelDescrPriority" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1385:
>   1386:       OBJECT      dataBearingChannelMinReservableBandwidth
>                           ^
>E: OBJECT-TYPE "dataBearingChannelMinReservableBandwidth" is not in a 
>MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
>   1390:
>   1391:       OBJECT      dataBearingChannelDescrRowStatus
>                           ^
>E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1397:
>   1398:       OBJECT      dataBearingChannelDescrStorageType
>                           ^
>E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY 
>or conditional group for module "LINK-BUNDLING-MIB"
>   1405:
>   1406:       OBJECT      dataBearingChannelBwRowStatus
>                           ^
>E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>   1413:
>   1414:       OBJECT      dataBearingChannelBwStorageType
>                           ^
>E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or 
>conditional group for module "LINK-BUNDLING-MIB"
>      4:    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
>      5:    experimental, Integer32, Unsigned32
>                          ^
>W: "Integer32" imported but not used
>     10:
>     11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
>            ^
>W: "TEXTUAL-CONVENTION" imported but not used
>     11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
>     12:    RowPointer, TimeStamp
>            ^
>W: "RowPointer" imported but not used
>                        ^
>W: "TimeStamp" imported but not used
>     14:
>     15:    InterfaceIndex, InterfaceIndexOrZero, ifIndex
>            ^
>W: "InterfaceIndex" imported but not used
>     21:
>     22:    InetAddressType, InetAddress
>            ^
>W: "InetAddressType" imported but not used
>
>------------------------------------------------------------------
>In file lmp.mi2
>    134:        "This value represents a Node ID."
>    135:    SYNTAX        InetAddress
>                          ^
>E: In defining TC "NodeID", cannot define using syntax "InetAddress", 
>which is another TC
>   1448:                      -- SONET/SDH encoding type:
>   1449:                      j016OverheadBytes(1),
>                              ^
>E: First named bit for BITS must be position zero
>    194:         every pair of nodes that can establish control channels."
>    195:    INDEX         { lmpNbrNodeId }
>                            ^
>E: Index item "lmpNbrNodeId" may not have "read-write", "write-only", 
>"read-create", or "accessible-for-notify" access
>    207:
>    208: lmpNbrNodeId OBJECT-TYPE
>         ^
>E: Item "lmpNbrNodeId" has invalid value for MAX-ACCESS because it is an 
>index column
>    386:         well (see RFC 2863)."
>    387:    INDEX         { lmpCcId }
>                            ^
>E: Index item "lmpCcId" may not have "read-write", "write-only", 
>"read-create", or "accessible-for-notify" access
>    414:
>    415: lmpCcId OBJECT-TYPE
>         ^
>E: Item "lmpCcId" has invalid value for MAX-ACCESS because it is an index 
>column
>   1878: lmpDataBearingLinkPropertyMismatch NOTIFICATION-TYPE
>   1879:    OBJECTS       { ifStackHigherLayer,
>                            ^
>E: Variable "ifStackHigherLayer" in notification 
>"lmpDataBearingLinkPropertyMismatch" has access of "not-accessible"
>   2517:              lmpCcBeginVerifySent,
>   2518:              lmpCcBeginVerifyReceived,
>                      ^
>W: Duplicate item "lmpCcBeginVerifyReceived" in object-group 
>"lmpPerfGroup" OBJECTS list
>   2524:              lmpCcEndVerifySent,
>   2525:              lmpCcEndVerifyReceived,
>                      ^
>W: Duplicate item "lmpCcEndVerifyReceived" in object-group "lmpPerfGroup" 
>OBJECTS list
>   2529:              lmpCcTestStatusSuccessSent,
>   2530:              lmpCcTestStatusSuccessReceived,
>                      ^
>W: Duplicate item "lmpCcTestStatusSuccessReceived" in object-group 
>"lmpPerfGroup" OBJECTS list
>   2532:              lmpCcTestStatusFailureSent,
>   2533:              lmpCcTestStatusFailureReceived,
>                      ^
>W: Duplicate item "lmpCcTestStatusFailureReceived" in object-group 
>"lmpPerfGroup" OBJECTS list
>    908:
>    909: lmpCcBeginVerifyRetransmit OBJECT-TYPE
>         ^
>W: Item "lmpCcBeginVerifyRetransmit" is not contained in any group defined 
>in the current module
>    972:
>    973: lmpCcEndVerifyRetransmit OBJECT-TYPE
>         ^
>W: Item "lmpCcEndVerifyRetransmit" is not contained in any group defined 
>in the current module
>   1018:
>   1019: lmpCcTestStatusSuccessRetransmit OBJECT-TYPE
>         ^
>W: Item "lmpCcTestStatusSuccessRetransmit" is not contained in any group 
>defined in the current module
>   1045:
>   1046: lmpCcTestStatusFailureRetransmit OBJECT-TYPE
>         ^
>W: Item "lmpCcTestStatusFailureRetransmit" is not contained in any group 
>defined in the current module
>   1054:
>   1055: lmpCcTestStatusAckReceived OBJECT-TYPE
>         ^
>W: Item "lmpCcTestStatusAckReceived" is not contained in any group defined 
>in the current module
>   1063:
>   1064: lmpCcTestStatusAckSent OBJECT-TYPE
>         ^
>W: Item "lmpCcTestStatusAckSent" is not contained in any group defined in 
>the current module
>   1992:
>   1993:       OBJECT      lmpNbrRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpNbrRowStatus"
>   2000:
>   2001:       OBJECT      lmpNbrStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpNbrStorageType"
>   2008:
>   2009:       OBJECT      lmpCcRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpCcRowStatus"
>   2016:
>   2017:       OBJECT      lmpCcOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpCcOperStatus"
>   2023:
>   2024:       OBJECT      lmpCcStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpCcStorageType"
>   2031:
>   2032:       OBJECT      lmpTeLinkOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpTeLinkOperStatus"
>   2037:
>   2038:       OBJECT      lmpTeLinkRowStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpTeLinkRowStatus"
>   2045:
>   2046:       OBJECT      lmpTeLinkStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpTeLinkStorageType"
>   2053:
>   2054:       OBJECT      lmpDataBearingLinkActiveOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"lmpDataBearingLinkActiveOperStatus"
>   2059:
>   2060:       OBJECT      lmpDataBearingLinkPassiveOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"lmpDataBearingLinkPassiveOperStatus"
>   2074:
>   2075:       OBJECT      lmpDataBearingLinkStorageType
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"lmpDataBearingLinkStorageType"
>   2254:
>   2255:       OBJECT      lmpCcOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpCcOperStatus"
>   2307:
>   2308:       OBJECT      lmpTeLinkOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for "lmpTeLinkOperStatus"
>   2366:
>   2367:       OBJECT      lmpDataBearingLinkActiveOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"lmpDataBearingLinkActiveOperStatus"
>   2372:
>   2373:       OBJECT      lmpDataBearingLinkPassiveOperStatus
>                           ^
>W: MIN-ACCESS value identical to access specified for 
>"lmpDataBearingLinkPassiveOperStatus"
>      4:    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
>      5:    experimental, Integer32, Unsigned32, Counter32, TimeTicks
>                          ^
>W: "Integer32" imported but not used
>     11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
>     12:    RowPointer, TimeStamp
>            ^
>W: "RowPointer" imported but not used
>     14:
>     15:    InterfaceIndex, InterfaceIndexOrZero, ifIndex, ifStackHigherLayer
>            ^
>W: "InterfaceIndex" imported but not used
>     17:
>     18:    InetAddressType, InetAddress
>            ^
>W: "InetAddressType" imported but not used
>
>*** 21 errors and 51 warnings in parsing
>
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Thursday, April 11, 2002 7:34 PM
> > To: [email-masked]
> > Subject: LMP MIB
> >
> >
> > The authors of the LMP MIB
> >       draft-ietf-ccamp-lmp-mib-01.txt
> > feel that it is ready for WG Last Call.
> >
> > Please comment by COB April 18th, especially if you think this
> > work is *not* ready.
> >
> > Authors: please read the ID Nits page and make any editorial
> > corrections needed, preferably prior to WG Last Call.
> >
> > Kireeti.
> >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Fri, 12 Apr 2002 07:24:50 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: LMP MIB
Date: Fri, 12 Apr 2002 16:24:18 +0200

I guess I don't understand the process of WGs.
And I think I should udnerstand it as an AD should I not?

But if I were a document author/editor, or if I were a WG
co-chair, then, before I would even consider a MIB document
to be ready for WG last call, then I would make SURE that
the MIB in that document compiles clean.

I fed the MIB to SMICng. It causes lots of trouble, errors,
warnings. It also depends on the mpls bundle mib. Which in
turn also cause lots of trouble and warnings. 21 Errors
and 51 warnings all together.

Below is the report. PLEASE PLEASE fix those things FIRST.
And I did not look at the content at all yet.

Bert 

--------- SMICng report ----------
In file mplsbundle.mi2
    80:    REVISION
    81:        "200105223200Z"  -- 22 May 2001 12:00:00 EST
               ^
W: REVISION value "200105223200Z" is not a valid extended UTC time
  1124: 
  1125:       OBJECT      teLinkRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkRowStatus"
  1132: 
  1133:       OBJECT      teLinkStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkStorageType"
  1140: 
  1141:       OBJECT      teLinkDescrRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkDescrRowStatus"
  1147: 
  1148:       OBJECT      teLinkDescrStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkDescrStorageType"
  1156:       OBJECT      teLinkOspfLinkId
  1157:       SYNTAX      INTEGER { pointToPoint(1) }
                          ^
E: Syntax type does not match that for "teLinkOspfLinkId"
  1155: 
  1156:       OBJECT      teLinkOspfLinkId
                          ^
E: MIN-ACCESS value incompatible with access specified for "teLinkOspfLinkId"
  1163: 
  1164:       OBJECT      srlgRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "srlgRowStatus"
  1171: 
  1172:       OBJECT      srlgStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "srlgStorageType"
  1179: 
  1180:       OBJECT      teLinkBandwidthRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkBandwidthRowStatus"
  1187: 
  1188:       OBJECT      teLinkBandwidthStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkBandwidthStorageType"
  1195: 
  1196:       OBJECT      dataBearingChannelRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelRowStatus"
  1203: 
  1204:       OBJECT      dataBearingChannelStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelStorageType"
  1211: 
  1212:       OBJECT      dataBearingChannelDescrRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelDescrRowStatus"
  1218: 
  1219:       OBJECT      dataBearingChannelDescrStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelDescrStorageType"
  1226: 
  1227:       OBJECT      dataBearingChannelBwRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelBwRowStatus"
  1234: 
  1235:       OBJECT      dataBearingChannelBwStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "dataBearingChannelBwStorageType"
  1211: 
  1212:       OBJECT      dataBearingChannelDescrRowStatus
                          ^
E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1218: 
  1219:       OBJECT      dataBearingChannelDescrStorageType
                          ^
E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1226: 
  1227:       OBJECT      dataBearingChannelBwRowStatus
                          ^
E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1234: 
  1235:       OBJECT      dataBearingChannelBwStorageType
                          ^
E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1314:       OBJECT      teLinkOspfLinkId
  1315:       SYNTAX      INTEGER { pointToPoint(1) }
                          ^
E: Syntax type does not match that for "teLinkOspfLinkId"
  1313: 
  1314:       OBJECT      teLinkOspfLinkId
                          ^
W: MIN-ACCESS value identical to access specified for "teLinkOspfLinkId"
  1375: 
  1376:       OBJECT      dataBearingChannelEncodingType
                          ^
E: OBJECT-TYPE "dataBearingChannelEncodingType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1380: 
  1381:       OBJECT      dataBearingChannelDescrPriority
                          ^
E: OBJECT-TYPE "dataBearingChannelDescrPriority" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1385: 
  1386:       OBJECT      dataBearingChannelMinReservableBandwidth
                          ^
E: OBJECT-TYPE "dataBearingChannelMinReservableBandwidth" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1390: 
  1391:       OBJECT      dataBearingChannelDescrRowStatus
                          ^
E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1397: 
  1398:       OBJECT      dataBearingChannelDescrStorageType
                          ^
E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1405: 
  1406:       OBJECT      dataBearingChannelBwRowStatus
                          ^
E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
  1413: 
  1414:       OBJECT      dataBearingChannelBwStorageType
                          ^
E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB"
     4:    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
     5:    experimental, Integer32, Unsigned32
                         ^
W: "Integer32" imported but not used
    10: 
    11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
           ^
W: "TEXTUAL-CONVENTION" imported but not used
    11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
    12:    RowPointer, TimeStamp
           ^
W: "RowPointer" imported but not used
                       ^
W: "TimeStamp" imported but not used
    14: 
    15:    InterfaceIndex, InterfaceIndexOrZero, ifIndex
           ^
W: "InterfaceIndex" imported but not used
    21: 
    22:    InetAddressType, InetAddress
           ^
W: "InetAddressType" imported but not used

------------------------------------------------------------------
In file lmp.mi2
   134:        "This value represents a Node ID."
   135:    SYNTAX        InetAddress
                         ^
E: In defining TC "NodeID", cannot define using syntax "InetAddress", which is another TC
  1448:                      -- SONET/SDH encoding type:
  1449:                      j016OverheadBytes(1),
                             ^
E: First named bit for BITS must be position zero
   194:         every pair of nodes that can establish control channels."
   195:    INDEX         { lmpNbrNodeId }
                           ^
E: Index item "lmpNbrNodeId" may not have "read-write", "write-only", "read-create", or "accessible-for-notify" access
   207: 
   208: lmpNbrNodeId OBJECT-TYPE
        ^
E: Item "lmpNbrNodeId" has invalid value for MAX-ACCESS because it is an index column
   386:         well (see RFC 2863)."
   387:    INDEX         { lmpCcId }
                           ^
E: Index item "lmpCcId" may not have "read-write", "write-only", "read-create", or "accessible-for-notify" access
   414: 
   415: lmpCcId OBJECT-TYPE
        ^
E: Item "lmpCcId" has invalid value for MAX-ACCESS because it is an index column
  1878: lmpDataBearingLinkPropertyMismatch NOTIFICATION-TYPE
  1879:    OBJECTS       { ifStackHigherLayer,
                           ^
E: Variable "ifStackHigherLayer" in notification "lmpDataBearingLinkPropertyMismatch" has access of "not-accessible"
  2517:              lmpCcBeginVerifySent,
  2518:              lmpCcBeginVerifyReceived,
                     ^
W: Duplicate item "lmpCcBeginVerifyReceived" in object-group "lmpPerfGroup" OBJECTS list
  2524:              lmpCcEndVerifySent,
  2525:              lmpCcEndVerifyReceived,
                     ^
W: Duplicate item "lmpCcEndVerifyReceived" in object-group "lmpPerfGroup" OBJECTS list
  2529:              lmpCcTestStatusSuccessSent,
  2530:              lmpCcTestStatusSuccessReceived,
                     ^
W: Duplicate item "lmpCcTestStatusSuccessReceived" in object-group "lmpPerfGroup" OBJECTS list
  2532:              lmpCcTestStatusFailureSent,
  2533:              lmpCcTestStatusFailureReceived,
                     ^
W: Duplicate item "lmpCcTestStatusFailureReceived" in object-group "lmpPerfGroup" OBJECTS list
   908: 
   909: lmpCcBeginVerifyRetransmit OBJECT-TYPE
        ^
W: Item "lmpCcBeginVerifyRetransmit" is not contained in any group defined in the current module
   972: 
   973: lmpCcEndVerifyRetransmit OBJECT-TYPE
        ^
W: Item "lmpCcEndVerifyRetransmit" is not contained in any group defined in the current module
  1018: 
  1019: lmpCcTestStatusSuccessRetransmit OBJECT-TYPE
        ^
W: Item "lmpCcTestStatusSuccessRetransmit" is not contained in any group defined in the current module
  1045: 
  1046: lmpCcTestStatusFailureRetransmit OBJECT-TYPE
        ^
W: Item "lmpCcTestStatusFailureRetransmit" is not contained in any group defined in the current module
  1054: 
  1055: lmpCcTestStatusAckReceived OBJECT-TYPE
        ^
W: Item "lmpCcTestStatusAckReceived" is not contained in any group defined in the current module
  1063: 
  1064: lmpCcTestStatusAckSent OBJECT-TYPE
        ^
W: Item "lmpCcTestStatusAckSent" is not contained in any group defined in the current module
  1992: 
  1993:       OBJECT      lmpNbrRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpNbrRowStatus"
  2000: 
  2001:       OBJECT      lmpNbrStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "lmpNbrStorageType"
  2008: 
  2009:       OBJECT      lmpCcRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpCcRowStatus"
  2016: 
  2017:       OBJECT      lmpCcOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpCcOperStatus"
  2023: 
  2024:       OBJECT      lmpCcStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "lmpCcStorageType"
  2031: 
  2032:       OBJECT      lmpTeLinkOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpTeLinkOperStatus"
  2037: 
  2038:       OBJECT      lmpTeLinkRowStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpTeLinkRowStatus"
  2045: 
  2046:       OBJECT      lmpTeLinkStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "lmpTeLinkStorageType"
  2053: 
  2054:       OBJECT      lmpDataBearingLinkActiveOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpDataBearingLinkActiveOperStatus"
  2059: 
  2060:       OBJECT      lmpDataBearingLinkPassiveOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpDataBearingLinkPassiveOperStatus"
  2074: 
  2075:       OBJECT      lmpDataBearingLinkStorageType
                          ^
W: MIN-ACCESS value identical to access specified for "lmpDataBearingLinkStorageType"
  2254: 
  2255:       OBJECT      lmpCcOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpCcOperStatus"
  2307: 
  2308:       OBJECT      lmpTeLinkOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpTeLinkOperStatus"
  2366: 
  2367:       OBJECT      lmpDataBearingLinkActiveOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpDataBearingLinkActiveOperStatus"
  2372: 
  2373:       OBJECT      lmpDataBearingLinkPassiveOperStatus
                          ^
W: MIN-ACCESS value identical to access specified for "lmpDataBearingLinkPassiveOperStatus"
     4:    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
     5:    experimental, Integer32, Unsigned32, Counter32, TimeTicks
                         ^
W: "Integer32" imported but not used
    11:    TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
    12:    RowPointer, TimeStamp
           ^
W: "RowPointer" imported but not used
    14: 
    15:    InterfaceIndex, InterfaceIndexOrZero, ifIndex, ifStackHigherLayer
           ^
W: "InterfaceIndex" imported but not used
    17: 
    18:    InetAddressType, InetAddress
           ^
W: "InetAddressType" imported but not used

*** 21 errors and 51 warnings in parsing

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, April 11, 2002 7:34 PM
> To: [email-masked]
> Subject: LMP MIB
> 
> 
> The authors of the LMP MIB
> 	draft-ietf-ccamp-lmp-mib-01.txt
> feel that it is ready for WG Last Call.
> 
> Please comment by COB April 18th, especially if you think this
> work is *not* ready.
> 
> Authors: please read the ID Nits page and make any editorial
> corrections needed, preferably prior to WG Last Call.
> 
> Kireeti.
> 
> 

Delivery-date: Fri, 12 Apr 2002 07:11:30 -0700
To: Zhi-Wei Lin <[email-masked]>
cc: [email-masked]
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents 
Date: Fri, 12 Apr 2002 07:08:35 -0700
From: Yakov Rekhter <[email-masked]>

Zhi,

> Given that for the GMPLS signaling work, we have agreed (I think) to use 
> SDH terminology (but possibly appended with SONET terminology as well), 
> then I believe the -routing-03 document should be revised to include the 
> SDH signal rates along with SONET, e.g., in Section 6.4.2, last 
> paragraph, the rates "VT1.5" and "VT2", VT1.5 should be replaced with 
> "VC-11/VT1.5", and similarly for VT2.
> 
> This of course needs to be done throughout the document.

My suggestion would be just to replace SONET signal rates with SDH
signal rates (rather than including both) throughout the document.

Yakov.

Delivery-date: Fri, 12 Apr 2002 05:41:59 -0700
Date: Fri, 12 Apr 2002 08:40:10 -0400
From: Zhi-Wei Lin <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents

Hi Kireeti,

Given that for the GMPLS signaling work, we have agreed (I think) to use 
SDH terminology (but possibly appended with SONET terminology as well), 
then I believe the -routing-03 document should be revised to include the 
SDH signal rates along with SONET, e.g., in Section 6.4.2, last 
paragraph, the rates "VT1.5" and "VT2", VT1.5 should be replaced with 
"VC-11/VT1.5", and similarly for VT2.

This of course needs to be done throughout the document.

For equivalent rates, you can see the -sonet-sdh-03 document section 2.1 
for reference.

Zhi

Kireeti Kompella wrote:

>Hi,
>
>This is to announce a two week WG Last Call on the GMPLS routing
>documents, i.e.:
>draft-ietf-ccamp-gmpls-routing-03.txt
>draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
>
>FYI: these documents are intended to be Standards Track.
>
>The Last Call will end at 1700 EDT, April 17th.
>
>Kireeti.
>
>

Delivery-date: Fri, 12 Apr 2002 04:07:02 -0700
From: Andy Kilpatrick <[email-masked]>
To: Juniper - Kireeti Kompella <[email-masked]>
Cc: [email-masked], Meriton - Martin Dubuc <[email-masked]>,  Calient - Jonathan Lang <[email-masked]>
Subject: RE: LMP MIB
Date: Fri, 12 Apr 2002 12:05:19 +0100

Kireeti,

I believe that there are discrepencies between the LMP-MIB draft and current
LMP draft (draft-ietf-ccamp-lmp-03.txt) which need to be resolved in the
LMP-MIB.

- lmpTeLinkOperStatus states do not match the TE Link FSM states defined in
LMP 12.2.1 (the degraded state has been retired)
- lmpVerifyTransportMechanism does not include the J0-trace option defined
in LMP 14.9
- The lmpDataBearingLinkTable does not allow configuration of all the fields
of the Interface Switching Capability and Wavelength subobjects defined in
LMP 14.13.1.  LMP 14.14 also allows multiple DATA_LINK subobjects to be
configured - there is no support for this in the LMP-MIB.

I also have some feedback on the updates from the lmp-mib-00 draft made to
lmp-mib-01.

1. Local ifIndex has been removed from the TEL and DBL mismatch
Notifications (traps)
- This significantly reduces the usability of these notifications -
particularly if the local administrator does not have access to the remote
configuration.
- Proposal: reinstate this field.

2. lmpDataBearingLinkNumberingType values are not consistent with RFC 2851
(InetAddressType Textual Convention).
- LMP-MIB defines the values 1,2,3 for unnumbered, ipv4, ipv6.
- RFC 2851 defines the values 0,1,2 for "other", ipv4, ipv6.
- Proposal: to avoid confusion I recommend changing LMP-MIB to use the RFC
2851 values.

3. lmpNbrRetransmitInterval & lmpNbrRetransmitTimeout
- These values should apply to all acknowledged CC messages - including
TestStatusSuccess, TestStatusFailure, ChannelStatus, ChannelStatusRequest
[and also ServiceConfig from the O-UNI spec].
- Proposal: add this clarification to the draft

4. lmpCcHelloDeadIntervalDefault
- The clause "The HelloDeadInterval parameter must be greater than the
HelloInterval parameter..." has been removed.  If this is to allow the Hello
mechanism to be disabled by setting both to 0, would it be better to say
"greater than or equal to", rather than not mention it at all?

5. lmpControlChannelDown notification
- This should be generated when a CC transitions out of the up operational
state, by symmetry with the lmpControlChannelUp notification.

Andy Kilpatrick
Network Convergence Group
Data Connection Ltd
Tel:	+44 20 8366 1177		Fax:	+44 20 8363 1468
Email:	[email-masked]	Web:	http://www.dataconnection.com

-----Original Message-----
From: Juniper - Kireeti Kompella 
Sent: 11 April 2002 18:33
To: [email-masked]
Subject: LMP MIB

The authors of the LMP MIB
	draft-ietf-ccamp-lmp-mib-01.txt
feel that it is ready for WG Last Call.

Please comment by COB April 18th, especially if you think this
work is *not* ready.

Authors: please read the ID Nits page and make any editorial
corrections needed, preferably prior to WG Last Call.

Kireeti.

Delivery-date: Fri, 12 Apr 2002 01:40:33 -0700
Date: Fri, 12 Apr 2002 01:39:18 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Zafar Ali <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: LC comments on  draft-ietf-ccamp-ospf-gmpls-extensions-05.txt 

On Fri, 12 Apr 2002, Zafar Ali wrote:

> A way of exchanging the Link Identifiers for Unnumbered TE links (with
> interface switching cap of PSC-1 to PSC-4) is missing from the draft. In
> ISIS, the unnumbered TE link identifiers can be exchanged using Link
> Identifies in the Extended Local Circuit ID field of the "Point-to-Point
> Three-Way Adjacency" IS-IS Option type [draft-ietf-isis-3way-05.txt]. Can
> you please define an equivalent mechanism for the OSPF in the draft?

Excellent point.  We have a way of doing this (namely, a link-local
opaque LSA, similar to grace-LSAs), but we weren't sure whether to put
it in this draft or a companion draft.

To keep the parallelism with the ISIS draft, we should probably just
add this specification to this draft ...

Kireeti.

Delivery-date: Thu, 11 Apr 2002 22:45:32 -0700
Date: Fri, 12 Apr 2002 01:42:21 -0400
To: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Zafar Ali <[email-masked]>
Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt 
Cc: [email-masked], [email-masked]

--=====================_16882155==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear Fellow Authors:

A way of exchanging the Link Identifiers for Unnumbered TE links (with=20
interface switching cap of PSC-1 to PSC-4) is missing from the draft. In=20
ISIS, the unnumbered TE link identifiers can be exchanged using Link=20
Identifies in the Extended Local Circuit ID field of the "Point-to-Point=20
Three-Way Adjacency" IS-IS Option type [draft-ietf-isis-3way-05.txt]. Can=20
you please define an equivalent mechanism for the OSPF in the draft?

Thanks

Regards=85 Zafar=20
--=====================_16882155==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<font size=3D3>Dear Fellow Authors:<br>
<br>
A way of exchanging the Link Identifiers for Unnumbered TE links (with
interface switching cap of PSC-1 to PSC-4) is missing from the draft. In
ISIS, the unnumbered TE link identifiers can be exchanged using Link
Identifies in the Extended Local Circuit ID field of the
&quot;Point-to-Point Three-Way Adjacency&quot; IS-IS Option type
[draft-ietf-isis-3way-05.txt]. Can you please define an equivalent
mechanism for the OSPF in the draft? <br>
<br>
Thanks<br>
<br>
Regards=85 Zafar </font></html>

--=====================_16882155==_.ALT--

Delivery-date: Thu, 11 Apr 2002 16:18:59 -0700
Date: Thu, 11 Apr 2002 16:18:20 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Baktha Muralidharan <[email-masked]>
cc: <[email-masked]>
Subject: Re: LMP MIB

On Thu, 11 Apr 2002, Baktha Muralidharan wrote:

> Comments on the LMP MIB:

Thanks!  That was quick!

> >         1.Data Link Adddress is of type InetAddressType--- not sure
> > if  this covers NSAP, required by OIF OUNI

I see that the OIF UNI comes up over and over.  The OIF UNI is *NOT*
specified by CCAMP; hence "required by OIF OUNI" has little official
meaning to CCAMP.

However, if what the OIF UNI needs comes for free (as in this case),
that's fine.  In this case, NSAP is covered by IPv6, and thus by
InetAddressType.

> >         2. CC ID. How will applications know what to set this to? Suggesr
> > defining a "CCIDNext"
>              object that will dole out values to be used in row creation

Good idea.

> >         3. TE oper status includes a "testing", which is not in the LMP
> > draft's definition of
>                TE Link Finite State Machine states.

It is likely that implementations will have a "test" mode.  Is that
the intent of the authors?

The rest of your comments I leave to the authors.

Kireeti.

Delivery-date: Thu, 11 Apr 2002 16:06:59 -0700
Date: Thu, 11 Apr 2002 16:00:45 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

Yakov,

 Thanks for the follow up.
 See below, pls.

>> It might be a good idea to explicitly mention that only
>> intra-area issues are covered here.

> That is not exactly correct, as the extensions defined in this
> document could certainly be used for establishing LSPs that span
> multiple area. An example of how this could be accomplished can
> be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt.

OK, I see what you mean. What I meant is that the document
does not described any sort of aggregation and distribution
of introduced parameters between areas.

>> [OSPF-TE] says:
>> 
>>    The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
>>    exactly once.  All other sub-TLVs defined here may occur at most
>>    once.  These restrictions need not apply to future sub-TLVs.
>>    Unrecognized sub-TLVs are ignored.
>> 
>> Considering the last two sentences, it would be really nice if
>> this document said something about this.
>> 
>> You might also say something about processing of sub-TLVs
>> with unexpected length.

> Could you please suggest the text.

If I may, I would leave the exact wording to the authors, please.
I would, however, be willing to review proposed text.

>> > 5.1. Link Local Identifier
>> > 
>> >    A  Link Local Identifier is a sub-TLV of the Link TLV with type 11,
>> >    and length 4.
>> 
>> What do I put in it?

> Link Local Identifier. For more information consult Section 6.1
> of draft-ietf-ccamp-gmpls-routing-03.txt.

Please specify in the draft (though the names happen to be the same).

>> > 5.2. Link Remote Identifier
>> > 
>> >    A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
>> >    and length 4.
>> > 
>> 
>> Ditto

> Link Remote Identifier. For more information consult Section 6.1
> of draft-ietf-ccamp-gmpls-routing-03.txt.

Ditto

>> > 5.3. Link Protection Type
>> > 
>> >    The Link Protection Type is a sub-TLV of the Link TLV, with type 14,
>> >    and length of four octets, the first of which is a bit vector
>> >    describing the protection capabilities of the link. They are:
>> 
>> Something should also be said about other octets.

> Ditto.

>> Are they reserved and ignored on receipt?

> Should be set to zero by the sender and should be ignored on receipt.

Please specify as well.

Thanks a lot!

Alex

Delivery-date: Thu, 11 Apr 2002 12:51:11 -0700
Date: Thu, 11 Apr 2002 15:49:49 -0400
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Re: LMP MIB

Comments on the LMP MIB:

>         1.Data Link Adddress is of type InetAddressType--- not sure 
> if  this covers NSAP,
>            required by OIF OUNI
>         2. CC ID. How will applications know what to set this to? Suggesr 
> defining a "CCIDNext"
             object that will dole out values to be used in row creation
>         3. TE oper status includes a "testing", which is not in the LMP 
> draft's definition of
               TE Link Finite State Machine states.
>         4. Add an attribute to the data bearing link table, to indicate 
> which "bundle" (TE Link) owns it
>         5. CC Trap won't work if CC is not modeled as an ifEntry
>         6. Since we have traps for "TE Link has degraded", would be 
> useful to have traps when TE Link
>             moves out of the degraded state.
>         7. It will be quite useful to have objects that store the reason 
> why a CC or TE Link or Data
                bearing link is in down state, since each of them could go 
into down state due to a number of different
>             reasons.
>         8. Data bearing link table should include objects for the following:
>                 a. Interface switching capability
>                 b. bandwidth
                These are defined in the LMP draft
>         9. Given the contention resolution definition in OUNI OIF draft, 
> why do we need the Role
>             object in CC table

          10. Configurable retry limit for message retransmissions

Thanks

/Baktha Muralidharan
Cisco Systems

Delivery-date: Thu, 11 Apr 2002 10:35:09 -0700
Date: Thu, 11 Apr 2002 10:33:30 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: LMP MIB

The authors of the LMP MIB
	draft-ietf-ccamp-lmp-mib-01.txt
feel that it is ready for WG Last Call.

Please comment by COB April 18th, especially if you think this
work is *not* ready.

Authors: please read the ID Nits page and make any editorial
corrections needed, preferably prior to WG Last Call.

Kireeti.

Delivery-date: Thu, 11 Apr 2002 09:04:35 -0700
Cc: [email-masked]
Date: Thu, 11 Apr 2002 18:03:26 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Jonathan,

Your answer raises some questions in my mind:

> This is what the Link Verification procedure provides. As part of the
> BeginVerify message exchange, certain Test parameters (such as
> Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
> exchanged.

How do you start this link Verification procedure ? The 'beginVerify' message
seems to assume that the neighbor is already known.

Please note that I'm discussing initial discovery. I don't question the use
of subsequent test messages verifying the connectivity.

> As part of this discovery, NE-3 sends an acknowledgment message carrying the
> local (near-end) identity of link B.

Yes, agreed.

In my proposal this acknowledgement is in the link correlation procedure.
The DATA_LINK object in the linkSummary message (which is sent upon detection
of the neighbor) gives the association between "Local_Interface_Id" and
"Remote_Interface_Id".

> This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> verification mechanism in advance.

I'm not discussing verification but initial discovery.
If we could align on the used procedure for this initial discovery,
the neighboring NEs don't have to negotiate the mechanism :-)

> You could certainly create an LMP control channel through a DCN network. In
> fact, this is probably the preferred configuration.
> 
> > Is implementation of the LMP's 'control channel management' mandatory ?
> yes, however you can choose not to run the Hellos by setting the
> HelloInterval and HelloDeadInterval equal to zero.

I don't understand why the normal network-layer mechanisms (defined in e.g.
OSPF or I-ISIS) are not sufficient ?
Why do we need the LMP specific 'Config' 'ConfigAck' and 'ConfigNack'
messages ?

Thanks !

Michiel

Jonathan Lang wrote:
> 
> Michiel,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Michiel van Everdingen [mailto:[email-masked]]
> > Sent: Tuesday, April 09, 2002 12:41 AM
> > To: [email-masked]
> > Subject: LMP & neighbor discovery
> >
> >
> > Hello all,
> >
> > I found the concept of neighbor discovery mentioned several times in
> > previous discussions on this list. However, I did not find a final
> > conclusion on how this neighbor discovery is done. Correct ?
> >
> > Could you please check my understanding below ?
> >
> > In my mind, reading the incoming 'access point identifier' [ITU-G.707]
> > and subsequent LMP 'link property correlation' form a perfect fit. By
> > simply encoding the sending node's IP address and local access point
> > number in the access point identifier (see e.g. [OIF.2000.159.01]), the
> > receiver can discover the data link (linkConnection in ITU  terminology).
> > Subsequent 'link property correlation' could then a.o. check on bi-
> > directional fibering, matching data link properties and grouping of data
> > links into TE links.
> >
> > Example: the following figure shows 4 network elements of which 2
> terminate
> > the data link (TTPs, T) and two are transparent to the data link (CTPs,
> C).
> > E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
> transparent
> > optical cross connects. The data link in this example is STM-N/OC-N.
> >
> > +------+      +------+      +------+      +------+
> > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > |      |   A  |      |   B  |      |   C  |      |
> > |      |      |      |      |      |      |      |
> > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > +------+      +------+      +------+      +------+
> >
> > NE-2 should, when it wants to discover data link B, connect a test-set
> that
> > sends an access point identifier to identify the sending connection point
> C
> > in NE-2. This test-signal should be send long enough for NE-3 to detect
> and
> > read the test-signal (a fixed, agreed upon timer is needed). NE-3 will
> > continuously scan all its not discovered input ports for a discovery
> signal.
> > At some point, it will detect the test-signal on data link B.
> This is what the Link Verification procedure provides. As part of the
> BeginVerify message exchange, certain Test parameters (such as
> Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
> exchanged.
> 
> >
> > +------+      +------+      +------+      +------+
> > |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> > |      |   A  |   /  |   B  |  \   |   C  |      |
> > |      |      |  T   |      |   T  |      |      |
> > | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> > +------+      +------+      +------+      +------+
> >
> > When NE-3 has read the access point identifier in the test signal, data
> > link B is discovered. Subsequent link property correlation can then be
> > invoked.
> As part of this discovery, NE-3 sends an acknowledgment message carrying the
> local (near-end) identity of link B.
> 
> >
> > Discovery of data link A is similar, except that the access point
> identifier
> > is continuously sent. Discovery of data link C is also similar, except
> that
> > the access point identifier is continuously monitored. In other words,
> there
> > is no need for a sending respectively monitoring 'test-set' in NE-1 and
> NE-4.
> This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> verification mechanism in advance.
> 
> >
> > Data link type          Access point identifier to be used
> > --------------          ----------------------------------
> > STM-N, OC-N                            J0
> > STS-1/3/.../VC-3/4/...                 J1
> > VT-1.5/VC-11/12                        J2
> >
> >
> > Notes:
> > - I understand that LMP's link verification procedure is more efficient
> for
> >   *already discovered* data links. It does not need the continuous
> scanning
> >   on received access point identifiers in undiscovered CTPs (in the
> example:
> >   in NE-3).
> > - Discovering the address of the sending access point might also go via a
> 'name
> >   server'. This can, for example, be useful in case the address of this
> access
> >   point can not be encoded in the limited length of the access point
> identifier.
> >
> > B.t.w., could you please explain why the linkSummary and linkSummaryAck
> messages
> > have to go over a point-to-point control channel ?
> All LMP messages are sent over the LMP control channel; the health of which
> is monitored using LMP Hello messages.
> 
> > Is it also possible to
> > use the generic DCN network (MCN/SCN, can be IP-based, see ITU-G.7712) ?
> > In the latter case, we could simply use the normal UDP service of that
> network
> > to transport the linkSummary and linkSummaryAck messages ?
> You could certainly create an LMP control channel through a DCN network. In
> fact, this is probably the preferred configuration.
> 
> > Is implementation of the LMP's 'control channel management' mandatory ?
> yes, however you can choose not to run the Hellos by setting the
> HelloInterval and HelloDeadInterval equal to zero.
> 
> >
> >
> > Thanks !
> >
> > Michiel
> >
> > --
> > +------------------------------------------------------------------+
> > | Michiel van Everdingen                                           |
> > | Systems Engineer                                                 |
> > | Lucent Technologies - Optical Networking Group                   |
> > | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> > | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> > | Huizen, The Netherlands        mailto:[email-masked]  |
> > +------------------------------------------------------------------+
> >

Delivery-date: Thu, 11 Apr 2002 07:02:33 -0700
Date: Thu, 11 Apr 2002 19:32:07 +0530
From: Manoj Sontakke <[email-masked]>
Organization: Sasken Communication Technologies Ltd.
To: [email-masked]
Subject: Question on LMP.

Hi,

I have two questions on LMP.

-------------------------------------------------------------------------------------------
Q1.  Control Channel Question

Assuming a configuration as shown.

                -----------------               -----------------
                |               |               |               |
                |            if1|---------------|if1            |
                |            if2|---------------|if2            |
                |     OXC 1     |               |     OXC 2     |
                |             d1|---------------|d1             |
                |             d2|---------------|d2             |
                -----------------               -----------------       

I have two OXCs connected by four links. Consider d1, d2 are configured
to carry data and 
if1 and if2 are configured to carry control data ( LMP messages and RSVP
and OSPF messages).

The LMP document defines control channels with an unique identifier (
control channel identifier ) between the negibouring nodes. So also, the
LMP messages are IP encapsulated.

Now, I have a couple of questions

1. Is there any association between the LMP control channels to the
physical interfaces( if1, if2). Because all the IP packets are routed on
the physical interfaces according to the routing table. The control
channel messages like  ( config and configAck etc.. ) can go on the any
physical interface which is decided by the routing table.

In such case, are the control channels a pure logical concept or do they
have any physical interface significance & correlation [ mapping between
control channles ( ccid ) and interfaces ( if1 and if2 )] ?

-------------------------------------------------------------------------------------------
Q2. MessageId question

In the LMP document, the config Message & config ack messages are
defined as 

        <configMessage> ::= <common header> <LOCAL_CCID> <MESSGAE_ID>
<LOCAL_NODE_ID> 			    <CONFIG>
        
        <configAckMessage> ::= <common header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID> 				<MESSAGE_ID_ACK> <REMOTE_NODE_ID>

Assume the following sequence.

                                   ConfigMessage        
                OXC1    ---------------------------------->     OXC2

                                   ConfigMessage        
                OXC1    ---------------------------------->     OXC2

                                   ConfigMessage        
                OXC1    ---------------------------------->     OXC2

                                  ConfigAckMessage      
                OXC1    <----------------------------------     OXC2

On the OXC1 when the configAck Message is received then the OXC1 can
come to know that the config Message has been received by the OXC2 and
it can identify that it received the ack for a LOCAL_CCID. Any configAck
recevied will result in bringing that control channel UP.

So how does the <MESSAGE_ID> and <MESSAGE_ID_ACK> helps improve the
message realiability ?

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

Any comments in this regard will be appreciated.

Thanks,
Manoj

Delivery-date: Thu, 11 Apr 2002 06:19:37 -0700
To: Alex Zinin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt 
Date: Thu, 11 Apr 2002 06:14:05 -0700
From: Yakov Rekhter <[email-masked]>

Alex,

> Kireeti, et al:
> 
> Please find my comments on the draft below.
> I'm also CC'ing the OSPF WG to make sure we
> have a good coverage here.

see my response in-line...

> Cheers!
> 
> Alex
> 
> > CCAMP Working Group                       K. Kompella (Juniper Networks)
> > Internet Draft                            Y. Rekhter  (Juniper Networks)
> > Expiration Date: October 2002             A. Banerjee (Calient Networks)
> >                                           J. Drake    (Calient Networks)
> >                                           G. Bernstein (Ciena)
> >                                           D. Fedyk    (Nortel Networks)
> >                                           E. Mannie   (GTS Network)
> >                                           D. Saha     (Tellium)
> >                                           V. Sharma   (Metanoia, Inc.)
> 
> I would consult your ADs about the length of the author list.
> 
> IMHO, it's kind of hard to imagine 9 people editing
> a draft containing 7 pages of useful info ;))
> 
> > 
> >              OSPF Extensions in Support of Generalized MPLS
> > 
> >              draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
> > 
> > 
> [...]
> 
> >
> > 2. Abstract
> > 
> >    This document specifies encoding of extensions to the OSPF routing
> >    protocol in support of Generalized Multi-Protocol Label Switching
> >    (GMPLS).  The description of the extensions is specified in [GMPLS-
> >    ROUTING].
> 
> The rfc-ed will request the citation to be removed from the abstract.

I'll fix this in the next version of the draft.

> 
> >
> > 4. Introduction
> > 
> >    This document specifies extensions to the OSPF routing protocol in
> >    support of carrying link state information for Generalized Multi-
> >    Protocol Label Switching (GMPLS). The set of required enhancements to
> >    OSPF are outlined in [GMPLS-ROUTING].
> 
> It might be a good idea to explicitly mention that only
> intra-area issues are covered here.

That is not exactly correct, as the extensions defined in this
document could certainly be used for establishing LSPs that span
multiple area. An example of how this could be accomplished can
be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt.

> > 5. OSPF Routing Enhancements
> > 
> >    In this section we define the enhancements to the TE properties of
> >    GMPLS TE links that can be announced in OSPF TE LSAs.  The Traffic
> >    Engineering (TE) LSA, which is an opaque LSA with area flooding scope
> >    [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and
> >    has one or more nested sub-TLVs for extensibility. The top-level TLV
> >    can take one of two values (1) Router Address or (2) Link. In this
> >    document, we enhance the sub-TLVs for the Link TLV in support of
> >    GMPLS. Specifically, we add the following sub-TLVs to the Link TLV:
> > 
> >       1. Link Local Identifier,
> >       2. Link Remote Identifier,
> >       3. Link Protection Type,
> >       4. Interface Switching Capability Descriptor, and
> >       5. Shared Risk Link Group.
> 
> Minor: given the table below, do we need the above list really?

Ok. I'll remove the list.

> >    The following defines the Type and Length of these sub-TLVs:
> > 
> >       Sub-TLV Type      Length    Name
> >                 11           4    Link Local Identifier
> >                 12           4    Link Remote Identifier
> >                 14           4    Link Protection Type
> >                 15    variable    Interface Switching Capability Descriptor
> >                 16    variable    Shared Risk Link Group
> > 
> 
> [OSPF-TE] says:
> 
>    The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
>    exactly once.  All other sub-TLVs defined here may occur at most
>    once.  These restrictions need not apply to future sub-TLVs.
>    Unrecognized sub-TLVs are ignored.
> 
> Considering the last two sentences, it would be really nice if
> this document said something about this.
> 
> You might also say something about processing of sub-TLVs
> with unexpected length.

Could you please suggest the text.

> > 5.1. Link Local Identifier
> > 
> >    A  Link Local Identifier is a sub-TLV of the Link TLV with type 11,
> >    and length 4.
> 
> What do I put in it?

Link Local Identifier. For more information consult Section 6.1
of draft-ietf-ccamp-gmpls-routing-03.txt.

> 
> > 5.2. Link Remote Identifier
> > 
> >    A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
> >    and length 4.
> > 
> 
> Ditto

Link Remote Identifier. For more information consult Section 6.1
of draft-ietf-ccamp-gmpls-routing-03.txt.
  
> >
> > 5.3. Link Protection Type
> > 
> >    The Link Protection Type is a sub-TLV of the Link TLV, with type 14,
> >    and length of four octets, the first of which is a bit vector
> >    describing the protection capabilities of the link. They are:
> 
> Might be a good idea to include an IETF-style format illustration
> here, to make sure everyone understands "first octet" the same
> way.

I'll do this in the next version of the draft.

> 
> Something should also be said about other octets. 

Ditto.

> Are they reserved and ignored on receipt?

Should be set to zero by the sender and should be ignored on receipt.

> > 
> >       0x01  Extra Traffic
> > 
> >       0x02  Unprotected
> > 
>       0x04  Shared
> > 
> >       0x08  Dedicated 1:1
> > 
> >       0x10  Dedicated 1+1
> > 
> >       0x20  Enhanced
> > 
> >       0x40  Reserved
> > 
> >       0x80  Reserved
> > 
> 
> I believe these are described in [GMPLS-ROUTING]. You may want
> to add a reference to it here.

Will do in the next version of the draft.

> 
> > 5.4. Shared Risk Link Group (SRLG)
> > 
> >    The SRLG is a sub-TLV of the Link TLV with type 16. The length is the
> >    length of the list in octets. The value is an unordered list of 32
> >    bit numbers that are the SRLGs that the link belongs to. The format
> >    of the value field is as shown below:
> 
> ditto

ditto.

> ...
> 
> > 5.5. Interface Switching Capability Descriptor
> > 
> >    The Interface Switching Capability Descriptor is a sub-TLV of the
> >    Link TLV with type 15. The length is the length of value field in
> 
> Minor: might want to change wording, not clear what "with type 15" is
> relative to, one may ready "Link TLV with type 15".

ditto.

> 
> >    octets. The format of the value field is as shown below:
> > 
> ...
> >
> >    When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
> >    the specific information includes Interface MTU, Minimum LSP
> >    Bandwidth, and padding. The Interface MTU is encoded as a 2 octets
> >    integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field
> >    in the IEEE floating point format. The units are bytes (not bits!)
> >    per second. The padding is 2 octets, and is used to make the
> >    Interface Switching Capability Descriptor sub-TLV 32-bits aligned.
> 
> Would be just great to have a field format illustration here.

ditto.

> 
> > 
> >    When the Switching Capability field is L2SC, there is no specific
> >    information.
> 
> So, the field is not included? Please specify.

Yes, there is no Switching Capability specific information field.
I'll clarify this in the next version of the draft.

> >    When the Switching Capability field is TDM, the specific information
> >    includes Minimum LSP Bandwidth, an indication whether the interface
> >    supports Standard or Arbitrary SONET/SDH, and padding. The Minimum
> >    LSP Bandwidth is encoded in a 4 octets field in the IEEE floating
> >    point format. The units are bytes (not bits!) per second. The
> >    indication whether the interface supports Standard or Arbitrary
> >    SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the
> >    interface supports Standard SONET/SDH, and 1 if the interface
> >    supports Arbitrary SONET/SDH.  The padding is 3 octets, and is used
> >    to make the Interface Switching Capability Descriptor sub-TLV 32-bits
> >    aligned.
> 
> Again, would appreciate a format illustration here. Breaking field
> description into a list here and above would be nice as well.

Will add to the next version of the draft.

> >    When the Switching Capability field is LSC, there is no specific
> >    information.
> 
> "... and the <blah> field is not included."
> > 
> >    The Interface Switching Capability Descriptor sub-TLV may occur more
> >    than once within the Link TLV.
> 
> "...to indicate multiple switching capabilities supported by the link.
> The resulting set of capabilities includes all those announced in
> multiple instances of the sub-TLV" or something like this?

Ditto.

> 
> > 6. Implications on Graceful Restart
> > 
> >    The restarting node should follow the OSPF restart procedures [OSPF-
> >    RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].
> 
> These look like normative references and hence it means that the
> document will be delayed until those are complete. Just a heads-up :)

Do you think it would be better to put TE Graceful Restart into
a separate Internet Draft ?

> >    When a restarting node is going to originate its TE LSAs, the TE LSAs
> >    containing Link TLV should be originated with 0 unreserved bandwidth,
> >    and if the Link has LSC or FSC as its Switching Capability then also
> >    with 0 as Max LSP Bandwidth, until the node is able to determine the
> >    amount of unreserved resources taking into account the resources
> >    reserved by the already established LSPs that have been preserved
> >    across the restart. Once the restarting node determines the amount of
> >    unreserved resources, taking into account the resources reserved by
> >    the already established LSPs that have been preserved across the
> >    restart, the node should advertise these resources in its TE LSAs.
> > 
> >    In addition in the case of a planned restart prior to restarting, the
> >    restarting node SHOULD originate the TE LSAs containing Link TLV with
> >    0 as unreserved bandwidth, and if the Link has LSC or FSC as its
> >    Switching Capability then also with 0 as Max LSP Bandwidth.
> 
> "...to discourage new LSP establishment through the restarting router"?

Will add to the next version of the draft.

> >    Neighbors of the restarting node should continue advertise the actual
> >    unreserved bandwidth on the TE links from the neighbors to that node.
> > 
> >    Regular graceful restart should not be aborted if a TE LSA or TE
> >    topology changes. TE graceful restart need not be aborted if a TE LSA
> >    or TE topology changes.
> > 
> > 
> > 7. Security Considerations
> > 
> >    The sub-TLVs proposed in this document does not raise any new
> >    security concerns.
> 
> "do not raise"

Will fix in the next version of the draft.

> >
> > 9. References
> 
> Might be a good idea to split these to normative and
> informative or specify the type if all of them are the same
> type.

Ditto.

Yakov.

Delivery-date: Wed, 10 Apr 2002 19:05:23 -0700
From: Jonathan Lang <[email-masked]>
To: 'Michiel van Everdingen' <[email-masked]>,  [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Wed, 10 Apr 2002 18:56:45 -0700

Michiel,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Michiel van Everdingen [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 12:41 AM
> To: [email-masked]
> Subject: LMP & neighbor discovery
> 
> 
> Hello all,
> 
> I found the concept of neighbor discovery mentioned several times in
> previous discussions on this list. However, I did not find a final
> conclusion on how this neighbor discovery is done. Correct ?
> 
> Could you please check my understanding below ?
> 
> In my mind, reading the incoming 'access point identifier' [ITU-G.707]
> and subsequent LMP 'link property correlation' form a perfect fit. By
> simply encoding the sending node's IP address and local access point
> number in the access point identifier (see e.g. [OIF.2000.159.01]), the
> receiver can discover the data link (linkConnection in ITU  terminology).
> Subsequent 'link property correlation' could then a.o. check on bi-
> directional fibering, matching data link properties and grouping of data
> links into TE links.
> 
> Example: the following figure shows 4 network elements of which 2
terminate
> the data link (TTPs, T) and two are transparent to the data link (CTPs,
C).
> E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
transparent
> optical cross connects. The data link in this example is STM-N/OC-N.
> 
> +------+      +------+      +------+      +------+
> |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> |      |   A  |      |   B  |      |   C  |      |
> |      |      |      |      |      |      |      |
> | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> +------+      +------+      +------+      +------+
> 
> NE-2 should, when it wants to discover data link B, connect a test-set
that
> sends an access point identifier to identify the sending connection point
C
> in NE-2. This test-signal should be send long enough for NE-3 to detect
and
> read the test-signal (a fixed, agreed upon timer is needed). NE-3 will
> continuously scan all its not discovered input ports for a discovery
signal.
> At some point, it will detect the test-signal on data link B.
This is what the Link Verification procedure provides. As part of the
BeginVerify message exchange, certain Test parameters (such as
Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
exchanged.

> 
> +------+      +------+      +------+      +------+
> |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> |      |   A  |   /  |   B  |  \   |   C  |      |
> |      |      |  T   |      |   T  |      |      |
> | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> +------+      +------+      +------+      +------+
> 
> When NE-3 has read the access point identifier in the test signal, data
> link B is discovered. Subsequent link property correlation can then be
> invoked.
As part of this discovery, NE-3 sends an acknowledgment message carrying the
local (near-end) identity of link B.

> 
> Discovery of data link A is similar, except that the access point
identifier
> is continuously sent. Discovery of data link C is also similar, except
that
> the access point identifier is continuously monitored. In other words,
there
> is no need for a sending respectively monitoring 'test-set' in NE-1 and
NE-4.
This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
verification mechanism in advance.

> 
> Data link type          Access point identifier to be used
> --------------          ----------------------------------
> STM-N, OC-N                            J0
> STS-1/3/.../VC-3/4/...                 J1
> VT-1.5/VC-11/12                        J2
> 
> 
> Notes:
> - I understand that LMP's link verification procedure is more efficient
for
>   *already discovered* data links. It does not need the continuous
scanning
>   on received access point identifiers in undiscovered CTPs (in the
example:
>   in NE-3).
> - Discovering the address of the sending access point might also go via a
'name
>   server'. This can, for example, be useful in case the address of this
access
>   point can not be encoded in the limited length of the access point
identifier.
> 
> B.t.w., could you please explain why the linkSummary and linkSummaryAck
messages
> have to go over a point-to-point control channel ? 
All LMP messages are sent over the LMP control channel; the health of which
is monitored using LMP Hello messages.

> Is it also possible to
> use the generic DCN network (MCN/SCN, can be IP-based, see ITU-G.7712) ?
> In the latter case, we could simply use the normal UDP service of that
network
> to transport the linkSummary and linkSummaryAck messages ?
You could certainly create an LMP control channel through a DCN network. In
fact, this is probably the preferred configuration.

> Is implementation of the LMP's 'control channel management' mandatory ?
yes, however you can choose not to run the Hellos by setting the
HelloInterval and HelloDeadInterval equal to zero.

> 
> 
> Thanks !
> 
> Michiel
> 
> -- 
> +------------------------------------------------------------------+
> | Michiel van Everdingen                                           |
> | Systems Engineer                                                 |
> | Lucent Technologies - Optical Networking Group                   |
> | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> | Huizen, The Netherlands        mailto:[email-masked]  |
> +------------------------------------------------------------------+
> 

Delivery-date: Wed, 10 Apr 2002 17:55:55 -0700
From: "Ong, Lyndon" <[email-masked]>
To: "'Suresh Katukam'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: [email-masked]
Subject: RE: Question on Restart Procedure - Restart Time
Date: Wed, 10 Apr 2002 17:55:13 -0700

Hi Suresh,

This was a source of confusion back in December, at one
point it looked like an "infinite" value was going to be
defined for Restart Time rather than Recovery Time.

Apparently this was not done, can someone recall what the
resolution was?  I'd check the archive but this seems to
be down at the moment...

Cheers,

Lyndon 

-----Original Message-----
From: Suresh Katukam [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 5:25 PM
To: Zhi-Wei Lin
Cc: [email-masked]
Subject: Re: Question on Restart Procedure - Restart Time

Zhi,

This only allows the local node to wait for longer. If I want the other 
node to wait
forever, ( I do not want to depend on the other node's local policy ), I 
should be
able to indicate to the other node that - Please wait forever or Until Hello
established and Recovery timer expires.

Thanks,
Suresh

At 07:20 PM 4/10/2002 -0400, Zhi-Wei Lin wrote:
>Hi Suresh,
>
>In the GMPLS RSVP-TE document, Section 9.3, first paragraph, last sentence:
>
>A node MAY wait longer based on local policy or configuration information.
>
>Is this what you are looking for?
>
>Zhi
>
>
>Suresh Katukam wrote:
>
>>
>>>Ping and others,
>>>
>>>Is it possible to define an infinite value for Restart time so that one 
>>>may not
>>>have to remove circuits as soon as Restart timer expires? This is more
valid
>>>in SONET/SDH cases where a control channel may be down for a long enough
>>>time that is difficult to guess it up front..
>>>
>>>In SONET/SDH cases, nodes should delete circuits in these conditions
>>>
>>>- explicitly removed by customer
>>>- Recovery Timer expires
>>>
>>>other conditions ( restart timer expires, soft-state time out ) should 
>>>be given
>>>optional. there should be values or procedures defined in these other
cases
>>>such that the node does not remove LSPs.
>>>
>>>Thanks,
>>>Suresh
>>
>>
>

Delivery-date: Wed, 10 Apr 2002 17:25:44 -0700
From: "Soo-Hyun Choi" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>, "Sudheer Dharanikota" <[email-masked]>
Cc: "Diego Caviglia" <[email-masked]>, <[email-masked]>, "Gino Carrozzo <g.carrozzo" <[email-masked]>, "ccamp <ccamp" <[email-masked]>, "<braja" <[email-masked]>, <[email-masked]>
Subject: Re: UNI end-to-end sessions
Date: Thu, 11 Apr 2002 09:24:38 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0080_01C1E13A.B42B3D90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

As you might know, the NNI interoperability test at the Supercomm 2002 has
been cancelled.
But, you can still refer to the document (oif2002.025) _just_ for your
reference.
(It's under heavy discussion among the principal members in the OIF.)

Soo-Hyun
  ----- Original Message -----
  From: Zhi-Wei Lin
  To: Sudheer Dharanikota
  Cc: Diego Caviglia ; [email-masked] ; Gino Carrozzo <g.carrozzo ; ccamp
<ccamp ; <braja ; [email-masked]
  Sent: Thursday, April 11, 2002 5:34 AM
  Subject: Re: UNI end-to-end sessions

  Hi Sudheer, all,

  I think the work is actually part of the Supercomm NNI work effort
  (there is no private NNI effort within OIF). For folks involved with OIF
  and Supercomm NNI, see OIF2002.025, Section 7.4, which clearly includes
  the facility to transport UNI-specific information (such as TNA) from
  source UNI to destination UNI.

  This is not part of the IETF GMPLS documents yet. I view the GMPLS work
  in IETF as laying a foundation for using IP-based protocols. For
  example, the OIF and ITU-T may use these protocols to extend the
  capability to support UNI-based, and E-NNI-based signaling and routing.
  In fact this is exactly what was done for the UNI.

  Zhi

  FYI, I've also added [email-masked] to the cc: list

  Sudheer Dharanikota wrote:

  >There has been some effort in proposing a TLV to carry some of the
  >UNI specific parameters into NNI cloud. This was part of Private NNI
  >at OIF. Once we sort requirements out at OIF on NNI and UNI 2.0 front,
  >we can go to the details of this TLV.
  >
  >- sudheer
  >
  >Diego Caviglia wrote:
  >
  >>Hi Monica,
  >>                        I agree with you that there isn't a UNI
end-to-end
  >>session, but in my understanding what Gino was asking is how to map UNI
  >>information that has end-to-end significance.
  >>
  >>In fact it is written in the UNI doc (table 12-5) that there are some
UNI
  >>objects that have end-to-end significance. For example Source and
  >>Destination TNA addresses have end-to-end significance.   This doesn't
  >>mean, as you pointed out, that there is an UNI session between two UNI.
  >>
  >> Anyway the question is (this is my interpretation of Gino's message so
  >>please, Gino, correct me if I'm wrong) how can I transport/map the UNI
  >>end-to-end significative information between the two UNIs?
  >>
  >>AFAIK there is no room in GMPLS extended LDP and RSVP for this purpose.
  >>
  >>Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
  >>LDP/RSVP?
  >>
  >>Regards, Diego.
  >>
  >>----------------------------------------------------------------
  >>Diego Caviglia
  >>Optical Network - ASON strategy
  >>E-mail: [email-masked]
  >>Tel: +39 0 10 6003 808
  >>Via A. Negrone 1A 16153 Genoa (Italy)
  >>http://www.marconi.com
  >>
  >>"Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
  >>04.41.05
  >>
  >>Sent by:  [email-masked]
  >>
  >>To:   "Gino Carrozzo" <[email-masked]>, "ccamp" <[email-masked]>
  >>cc:   <[email-masked]>
  >>
  >>Subject:  RE: UNI end-to-end sessions
  >>
  >>All,
  >>I want to correct some mis-representations - There is no end-to-end UNI
  >>session. A UNI session is between a user and the network. There is a
  >>separate UNI session at the other edge of the network, between the other
  >>client and the network. Further more, it should not be assumed that the
  >>same protocol must run over the 2 separate UNIs.
  >>
  >>Monica A. Lazer
  >>Advanced Transport Technology and Architecture Planning
  >>
  >>908 234 8462
  >>[email-masked]
  >>
  >>-----Original Message-----
  >>From: Gino Carrozzo [mailto:[email-masked]]
  >>Sent: Tuesday, April 09, 2002 5:45 AM
  >>To: ccamp
  >>Cc: [email-masked]
  >>Subject: UNI end-to-end sessions
  >>
  >>All,
  >>
  >>when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src
&
  >>dest. UNI clients),
  >>I didn't found any reference in how to "transfer" UNI  end-to-end info
from
  >>the source client side (source UNI-C <--> UNI-N on source TNE) to the
  >>destination client side (UNI-N on dest. TNE <-->dest UNI-C).
  >>In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N
side
  >>is considered.
  >>
  >>How the two UNI-N can exchange UNI infos in the transport network?
  >>Is there any action in this WG (or in IETF) to fix this problem?
  >>
  >>Thanks
  >>
  >>Gino
  >>
  >
  >

------=_NextPart_000_0080_01C1E13A.B42B3D90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi, </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>As you might know, the NNI interoperability test at =
the=20
Supercomm 2002 has been cancelled.</FONT></DIV>
<DIV><FONT size=3D2>But, you can still&nbsp;refer to&nbsp;the document=20
(oif2002.025) _just_ for&nbsp;your reference.</FONT></DIV>
<DIV><FONT size=3D2>(It's&nbsp;under heavy discussion among the =
principal=20
members&nbsp;in the OIF.)</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Soo-Hyun</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#44404;&#47548;">----- Original Message =
----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt &#44404;&#47548;; font-color: =
black"><B>From:</B> <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Zhi-Wei =
Lin</A> </DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Sudheer Dharanikota</A> </DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Diego Caviglia</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Gino =
Carrozzo=20
  &lt;g.carrozzo</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">ccamp &lt;ccamp</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">&lt;braja</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Sent:</B> Thursday, =
April 11, 2002 5:34 AM</DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Subject:</B> Re: UNI =
end-to-end sessions</DIV>
  <DIV><BR></DIV>Hi Sudheer, all,<BR><BR>I think the work is actually =
part of=20
  the Supercomm NNI work effort <BR>(there is no private NNI effort =
within OIF).=20
  For folks involved with OIF <BR>and Supercomm NNI, see OIF2002.025, =
Section=20
  7.4, which clearly includes <BR>the facility to transport UNI-specific =

  information (such as TNA) from <BR>source UNI to destination =
UNI.<BR><BR>This=20
  is not part of the IETF GMPLS documents yet. I view the GMPLS work =
<BR>in IETF=20
  as laying a foundation for using IP-based protocols. For <BR>example, =
the OIF=20
  and ITU-T may use these protocols to extend the <BR>capability to =
support=20
  UNI-based, and E-NNI-based signaling and routing. <BR>In fact this is =
exactly=20
  what was done for the UNI.<BR><BR>Zhi<BR><BR>FYI, I've also added <A=20
  href=3D"mailto:[email-masked]">[email-masked]</A> to =
the cc:=20
  list<BR><BR><BR><BR>Sudheer Dharanikota wrote:<BR><BR>&gt;There has =
been some=20
  effort in proposing a TLV to carry some of the<BR>&gt;UNI specific =
parameters=20
  into NNI cloud. This was part of Private NNI<BR>&gt;at OIF. Once we =
sort=20
  requirements out at OIF on NNI and UNI 2.0 front,<BR>&gt;we can go to =
the=20
  details of this TLV.<BR>&gt;<BR>&gt;- sudheer<BR>&gt;<BR>&gt;Diego =
Caviglia=20
  wrote:<BR>&gt;<BR>&gt;&gt;Hi=20
  =
Monica,<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
  I agree with you that there isn't a UNI end-to-end<BR>&gt;&gt;session, =
but in=20
  my understanding what Gino was asking is how to map =
UNI<BR>&gt;&gt;information=20
  that has end-to-end significance.<BR>&gt;&gt;<BR>&gt;&gt;In fact it is =
written=20
  in the UNI doc (table 12-5) that there are some UNI<BR>&gt;&gt;objects =
that=20
  have end-to-end significance. For example Source =
and<BR>&gt;&gt;Destination=20
  TNA addresses have end-to-end significance.&nbsp;&nbsp; This=20
  doesn't<BR>&gt;&gt;mean, as you pointed out, that there is an UNI =
session=20
  between two UNI.<BR>&gt;&gt;<BR>&gt;&gt; Anyway the question is (this =
is my=20
  interpretation of Gino's message so<BR>&gt;&gt;please, Gino, correct =
me if I'm=20
  wrong) how can I transport/map the UNI<BR>&gt;&gt;end-to-end =
significative=20
  information between the two UNIs?<BR>&gt;&gt;<BR>&gt;&gt;AFAIK there =
is no=20
  room in GMPLS extended LDP and RSVP for this=20
  purpose.<BR>&gt;&gt;<BR>&gt;&gt;Are there any efforts in IETF to =
harmonize OIF=20
  UNI and GMPLS =
extended<BR>&gt;&gt;LDP/RSVP?<BR>&gt;&gt;<BR>&gt;&gt;Regards,=20
  =
Diego.<BR>&gt;&gt;<BR>&gt;&gt;-------------------------------------------=
---------------------<BR>&gt;&gt;Diego=20
  Caviglia<BR>&gt;&gt;Optical Network - ASON strategy<BR>&gt;&gt;E-mail: =
<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>=
<BR>&gt;&gt;Tel:=20
  +39 0 10 6003 808<BR>&gt;&gt;Via A. Negrone 1A 16153 Genoa=20
  =
(Italy)<BR>&gt;&gt;http://www.marconi.com<BR>&gt;&gt;<BR>&gt;&gt;"Lazer, =

  Monica A, ALCNS" &lt;<A=20
  =
href=3D"mailto:[email-masked]>@ops.ietf.org">[email-masked]&gt;@ops.ietf.=
org</A>=20
  on 10/04/2002<BR>&gt;&gt;04.41.05<BR>&gt;&gt;<BR>&gt;&gt;Sent =
by:&nbsp; <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
&gt;&gt;<BR>&gt;&gt;To:&nbsp;&nbsp;=20
  "Gino Carrozzo" &lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, "ccamp" =
&lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>&gt;&gt;=
cc:&nbsp;&nbsp;=20
  &lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>&gt;&gt;<B=
R>&gt;&gt;Subject:&nbsp;=20
  RE: UNI end-to-end sessions<BR>&gt;&gt;<BR>&gt;&gt;All,<BR>&gt;&gt;I =
want to=20
  correct some mis-representations - There is no end-to-end=20
  UNI<BR>&gt;&gt;session. A UNI session is between a user and the =
network. There=20
  is a<BR>&gt;&gt;separate UNI session at the other edge of the network, =
between=20
  the other<BR>&gt;&gt;client and the network. Further more, it should =
not be=20
  assumed that the<BR>&gt;&gt;same protocol must run over the 2 separate =

  UNIs.<BR>&gt;&gt;<BR>&gt;&gt;Monica A. Lazer<BR>&gt;&gt;Advanced =
Transport=20
  Technology and Architecture Planning<BR>&gt;&gt;<BR>&gt;&gt;908 234=20
  8462<BR>&gt;&gt;[email-masked]<BR>&gt;&gt;<BR>&gt;&gt;-----Original=20
  Message-----<BR>&gt;&gt;From: Gino Carrozzo=20
  [mailto:[email-masked]]<BR>&gt;&gt;Sent: Tuesday, April 09, 2002 =
5:45=20
  AM<BR>&gt;&gt;To: ccamp<BR>&gt;&gt;Cc: <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;Subjec=
t: UNI=20
  end-to-end =
sessions<BR>&gt;&gt;<BR>&gt;&gt;All,<BR>&gt;&gt;<BR>&gt;&gt;when=20
  establishing an end-to-end UNI-RSVP session between two UNI-Cs (src=20
  &amp;<BR>&gt;&gt;dest. UNI clients),<BR>&gt;&gt;I didn't found any =
reference=20
  in how to "transfer" UNI&nbsp; end-to-end info from<BR>&gt;&gt;the =
source=20
  client side (source UNI-C &lt;--&gt; UNI-N on source TNE) to=20
  the<BR>&gt;&gt;destination client side (UNI-N on dest. TNE =
&lt;--&gt;dest=20
  UNI-C).<BR>&gt;&gt;In draft-bala-uni-signaling-extensions-00.txt, only =
the=20
  UNI-C / UNI-N side<BR>&gt;&gt;is =
considered.<BR>&gt;&gt;<BR>&gt;&gt;How the=20
  two UNI-N can exchange UNI infos in the transport =
network?<BR>&gt;&gt;Is there=20
  any action in this WG (or in IETF) to fix this=20
  =
problem?<BR>&gt;&gt;<BR>&gt;&gt;Thanks<BR>&gt;&gt;<BR>&gt;&gt;Gino<BR>&gt=
;&gt;<BR>&gt;<BR>&gt;<BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0080_01C1E13A.B42B3D90--

Delivery-date: Wed, 10 Apr 2002 17:25:41 -0700
Date: Wed, 10 Apr 2002 17:24:46 -0700
To: Zhi-Wei Lin <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: Re: Question on Restart Procedure - Restart Time
Cc: [email-masked]

Zhi,

This only allows the local node to wait for longer. If I want the other 
node to wait
forever, ( I do not want to depend on the other node's local policy ), I 
should be
able to indicate to the other node that - Please wait forever or Until Hello
established and Recovery timer expires.

Thanks,
Suresh

At 07:20 PM 4/10/2002 -0400, Zhi-Wei Lin wrote:
>Hi Suresh,
>
>In the GMPLS RSVP-TE document, Section 9.3, first paragraph, last sentence:
>
>A node MAY wait longer based on local policy or configuration information.
>
>Is this what you are looking for?
>
>Zhi
>
>
>Suresh Katukam wrote:
>
>>
>>>Ping and others,
>>>
>>>Is it possible to define an infinite value for Restart time so that one 
>>>may not
>>>have to remove circuits as soon as Restart timer expires? This is more valid
>>>in SONET/SDH cases where a control channel may be down for a long enough
>>>time that is difficult to guess it up front..
>>>
>>>In SONET/SDH cases, nodes should delete circuits in these conditions
>>>
>>>- explicitly removed by customer
>>>- Recovery Timer expires
>>>
>>>other conditions ( restart timer expires, soft-state time out ) should 
>>>be given
>>>optional. there should be values or procedures defined in these other cases
>>>such that the node does not remove LSPs.
>>>
>>>Thanks,
>>>Suresh
>>
>>
>

Delivery-date: Wed, 10 Apr 2002 16:22:23 -0700
Date: Wed, 10 Apr 2002 19:20:16 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Suresh Katukam <[email-masked]>
CC: [email-masked]
Subject: Re: Question on Restart Procedure - Restart Time

Hi Suresh,

In the GMPLS RSVP-TE document, Section 9.3, first paragraph, last sentence:

A node MAY wait longer based on local policy or configuration information.

Is this what you are looking for?

Zhi

Suresh Katukam wrote:

>
>> Ping and others,
>>
>> Is it possible to define an infinite value for Restart time so that 
>> one may not
>> have to remove circuits as soon as Restart timer expires? This is 
>> more valid
>> in SONET/SDH cases where a control channel may be down for a long enough
>> time that is difficult to guess it up front..
>>
>> In SONET/SDH cases, nodes should delete circuits in these conditions
>>
>> - explicitly removed by customer
>> - Recovery Timer expires
>>
>> other conditions ( restart timer expires, soft-state time out ) 
>> should be given
>> optional. there should be values or procedures defined in these other 
>> cases
>> such that the node does not remove LSPs.
>>
>> Thanks,
>> Suresh
>
>
>

Delivery-date: Wed, 10 Apr 2002 14:53:14 -0700
Date: Wed, 10 Apr 2002 14:51:48 -0700
To: [email-masked]
From: Suresh Katukam <[email-masked]>
Subject: Question on Restart Procedure - Restart Time

>Ping and others,
>
>Is it possible to define an infinite value for Restart time so that one 
>may not
>have to remove circuits as soon as Restart timer expires? This is more valid
>in SONET/SDH cases where a control channel may be down for a long enough
>time that is difficult to guess it up front..
>
>In SONET/SDH cases, nodes should delete circuits in these conditions
>
>- explicitly removed by customer
>- Recovery Timer expires
>
>other conditions ( restart timer expires, soft-state time out ) should be 
>given
>optional. there should be values or procedures defined in these other cases
>such that the node does not remove LSPs.
>
>Thanks,
>Suresh

Delivery-date: Wed, 10 Apr 2002 14:39:03 -0700
Date: Wed, 10 Apr 2002 14:36:15 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Diego Caviglia <[email-masked]>, [email-masked], "Gino Carrozzo <g.carrozzo" <[email-masked]>, "ccamp <ccamp" <[email-masked]>, "<braja" <[email-masked]>, [email-masked]
Subject: Re: UNI end-to-end sessions

Zhi...

Zhi-Wei Lin wrote:

> Hi Sudheer, all,
>
> I think the work is actually part of the Supercomm NNI work effort
> (there is no private NNI effort within OIF). For folks involved with OIF

Due to time constraints we did not push private NNI/ILSI work
for Supercom 2001. But this does not mean what we have done is
going to go waste. This will be part of the NNI signaling and
possibly in UNI 2.0 efforts.

>
> and Supercomm NNI, see OIF2002.025, Section 7.4, which clearly includes
> the facility to transport UNI-specific information (such as TNA) from
> source UNI to destination UNI.

Cheers,

sudheer

Delivery-date: Wed, 10 Apr 2002 14:27:47 -0700
Date: Wed, 10 Apr 2002 14:25:16 -0700
From: Sudheer Dharanikota <[email-masked]>
To: [email-masked]
CC: Suresh Katukam <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents

Hi Vishal and Suresh:

Vishal Sharma wrote:

> Sudheer,
>
> I would think that the capability of a node or link really needs to
> be part of the routing protocol, at least from a "distribution of
> information" perspective.

Sure. I agree with you. Node capability is something new to be
cosidered in path computation. This is subset of the domain
considrations we had in the SRG document.

>
>
> Of course, it would have to be used in signaling for path setup
> (depending on how path setup is initiated).

Agreed.

>
>
> Also, I think Suresh's reference in asking for additions to routing
> wasn't directed at the several proposals directed at simplifying
> path computation and restoration, such as SRG.

Agreed too. That is the reason why I responded to a part of his
message. One remark though, SRG will not reduce the overhead
of path computation - from my internal implementation experience :-)
I was only commenting to the P&R portion.

>
>
> Rather, it seems to point to some specific equipment/technology
> capabilities
> that need to be included in routing for the routing to be fully
> applicable for the SDH/SONET case.
>

We are in sync.

>
> -Vishal
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Sudheer Dharanikota
> > Sent: Tuesday, April 09, 2002 8:32 PM
> > To: Suresh Katukam
> > Cc: [email-masked]
> > Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents
> >
> >
> > Hi:
> >
> >
> > Suresh Katukam wrote:
> >
> > > These routing documents do not cover many SONET/SDH cases at all.
> > > Even though it is generic routing, SONET/SDH is included in these and
> > > do not take care of TSI (Time Slot Interchangable) issues and protection
> > > related issues.
> > >
> > > Here is the list of issues:
> > >
> > > 1. Certain links are TSI capable - and certain are not. In this
> > case, one
> > > needs to know the group of nodes that belong to this category (e.g.
> > > Ring ID for BLSR ) so that one can do path computation properly.
> >
> > Some people feel that such requirements are to be part of signaling and
> > some feel that it should be part of the routing and signaling
> > protocol. I belong
> > to the second category. As Kireeti said, in the design team this is one of
> > the issues we would like to address. There are some proposals already
> > on the table to address some of these issues...
> > draft-many-ccamp-srg-01.txt is one such draft.
> >
> > - sudheer
> >

Delivery-date: Wed, 10 Apr 2002 13:36:43 -0700
Date: Wed, 10 Apr 2002 16:34:40 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
CC: Diego Caviglia <[email-masked]>, [email-masked], "Gino Carrozzo <g.carrozzo" <[email-masked]>, "ccamp <ccamp" <[email-masked]>, "<braja" <[email-masked]>, [email-masked]
Subject: Re: UNI end-to-end sessions

Hi Sudheer, all,

I think the work is actually part of the Supercomm NNI work effort 
(there is no private NNI effort within OIF). For folks involved with OIF 
and Supercomm NNI, see OIF2002.025, Section 7.4, which clearly includes 
the facility to transport UNI-specific information (such as TNA) from 
source UNI to destination UNI.

This is not part of the IETF GMPLS documents yet. I view the GMPLS work 
in IETF as laying a foundation for using IP-based protocols. For 
example, the OIF and ITU-T may use these protocols to extend the 
capability to support UNI-based, and E-NNI-based signaling and routing. 
In fact this is exactly what was done for the UNI.

Zhi

FYI, I've also added [email-masked] to the cc: list

Sudheer Dharanikota wrote:

>There has been some effort in proposing a TLV to carry some of the
>UNI specific parameters into NNI cloud. This was part of Private NNI
>at OIF. Once we sort requirements out at OIF on NNI and UNI 2.0 front,
>we can go to the details of this TLV.
>
>- sudheer
>
>Diego Caviglia wrote:
>
>>Hi Monica,
>>                        I agree with you that there isn't a UNI end-to-end
>>session, but in my understanding what Gino was asking is how to map UNI
>>information that has end-to-end significance.
>>
>>In fact it is written in the UNI doc (table 12-5) that there are some UNI
>>objects that have end-to-end significance. For example Source and
>>Destination TNA addresses have end-to-end significance.   This doesn't
>>mean, as you pointed out, that there is an UNI session between two UNI.
>>
>> Anyway the question is (this is my interpretation of Gino's message so
>>please, Gino, correct me if I'm wrong) how can I transport/map the UNI
>>end-to-end significative information between the two UNIs?
>>
>>AFAIK there is no room in GMPLS extended LDP and RSVP for this purpose.
>>
>>Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
>>LDP/RSVP?
>>
>>Regards, Diego.
>>
>>----------------------------------------------------------------
>>Diego Caviglia
>>Optical Network - ASON strategy
>>E-mail: [email-masked]
>>Tel: +39 0 10 6003 808
>>Via A. Negrone 1A 16153 Genoa (Italy)
>>http://www.marconi.com
>>
>>"Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
>>04.41.05
>>
>>Sent by:  [email-masked]
>>
>>To:   "Gino Carrozzo" <[email-masked]>, "ccamp" <[email-masked]>
>>cc:   <[email-masked]>
>>
>>Subject:  RE: UNI end-to-end sessions
>>
>>All,
>>I want to correct some mis-representations - There is no end-to-end UNI
>>session. A UNI session is between a user and the network. There is a
>>separate UNI session at the other edge of the network, between the other
>>client and the network. Further more, it should not be assumed that the
>>same protocol must run over the 2 separate UNIs.
>>
>>Monica A. Lazer
>>Advanced Transport Technology and Architecture Planning
>>
>>908 234 8462
>>[email-masked]
>>
>>-----Original Message-----
>>From: Gino Carrozzo [mailto:[email-masked]]
>>Sent: Tuesday, April 09, 2002 5:45 AM
>>To: ccamp
>>Cc: [email-masked]
>>Subject: UNI end-to-end sessions
>>
>>All,
>>
>>when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src &
>>dest. UNI clients),
>>I didn't found any reference in how to "transfer" UNI  end-to-end info from
>>the source client side (source UNI-C <--> UNI-N on source TNE) to the
>>destination client side (UNI-N on dest. TNE <-->dest UNI-C).
>>In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N side
>>is considered.
>>
>>How the two UNI-N can exchange UNI infos in the transport network?
>>Is there any action in this WG (or in IETF) to fix this problem?
>>
>>Thanks
>>
>>Gino
>>
>
>

Delivery-date: Wed, 10 Apr 2002 12:17:25 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Sudheer Dharanikota" <[email-masked]>, "Suresh Katukam" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents
Date: Wed, 10 Apr 2002 15:21:47 -0400

Sudheer,

I would think that the capability of a node or link really needs to
be part of the routing protocol, at least from a "distribution of
information" perspective.

Of course, it would have to be used in signaling for path setup
(depending on how path setup is initiated).

Also, I think Suresh's reference in asking for additions to routing
wasn't directed at the several proposals directed at simplifying
path computation and restoration, such as SRG.

Rather, it seems to point to some specific equipment/technology
capabilities
that need to be included in routing for the routing to be fully
applicable for the SDH/SONET case.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sudheer Dharanikota
> Sent: Tuesday, April 09, 2002 8:32 PM
> To: Suresh Katukam
> Cc: [email-masked]
> Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents
>
>
> Hi:
>
>
> Suresh Katukam wrote:
>
> > These routing documents do not cover many SONET/SDH cases at all.
> > Even though it is generic routing, SONET/SDH is included in these and
> > do not take care of TSI (Time Slot Interchangable) issues and protection
> > related issues.
> >
> > Here is the list of issues:
> >
> > 1. Certain links are TSI capable - and certain are not. In this
> case, one
> > needs to know the group of nodes that belong to this category (e.g.
> > Ring ID for BLSR ) so that one can do path computation properly.
>
> Some people feel that such requirements are to be part of signaling and
> some feel that it should be part of the routing and signaling
> protocol. I belong
> to the second category. As Kireeti said, in the design team this is one of
> the issues we would like to address. There are some proposals already
> on the table to address some of these issues...
> draft-many-ccamp-srg-01.txt is one such draft.
>
> - sudheer
>

Delivery-date: Wed, 10 Apr 2002 07:35:18 -0700
Date: Wed, 10 Apr 2002 07:33:00 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Diego Caviglia <[email-masked]>
CC: [email-masked], "Gino Carrozzo <g.carrozzo" <[email-masked]>, "ccamp <ccamp" <[email-masked]>, "<braja" <[email-masked]>
Subject: Re: UNI end-to-end sessions

There has been some effort in proposing a TLV to carry some of the
UNI specific parameters into NNI cloud. This was part of Private NNI
at OIF. Once we sort requirements out at OIF on NNI and UNI 2.0 front,
we can go to the details of this TLV.

- sudheer

Diego Caviglia wrote:

> Hi Monica,
>                         I agree with you that there isn't a UNI end-to-end
> session, but in my understanding what Gino was asking is how to map UNI
> information that has end-to-end significance.
>
> In fact it is written in the UNI doc (table 12-5) that there are some UNI
> objects that have end-to-end significance. For example Source and
> Destination TNA addresses have end-to-end significance.   This doesn't
> mean, as you pointed out, that there is an UNI session between two UNI.
>
>  Anyway the question is (this is my interpretation of Gino's message so
> please, Gino, correct me if I'm wrong) how can I transport/map the UNI
> end-to-end significative information between the two UNIs?
>
> AFAIK there is no room in GMPLS extended LDP and RSVP for this purpose.
>
> Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
> LDP/RSVP?
>
> Regards, Diego.
>
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: [email-masked]
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
>
> "Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
> 04.41.05
>
> Sent by:  [email-masked]
>
> To:   "Gino Carrozzo" <[email-masked]>, "ccamp" <[email-masked]>
> cc:   <[email-masked]>
>
> Subject:  RE: UNI end-to-end sessions
>
> All,
> I want to correct some mis-representations - There is no end-to-end UNI
> session. A UNI session is between a user and the network. There is a
> separate UNI session at the other edge of the network, between the other
> client and the network. Further more, it should not be assumed that the
> same protocol must run over the 2 separate UNIs.
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gino Carrozzo [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 5:45 AM
> To: ccamp
> Cc: [email-masked]
> Subject: UNI end-to-end sessions
>
> All,
>
> when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src &
> dest. UNI clients),
> I didn't found any reference in how to "transfer" UNI  end-to-end info from
> the source client side (source UNI-C <--> UNI-N on source TNE) to the
> destination client side (UNI-N on dest. TNE <-->dest UNI-C).
> In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N side
> is considered.
>
> How the two UNI-N can exchange UNI infos in the transport network?
> Is there any action in this WG (or in IETF) to fix this problem?
>
> Thanks
>
> Gino

Delivery-date: Wed, 10 Apr 2002 07:03:25 -0700
From: Bala Rajagopalan <[email-masked]>
To: 'Diego Caviglia' <[email-masked]>, [email-masked]
Cc: "\"Gino Carrozzo\" <g.carrozzo" <[email-masked]>,  "\"ccamp\" <ccamp" <[email-masked]>, Bala Rajagopalan <[email-masked]>
Subject: RE: UNI end-to-end sessions
Date: Wed, 10 Apr 2002 09:45:35 -0400

Please post UNI related messages to
[email-masked] (not to ccamp).

FYI, there is going to be a OIF contribution
on UNI-GMPLS mapping for the coming meeting.

Bala

> -----Original Message-----
> From: Diego Caviglia [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 4:21 AM
> To: [email-masked]
> Cc: "Gino Carrozzo" <g.carrozzo; "ccamp" <ccamp; <braja
> Subject: RE: UNI end-to-end sessions
> 
> 
> 
> Hi Monica,
>                         I agree with you that there isn't a 
> UNI end-to-end
> session, but in my understanding what Gino was asking is how 
> to map UNI
> information that has end-to-end significance.
> 
> In fact it is written in the UNI doc (table 12-5) that there 
> are some UNI
> objects that have end-to-end significance. For example Source and
> Destination TNA addresses have end-to-end significance.   This doesn't
> mean, as you pointed out, that there is an UNI session 
> between two UNI.
> 
>  Anyway the question is (this is my interpretation of Gino's 
> message so
> please, Gino, correct me if I'm wrong) how can I transport/map the UNI
> end-to-end significative information between the two UNIs?
> 
> AFAIK there is no room in GMPLS extended LDP and RSVP for 
> this purpose.
> 
> Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
> LDP/RSVP?
> 
> Regards, Diego.
> 
> 
> 
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: [email-masked]
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
> 
> 
> 
> "Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
> 04.41.05
> 
> Sent by:  [email-masked]
> 
> 
> To:   "Gino Carrozzo" <[email-masked]>, "ccamp" 
> <[email-masked]>
> cc:   <[email-masked]>
> 
> Subject:  RE: UNI end-to-end sessions
> 
> 
> All,
> I want to correct some mis-representations - There is no 
> end-to-end UNI
> session. A UNI session is between a user and the network. There is a
> separate UNI session at the other edge of the network, 
> between the other
> client and the network. Further more, it should not be 
> assumed that the
> same protocol must run over the 2 separate UNIs.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Gino Carrozzo [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 5:45 AM
> To: ccamp
> Cc: [email-masked]
> Subject: UNI end-to-end sessions
> 
> All,
> 
> when establishing an end-to-end UNI-RSVP session between two 
> UNI-Cs (src &
> dest. UNI clients),
> I didn't found any reference in how to "transfer" UNI  
> end-to-end info from
> the source client side (source UNI-C <--> UNI-N on source TNE) to the
> destination client side (UNI-N on dest. TNE <-->dest UNI-C).
> In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C 
> / UNI-N side
> is considered.
> 
> How the two UNI-N can exchange UNI infos in the transport network?
> Is there any action in this WG (or in IETF) to fix this problem?
> 
> 
> Thanks
> 
> Gino
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 10 Apr 2002 01:23:36 -0700
Subject: RE: UNI end-to-end sessions
To: [email-masked]
Cc: ""Gino Carrozzo" <g.carrozzo" <[email-masked]>, ""ccamp" <ccamp" <[email-masked]>, "<braja" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 10 Apr 2002 10:20:57 +0200

Hi Monica,
                        I agree with you that there isn't a UNI end-to-end
session, but in my understanding what Gino was asking is how to map UNI
information that has end-to-end significance.

In fact it is written in the UNI doc (table 12-5) that there are some UNI
objects that have end-to-end significance. For example Source and
Destination TNA addresses have end-to-end significance.   This doesn't
mean, as you pointed out, that there is an UNI session between two UNI.

 Anyway the question is (this is my interpretation of Gino's message so
please, Gino, correct me if I'm wrong) how can I transport/map the UNI
end-to-end significative information between the two UNIs?

AFAIK there is no room in GMPLS extended LDP and RSVP for this purpose.

Are there any efforts in IETF to harmonize OIF UNI and GMPLS extended
LDP/RSVP?

Regards, Diego.

----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

"Lazer, Monica A, ALCNS" <[email-masked]>@ops.ietf.org on 10/04/2002
04.41.05

Sent by:  [email-masked]

To:   "Gino Carrozzo" <[email-masked]>, "ccamp" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: UNI end-to-end sessions

All,
I want to correct some mis-representations - There is no end-to-end UNI
session. A UNI session is between a user and the network. There is a
separate UNI session at the other edge of the network, between the other
client and the network. Further more, it should not be assumed that the
same protocol must run over the 2 separate UNIs.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Gino Carrozzo [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 5:45 AM
To: ccamp
Cc: [email-masked]
Subject: UNI end-to-end sessions

All,

when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src &
dest. UNI clients),
I didn't found any reference in how to "transfer" UNI  end-to-end info from
the source client side (source UNI-C <--> UNI-N on source TNE) to the
destination client side (UNI-N on dest. TNE <-->dest UNI-C).
In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N side
is considered.

How the two UNI-N can exchange UNI infos in the transport network?
Is there any action in this WG (or in IETF) to fix this problem?

Thanks

Gino

Delivery-date: Tue, 09 Apr 2002 19:50:25 -0700
content-class: urn:content-classes:message
Subject: RE: UNI end-to-end sessions
Date: Tue, 9 Apr 2002 22:41:05 -0400
From: "Lazer, Monica A, ALCNS" <[email-masked]>
To: "Gino Carrozzo" <[email-masked]>, "ccamp" <[email-masked]>
Cc: <[email-masked]>

All,
I want to correct some mis-representations - There is no end-to-end UNI =
session. A UNI session is between a user and the network. There is a =
separate UNI session at the other edge of the network, between the other =
client and the network. Further more, it should not be assumed that the =
same protocol must run over the 2 separate UNIs.=20

Monica A. Lazer
Advanced Transport Technology and Architecture Planning
=20
908 234 8462
[email-masked]

-----Original Message-----
From: Gino Carrozzo [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 5:45 AM
To: ccamp
Cc: [email-masked]
Subject: UNI end-to-end sessions

All,

when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src =
&
dest. UNI clients),
I didn't found any reference in how to "transfer" UNI  end-to-end info =
from
the source client side (source UNI-C <--> UNI-N on source TNE) to the
destination client side (UNI-N on dest. TNE <-->dest UNI-C).
In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N =
side
is considered.

How the two UNI-N can exchange UNI infos in the transport network?
Is there any action in this WG (or in IETF) to fix this problem?

Thanks

Gino

Delivery-date: Tue, 09 Apr 2002 17:34:13 -0700
Date: Tue, 09 Apr 2002 17:32:04 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Suresh Katukam <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents

Hi:

Suresh Katukam wrote:

> These routing documents do not cover many SONET/SDH cases at all.
> Even though it is generic routing, SONET/SDH is included in these and
> do not take care of TSI (Time Slot Interchangable) issues and protection
> related issues.
>
> Here is the list of issues:
>
> 1. Certain links are TSI capable - and certain are not. In this case, one
> needs to know the group of nodes that belong to this category (e.g.
> Ring ID for BLSR ) so that one can do path computation properly.

Some people feel that such requirements are to be part of signaling and
some feel that it should be part of the routing and signaling protocol. I belong
to the second category. As Kireeti said, in the design team this is one of
the issues we would like to address. There are some proposals already
on the table to address some of these issues...
draft-many-ccamp-srg-01.txt is one such draft.

- sudheer

Delivery-date: Tue, 09 Apr 2002 17:00:12 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Suresh Katukam'" <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents
Date: Tue, 9 Apr 2002 16:57:25 -0700 

Hi Suresh, I brought up some of the bandwidth accounting issues and I
thought Eric and Dimitri Papadimitriou brought this up again in a SONET/SDH
specific draft.
I don't recall the discussion concluding...

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Technology Director, Ciena Corporation 

-----Original Message-----
From: Suresh Katukam [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 1:54 PM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents

These routing documents do not cover many SONET/SDH cases at all.
Even though it is generic routing, SONET/SDH is included in these and
do not take care of TSI (Time Slot Interchangable) issues and protection
related issues.

Here is the list of issues:

1. Certain links are TSI capable - and certain are not. In this case, one
needs to know the group of nodes that belong to this category (e.g.
Ring ID for BLSR ) so that one can do path computation properly.

2. How to advertise bandwidth on Non-TSI links? Since one need to use
same labels (time slots ) on all these links, one has to know all available
time slots or advertise virtual links (pt-2-pt links) between all these
nodes.

Was there any discussion on these documents?

Thanks,
Suresh

At 03:14 PM 4/3/2002 -0800, Kireeti Kompella wrote:
>Hi,
>
>This is to announce a two week WG Last Call on the GMPLS routing
>documents, i.e.:
>draft-ietf-ccamp-gmpls-routing-03.txt
>draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
>
>FYI: these documents are intended to be Standards Track.
>
>The Last Call will end at 1700 EDT, April 17th.
>
>Kireeti.

Delivery-date: Tue, 09 Apr 2002 14:37:17 -0700
Date: Tue, 9 Apr 2002 14:33:38 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Suresh Katukam <[email-masked]>
cc: <[email-masked]>
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents

On Tue, 9 Apr 2002, Suresh Katukam wrote:

> These routing documents do not cover many SONET/SDH cases at all.
> Even though it is generic routing, SONET/SDH is included in these and
> do not take care of TSI (Time Slot Interchangable) issues and protection
> related issues.

As you say, this is generic routing.  There are a couple of folks
working on a SONET/SDH document ... I'll see that they take note of
your comments.

As for protection related issues, I leave that to the protection/
restoration design team.

> Was there any discussion on these documents?

Yes.

Kireeti.

Delivery-date: Tue, 09 Apr 2002 13:54:34 -0700
Date: Tue, 09 Apr 2002 13:54:00 -0700
To: Kireeti Kompella <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents
Cc: <[email-masked]>

These routing documents do not cover many SONET/SDH cases at all.
Even though it is generic routing, SONET/SDH is included in these and
do not take care of TSI (Time Slot Interchangable) issues and protection
related issues.

Here is the list of issues:

1. Certain links are TSI capable - and certain are not. In this case, one
needs to know the group of nodes that belong to this category (e.g.
Ring ID for BLSR ) so that one can do path computation properly.

2. How to advertise bandwidth on Non-TSI links? Since one need to use
same labels (time slots ) on all these links, one has to know all available
time slots or advertise virtual links (pt-2-pt links) between all these nodes.

Was there any discussion on these documents?

Thanks,
Suresh

At 03:14 PM 4/3/2002 -0800, Kireeti Kompella wrote:
>Hi,
>
>This is to announce a two week WG Last Call on the GMPLS routing
>documents, i.e.:
>draft-ietf-ccamp-gmpls-routing-03.txt
>draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
>
>FYI: these documents are intended to be Standards Track.
>
>The Last Call will end at 1700 EDT, April 17th.
>
>Kireeti.

Delivery-date: Tue, 09 Apr 2002 13:11:17 -0700
Date: Tue, 9 Apr 2002 13:04:50 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: [email-masked]
Subject: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

Kireeti, et al:

Please find my comments on the draft below.
I'm also CC'ing the OSPF WG to make sure we
have a good coverage here.

Cheers!

Alex

> CCAMP Working Group                       K. Kompella (Juniper Networks)
> Internet Draft                            Y. Rekhter  (Juniper Networks)
> Expiration Date: October 2002             A. Banerjee (Calient Networks)
>                                           J. Drake    (Calient Networks)
>                                           G. Bernstein (Ciena)
>                                           D. Fedyk    (Nortel Networks)
>                                           E. Mannie   (GTS Network)
>                                           D. Saha     (Tellium)
>                                           V. Sharma   (Metanoia, Inc.)

I would consult your ADs about the length of the author list.

IMHO, it's kind of hard to imagine 9 people editing
a draft containing 7 pages of useful info ;))

> 
>              OSPF Extensions in Support of Generalized MPLS
> 
>              draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
> 
> 
[...]

>
> 2. Abstract
> 
>    This document specifies encoding of extensions to the OSPF routing
>    protocol in support of Generalized Multi-Protocol Label Switching
>    (GMPLS).  The description of the extensions is specified in [GMPLS-
>    ROUTING].

The rfc-ed will request the citation to be removed from the abstract.

>
> 4. Introduction
> 
>    This document specifies extensions to the OSPF routing protocol in
>    support of carrying link state information for Generalized Multi-
>    Protocol Label Switching (GMPLS). The set of required enhancements to
>    OSPF are outlined in [GMPLS-ROUTING].

It might be a good idea to explicitly mention that only
intra-area issues are covered here.

> 5. OSPF Routing Enhancements
> 
>    In this section we define the enhancements to the TE properties of
>    GMPLS TE links that can be announced in OSPF TE LSAs.  The Traffic
>    Engineering (TE) LSA, which is an opaque LSA with area flooding scope
>    [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and
>    has one or more nested sub-TLVs for extensibility. The top-level TLV
>    can take one of two values (1) Router Address or (2) Link. In this
>    document, we enhance the sub-TLVs for the Link TLV in support of
>    GMPLS. Specifically, we add the following sub-TLVs to the Link TLV:
> 
>       1. Link Local Identifier,
>       2. Link Remote Identifier,
>       3. Link Protection Type,
>       4. Interface Switching Capability Descriptor, and
>       5. Shared Risk Link Group.

Minor: given the table below, do we need the above list really?

>    The following defines the Type and Length of these sub-TLVs:
> 
>       Sub-TLV Type      Length    Name
>                 11           4    Link Local Identifier
>                 12           4    Link Remote Identifier
>                 14           4    Link Protection Type
>                 15    variable    Interface Switching Capability Descriptor
>                 16    variable    Shared Risk Link Group
> 

[OSPF-TE] says:

   The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
   exactly once.  All other sub-TLVs defined here may occur at most
   once.  These restrictions need not apply to future sub-TLVs.
   Unrecognized sub-TLVs are ignored.

Considering the last two sentences, it would be really nice if
this document said something about this.

You might also say something about processing of sub-TLVs
with unexpected length.

> 5.1. Link Local Identifier
> 
>    A  Link Local Identifier is a sub-TLV of the Link TLV with type 11,
>    and length 4.

What do I put in it?

> 5.2. Link Remote Identifier
> 
>    A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
>    and length 4.
> 

Ditto

>
> 5.3. Link Protection Type
> 
>    The Link Protection Type is a sub-TLV of the Link TLV, with type 14,
>    and length of four octets, the first of which is a bit vector
>    describing the protection capabilities of the link. They are:

Might be a good idea to include an IETF-style format illustration
here, to make sure everyone understands "first octet" the same
way.

Something should also be said about other octets. Are they reserved
and ignored on receipt?

>       0x01  Extra Traffic
>       0x02  Unprotected
>       0x04  Shared
>       0x08  Dedicated 1:1
>       0x10  Dedicated 1+1
>       0x20  Enhanced
>       0x40  Reserved
>       0x80  Reserved

I believe these are described in [GMPLS-ROUTING]. You may want
to add a reference to it here.

> 5.4. Shared Risk Link Group (SRLG)
> 
>    The SRLG is a sub-TLV of the Link TLV with type 16. The length is the
>    length of the list in octets. The value is an unordered list of 32
>    bit numbers that are the SRLGs that the link belongs to. The format
>    of the value field is as shown below:

ditto

...

> 5.5. Interface Switching Capability Descriptor
> 
>    The Interface Switching Capability Descriptor is a sub-TLV of the
>    Link TLV with type 15. The length is the length of value field in

Minor: might want to change wording, not clear what "with type 15" is
relative to, one may ready "Link TLV with type 15".

>    octets. The format of the value field is as shown below:
> 
...
>
>    When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
>    the specific information includes Interface MTU, Minimum LSP
>    Bandwidth, and padding. The Interface MTU is encoded as a 2 octets
>    integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field
>    in the IEEE floating point format. The units are bytes (not bits!)
>    per second. The padding is 2 octets, and is used to make the
>    Interface Switching Capability Descriptor sub-TLV 32-bits aligned.

Would be just great to have a field format illustration here.

> 
>    When the Switching Capability field is L2SC, there is no specific
>    information.

So, the field is not included? Please specify.

>    When the Switching Capability field is TDM, the specific information
>    includes Minimum LSP Bandwidth, an indication whether the interface
>    supports Standard or Arbitrary SONET/SDH, and padding. The Minimum
>    LSP Bandwidth is encoded in a 4 octets field in the IEEE floating
>    point format. The units are bytes (not bits!) per second. The
>    indication whether the interface supports Standard or Arbitrary
>    SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the
>    interface supports Standard SONET/SDH, and 1 if the interface
>    supports Arbitrary SONET/SDH.  The padding is 3 octets, and is used
>    to make the Interface Switching Capability Descriptor sub-TLV 32-bits
>    aligned.

Again, would appreciate a format illustration here. Breaking field
description into a list here and above would be nice as well.

> 
>    When the Switching Capability field is LSC, there is no specific
>    information.

"... and the <blah> field is not included."
> 
>    The Interface Switching Capability Descriptor sub-TLV may occur more
>    than once within the Link TLV.

"...to indicate multiple switching capabilities supported by the link.
The resulting set of capabilities includes all those announced in
multiple instances of the sub-TLV" or something like this?

> 6. Implications on Graceful Restart
> 
>    The restarting node should follow the OSPF restart procedures [OSPF-
>    RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].

These look like normative references and hence it means that the
document will be delayed until those are complete. Just a heads-up :)

>    When a restarting node is going to originate its TE LSAs, the TE LSAs
>    containing Link TLV should be originated with 0 unreserved bandwidth,
>    and if the Link has LSC or FSC as its Switching Capability then also
>    with 0 as Max LSP Bandwidth, until the node is able to determine the
>    amount of unreserved resources taking into account the resources
>    reserved by the already established LSPs that have been preserved
>    across the restart. Once the restarting node determines the amount of
>    unreserved resources, taking into account the resources reserved by
>    the already established LSPs that have been preserved across the
>    restart, the node should advertise these resources in its TE LSAs.
> 
>    In addition in the case of a planned restart prior to restarting, the
>    restarting node SHOULD originate the TE LSAs containing Link TLV with
>    0 as unreserved bandwidth, and if the Link has LSC or FSC as its
>    Switching Capability then also with 0 as Max LSP Bandwidth.

"...to discourage new LSP establishment through the restarting router"?

>    Neighbors of the restarting node should continue advertise the actual
>    unreserved bandwidth on the TE links from the neighbors to that node.
> 
>    Regular graceful restart should not be aborted if a TE LSA or TE
>    topology changes. TE graceful restart need not be aborted if a TE LSA
>    or TE topology changes.
> 
> 
> 7. Security Considerations
> 
>    The sub-TLVs proposed in this document does not raise any new
>    security concerns.

"do not raise"

> 9. References

Might be a good idea to split these to normative and
informative or specify the type if all of them are the same
type.

<the end>

Delivery-date: Tue, 09 Apr 2002 05:44:05 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-00.txt
Date: Tue, 09 Apr 2002 08:40:36 -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 Signalling Extensions for G.709 Optical 
                          Transport Networks Control
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-g709-00.txt
	Pages		: 19
	Date		: 08-Apr-02
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It
describes the G.709 [ITUT-G709] technology specific information
needed to extend GMPLS signalling to control Optical Transport
Networks (OTN); it also includes the so-called pre-OTN
developments.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-g709-00.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 09 Apr 2002 02:46:40 -0700
From: "Gino Carrozzo" <[email-masked]>
To: "ccamp" <[email-masked]>
Cc: <[email-masked]>
Subject: UNI end-to-end sessions
Date: Tue, 9 Apr 2002 11:45:24 +0200
Organization: META-CPR

All,

when establishing an end-to-end UNI-RSVP session between two UNI-Cs (src &
dest. UNI clients),
I didn't found any reference in how to "transfer" UNI  end-to-end info from
the source client side (source UNI-C <--> UNI-N on source TNE) to the
destination client side (UNI-N on dest. TNE <-->dest UNI-C).
In draft-bala-uni-signaling-extensions-00.txt, only the UNI-C / UNI-N side
is considered.

How the two UNI-N can exchange UNI infos in the transport network?
Is there any action in this WG (or in IETF) to fix this problem?

Thanks

Gino

Delivery-date: Tue, 09 Apr 2002 00:43:01 -0700
Date: Tue, 09 Apr 2002 09:41:08 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: LMP & neighbor discovery

Hello all,

I found the concept of neighbor discovery mentioned several times in
previous discussions on this list. However, I did not find a final
conclusion on how this neighbor discovery is done. Correct ?

Could you please check my understanding below ?

In my mind, reading the incoming 'access point identifier' [ITU-G.707]
and subsequent LMP 'link property correlation' form a perfect fit. By
simply encoding the sending node's IP address and local access point
number in the access point identifier (see e.g. [OIF.2000.159.01]), the
receiver can discover the data link (linkConnection in ITU terminology).
Subsequent 'link property correlation' could then a.o. check on bi-
directional fibering, matching data link properties and grouping of data
links into TE links.

Example: the following figure shows 4 network elements of which 2 terminate
the data link (TTPs, T) and two are transparent to the data link (CTPs, C).
E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are transparent
optical cross connects. The data link in this example is STM-N/OC-N.

+------+      +------+      +------+      +------+
|    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
|      |   A  |      |   B  |      |   C  |      |
|      |      |      |      |      |      |      |
| NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
+------+      +------+      +------+      +------+

NE-2 should, when it wants to discover data link B, connect a test-set that
sends an access point identifier to identify the sending connection point C
in NE-2. This test-signal should be send long enough for NE-3 to detect and
read the test-signal (a fixed, agreed upon timer is needed). NE-3 will
continuously scan all its not discovered input ports for a discovery signal.
At some point, it will detect the test-signal on data link B.

+------+      +------+      +------+      +------+
|    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
|      |   A  |   /  |   B  |  \   |   C  |      |
|      |      |  T   |      |   T  |      |      |
| NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
+------+      +------+      +------+      +------+

When NE-3 has read the access point identifier in the test signal, data
link B is discovered. Subsequent link property correlation can then be
invoked.

Discovery of data link A is similar, except that the access point identifier
is continuously sent. Discovery of data link C is also similar, except that
the access point identifier is continuously monitored. In other words, there
is no need for a sending respectively monitoring 'test-set' in NE-1 and NE-4.

Data link type          Access point identifier to be used
--------------          ----------------------------------
STM-N, OC-N                            J0
STS-1/3/.../VC-3/4/...                 J1
VT-1.5/VC-11/12                        J2

Notes:
- I understand that LMP's link verification procedure is more efficient for
  *already discovered* data links. It does not need the continuous scanning
  on received access point identifiers in undiscovered CTPs (in the example:
  in NE-3).
- Discovering the address of the sending access point might also go via a 'name
  server'. This can, for example, be useful in case the address of this access
  point can not be encoded in the limited length of the access point identifier.

B.t.w., could you please explain why the linkSummary and linkSummaryAck messages
have to go over a point-to-point control channel ? Is it also possible to
use the generic DCN network (MCN/SCN, can be IP-based, see ITU-G.7712) ?
In the latter case, we could simply use the normal UDP service of that network
to transport the linkSummary and linkSummaryAck messages ? Is implementation
of the LMP's 'control channel management' mandatory ?

Thanks !

Michiel

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Mon, 08 Apr 2002 18:59:58 -0700
Date: Mon, 08 Apr 2002 21:49:28 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: IETF 53 CCAMP Minutes
To: Eve Varma <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_F+QXrvtPWqlTFzj4dOBxpQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8bit

I have added this to the minutes.

                        thanks,
                             Ron

  -----Original Message-----
  From: Eve Varma [mailto:[email-masked]]
  Sent: Monday, April 08, 2002 5:23 PM
  To: Ron Bonica
  Cc: [email-masked]
  Subject: Re: IETF 53 CCAMP Minutes

  Hi,
  Per your request from further down within the text - "can we supplement
with other copy of the minutes", here are some of my notes.

  Cheers,
      Eve

  --------------------------------------------------------------------
  Call for Design Team for GMPLS Profile for ASON/ASTN

  ITU-T Liaison
  Steve Trowbridge provided a report of the work of ITU-T Q14, as well as
from Q11 identifying the areas that need further work, as outlined in the
liaison to the IETF.  He also reviewed the Detector Controller Interface,
clarifying this is over and above the actual payload.  It's the view of the
anomalies and detectors from a control plane perspective, and identified the
key information flows to be communicated across this interface.

  Eric Mannie indicated that these gaps are very small, and were on their
way to being solved.  He asked if these were all the gaps?  Steve said this
doesn't mean that there wouldn't be something else identified, but would
like to see disconnects addressed and resolved.

  Dimitrios Pendarakis said the issue here is that the ITU-T has a set of
requirements preceding this work, and have had some preliminary discussions.
Many are more clarification and applicability.  However, there may be some
areas where some additional work might be involved.  The IETF gained alot
from the OIF experience, and he suggested this would be a good opportunity
with the ITU-T as well.

  Yong Xue said the ITU-T is now working on version 2 of the document
(G.7713), and should be considered.

  Eve Varma provided a clarification that this was really for G.7713.2
(GMPLS RSVP-TE), though in the future as the G.7713 (protocol-neutral)
capability set expands, the protocols may also need extension
  -----------------------------------------------------------------------

  Ron Bonica wrote:

    Folks,
    Minutes from our last meeting follow. Please review and comment.

                                              Ron

    CCAMP Minutes

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Kireeti Kompella - Status Update

    Draft Status Update

    generalized signalling - finished last call,have implementation status,
    ready for ietf last call

    call for consensus to send to ietf last call:
            draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
informational
                                    -architecture-02.txt  informational
                                    -ccamp-sdhsonet-control-00.txt
informational

    Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a
    working group document?

    NO OBJECTIONS

    Kireeti: There was a call for design team for "GMPLS profile for
ason/astn"

    Tolbridge: g709 framework was going to go back to the ITU to produce
    ".g.709 for dummies".  Have not met yet.

    Kireeti: happy to remove from plate of CCAMP if ITU will handle.

    Osama: we have a draft at ITU-T that is a wg document

    Kireeti: need a more concise statement from ITU

    Kireeti: If you have any comments on the documents
    (additions/subtractions/etc.), please post to the list.

    Kireeti: there will be a charter update at some point

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Steve Tolbridge

    Wasam Alanqar is liaison to ITU-T SG 15.

    (2) communications to IETF CCAMP
      - signaling protocol work in Q14.15
      - detector-controller interface (DCI) from Q.11/15

    See proceedings for URLs that show location of docs.

    Documents sent to IETF from Q14.15
      - PNNI-based signaling
      - GMPLS RSVP-TE based signaling
      - GMPLS CR-LDP based signaling

    Outlined a variety of "gaps" in the current work:
      - Call and connection separation
      - Additional error codes/value
      - Restart mechanisms
      - Support for crankback
      - Support for soft permanent connection

    See proceedings for details.

    Eric Mannie: Referring to slide "Identified Gaps".  Gaps seem to be
    very small.  Most of the points are solved, can be easily solved, or
    are in the process of being solved.

    Tolbridge: This was a preliminary scan.  Further review, might turn up
    more issues.  Technologies are similar, so lets identify and minimize
    gaps.

    Dimitri: ITU requirements precede much of IETF work.  Preliminary
    discussions indicate that the current gaps are covered by existing
    protocol work.  Areas where additional work will be required are
    probably minimal, but need to be looked at.  IETF may gain final
    improvements by looking at ITU work.

    Yong Xue: ITU is working on v2 ASON document so more things could turn
    up as "gaps".  Further communication between ITU and IETF should
    continue.

    Tolbridge: Technology will evolve within both organizations.  Should
    expend effort to make sure that they evolve together.

    Eva: ??? what was the point ???

    [ can we supplement with other copy of the minutes ]

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Lou Berger

    www.labn.net/gmpls-survey/...

    17 organisations responded, mostly equipment vendors
    1 provider
    about 50% are independent implementation

    charts no. of implementations as a function of feature
    17 gen label and bw encoding
    12 sonet/sdh label and traffic parameters
    17 bidir lsps
    ...

    no questions

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Eric Mannie - gmpls recovery terminology

    Eric provided overview of terminology draft.  Draft covers:
      - LSP protection and restoration
      - LSPs controlled by a GMPLS control place
      - End-to-end segment and span recovery

    Kireeti: Please send comments to list about whether or not this should
    be a wg document. Sense of room:

    About 20 have read document - all agree that this is a wg document.

    Yong: All carriers have a different definition of
    protection/restoration.  We need more carriers involved in the
    process.  IP and transport folks rarely have the same perspective.

    Kireeti: SP input came from TE WG and the SP representative on the
    design team (KPNQwest).  Point is well-taken.  Carriers please make
    comments.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Chen Lee - "Exclude Routes"

    Draft defines a new RSVP-TE object that allows specification of
    intermediate "objects" to avoid - avoid highly utilized nodes/ASs.

    Wanted wg consensus on definition of this object.  Current draft does
    !(A,B,C,D), but do we need to support (A, !B, !C, D).

    Yakov: Regarding slide "application inter-area".  As far as I
    understand, you want to exclude certain routers/links.  What is
    purpose of excluding links?  If you just specify a link, what does
    that do?

    Lee: You may want 

    Yakov: If you just want link diversity, then you want SLRGs, not links.

    Yakov: Regarding "application - avoid highly utilized node/as".  Why
    do this? Why not explicit route A, B, E, F?

    Lee: What if you just know what you don't want, but know explicit route.

    Kireeti: One of the issues.  When you do explicit routing with loose
    hops, this is very similar.  However, don't want to do TE
    node-by-node.  Want head-end or offline computations, not hop-by-hop
    TE. The point is not to overload RSVP-TE with all of this information
    - don't want to do this computation during the signaling process
    anyway.

    Ron: Take discussion to lists.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % draft-shiomoto-ccamp-multiarea-te-00.txt

    hierarchical lsps for multiarea te
            lowr layer for abr-abr
            upper layer going ingress to egress

    use of O-LSP for E-LSP routing.
    next step: should be included in multiarea te framework

    no questions
    no support from floor, take to list

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % draft-imajuku-ml-routing-01.txt

    LSR and PXC in same node. Number of links between the two should be
    advertised as available resource in the switching capability no
questions
    from floor

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Jerry Ash - draft-ash-multi-area-te-compare-00.txt

    comparison draft looks at existing proposals, try to converge on a
reduced
    set

    4 main types:
    distributed eg kompella scenario 1
    path computation server, PCS, eg kompella scenario 2/4, 5
    interarea summary methods
    multiple path comparison

    criteria: optimality, scalabilty, resoration, path selection
performance,
    path selection fuctionality

    next steps: discuss options on list for consensus on selected method
    if confirmed proceed with pcs, query and crankback exytensions

    Yakov: You state that PCS achieves optimal section.  How much topology
    information does the PCS need?

    Ash: Has full-topology of backbone area.

    Yakov: Therefore only optimal w.r.t. the backbone area.

    Ash: Well it varies.

    Yakov: Statement that PCS scales is "interesting".  : Normally
    distributed approaches scale better.

    Ash: Flooding is an issue with distributed schemes.

    Yakov: There is also computational load.  Box may be a bottleneck.

    Ash: That does not make it less scalable. [laughter here ]

    McDysan: What happens when a router is controlling optical paths and
    router goes berserk.  Might want to do "stability during
    mismanagement" characterization.  Very valuable from SP point of view.

    ???: Single ISP or multiple ISPs?

    Ash: Single ISP.

    ???: Why is protection hard in different areas?

    Ash: Can be done.  Much discussion between authors on this.

    Kireeti: As a router vendor, I take exception to the comment that
    routers are more likely to screw up than OXCs.

    Yakov: If you do protection/restoration on a per-area basis, then

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt

    Summarized modifications to document - see presentation.

    Note: Remember that this wg id detailed the architecture of the GMPLS
    building blocks, but not the detailed semantic of the technology
    dependent structures, fields, objects, etc.

    Ready for WG last call? About 20.

    Bilel: Would be useful to send this to ITU and recommend use of GMPLS.

    Kireeti: Are you suggesting that we take the document to ITU?

    Bilel: Yes.  With perhaps an exercise to see if it meets requirements.

    Kireeti: Who thinks that the document is not ready?  NONE

    Kireeti: Please be diligent is making any comments.  Want to send to
    ADS and request publications as an informational RFC.

    next: meeting to sort out label issue, send updated drafts for last
review,
    go to iesg last call.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
    % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

    Presented history and latest changes made.

    Next steps - small revisions to drafts (specifically label coding) and
    then go to IETF last call.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt

    Presented history and latest changes made.

    Target is informational RFC.  Let's have last review and last call
    before next IETF.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt

    Reviewed document status.  Would like WG to adopt working item?

    SENSE OF ROOM: SUPPORT 10-15.  NO OBJECTIONS.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt

    Reviewed scenarios in document.  Is working group will to accept this
    as a WG document?

    NO RESPONSE FROM THE ROOM (maybe 3 for, none against).

    Ron: Take this item to the mailing list.

    Kireeti: How many SPs in the room.  20-25.

    Kireeti: How many folks are interested in transport.  MOST EVERYONE

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.

    Draft addresses one of the issues that Tolbridge highlighted in his
    talk - call and connection control separation.

    Proposal to accept document as a WG item.

    Kireeti: There is an explicit statement from ITU requiring this.
    There is nothing in the charter about this.  This is good stuff.  Ron
    and I will go through a charter revision with Ads and discuss putting
    this in the charter.  Also need to address other gaps that were raised
    by ITU.

    Scott: When you propose to add something to WG, it would be helpful to
    state where it fits in the existing charter OR how and why charter
    should be extended.

    Eva: I think that it fits into the character as a requirement to the
    signaling protocols.

    Scott: OK - that is a good clean explanation that might save chairs
    some time.

    Yong: I second Eva's comment.

    Kireeti: Need to figure out how to address other issues as well.
    Also, MPLS OAM will be discussed in MPLS WG tomorrow.

    Osama: What is outcome?

    Kireeti: Let's think about this.  See about doing same for RSVP and
    then move forward.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % John Lang - LMP status (draft -03)

    Current status:
      - Finished WG last call
      - Fixed several edits
      - Added text to security considerations

    Open Issues:
      - Security
          - currently md5 is defined for LMP authentication
          - Another proposal exists in draft-sankar for Ipsec usage
      - Make local/remote id different in class type instead of object class

    Bert: I raised the local/remote id issue, but there were also other
    issues where things could be combined.  Did you review other parts of
    document as well?

    John: We did.  Your comment reflects this class, but not others.

    NO OBJECTIONS TO PROPOSED CHANGES

    John Sadler: I have some open issues.  Test message and ???.

    John: Test message was updated based on comments in last call and
    should be consistent with OIF work.

    John Sadler: Does not talk about control/address fields.  Do not talk
    about 1662 frame format.

    John: We can look at this.

    Kireeti: OIF compatibility is not a requirement, but if we get that
    for free (or cheap) great.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Tom Nadeau - MIBs for GMPLS

    Reviewed status of current documents, minor changes, etc.  Want GMPLS
    MIBs to be compatible with MPLS MIBs when then become RFCs.

    Summary:
      - Make mpls-tev2 MIB CCAMP (or MPLS) wg document
      - Make GMPLS-label MIB CCAMP wg document.
      - GMPLS-TC MIB as CCAMP wg document to capture new GMPLS-related TCs.
      - Drop GMPLS-LSR MIB (will use as it is including new TC change).

    Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?

    Tom: New indexing scheme relies on having the label MIB - for MPLS
    index is label.  For GMPLS there is more stuff in the GMPLS-label MIB.

    Kireeti: Need to see new version and then move forward.  Nice if we
    could decouple them.  Will discuss with chairs and Ads where this
    should go.

    Scott: Seems general, so belongs in CCAMP.

    Tolbridge: "general" frequently means more than one thing.

    Kireeti: We have "classical" MPLS and non-packet based MPLS.
    Generalized covers both.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling and
    restoration

    Presented drafts.

    Kireeti: Protection group should consider these docs.  More discussion
    on the list.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Ron Bonica

    Issues:
      - Should we define protocols yet?
      - IP centric VS Tunnel Centric tools

    We need a tool that tells us about the IP layer and the tunnels that
    support it.  IP network may be supported by multiple types of tunnels
    - don't want separate tools for each type.

    Proposal - adopt tunnel tracing requirements as a wg document.
    Continue work on protocol specification.  Orthogonal to any open
    discussions about MPLS OAM.

    Kireeti: Discussion to list.

    ???: Is the proposal to accept a new (03) draft that incorporates
    comments from the list.

    Ron: not the intention.  Accepting the doc just means that it is a
    good enough starting point and we can spin revs later.

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Dimitri - protection and restoration

    Will submit draft as an individual ID.  Want comments from the list.

    Kireeti: Thanks.

    ===========================================
    Ronald P. Bonica       Ph: 703 886 1681
    vBNS Engineering       page: 1 888 268 8021
    Ashburn, Va.
    ===========================================
    "Not all who wander are lost."
                    -- J.R.R. Tolkien

--Boundary_(ID_F+QXrvtPWqlTFzj4dOBxpQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D722554001-09042002>I have=20
added this to the minutes.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722554001-09042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722554001-09042002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722554001-09042002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Ron</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D722554001-09042002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Eve Varma=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, April 08, 2002 5:23 =

  PM<BR><B>To:</B> Ron Bonica<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: IETF 53 CCAMP=20
  Minutes<BR><BR></FONT></DIV>Hi,=20
  <P>Per your request from further down within the text - "can we =
supplement=20
  with other copy of the minutes", here are some of my notes.=20
  <P>Cheers, <BR>&nbsp;&nbsp;&nbsp; Eve=20
  =
<P>--------------------------------------------------------------------=20
  <BR><U>Call for Design Team for GMPLS Profile for ASON/ASTN</U>=20
  <P><I>ITU-T Liaison</I> <BR>Steve Trowbridge provided a report of the =
work of=20
  ITU-T Q14, as well as from Q11 identifying the areas that need further =
work,=20
  as outlined in the liaison to the IETF.&nbsp; He also reviewed the =
Detector=20
  Controller Interface, clarifying this is over and above the actual=20
  payload.&nbsp; It's the view of the anomalies and detectors from a =
control=20
  plane perspective, and identified the key information flows to be =
communicated=20
  across this interface.=20
  <P>Eric Mannie indicated that these gaps are very small, and were on =
their way=20
  to being solved.&nbsp; He asked if these were all the gaps?&nbsp; =
Steve said=20
  this doesn't mean that there wouldn't be something else identified, =
but would=20
  like to see disconnects addressed and resolved.=20
  <P>Dimitrios Pendarakis said the issue here is that the ITU-T has a =
set of=20
  requirements preceding this work, and have had some preliminary=20
  discussions.&nbsp; Many are more clarification and =
applicability.&nbsp;=20
  However, there may be some areas where some additional work might be=20
  involved.&nbsp; The IETF gained alot from the OIF experience, and he =
suggested=20
  this would be a good opportunity with the ITU-T as well.=20
  <P>Yong Xue said the ITU-T is now working on version 2 of the document =

  (G.7713), and should be considered.=20
  <P>Eve Varma provided a clarification that this was really for =
G.7713.2 (GMPLS=20
  RSVP-TE), though in the future as the G.7713 (protocol-neutral) =
capability set=20
  expands, the protocols may also need extension=20
  =
<BR>---------------------------------------------------------------------=
--=20
  <BR>&nbsp;=20
  <P>Ron Bonica wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">Folks,=20
    <P>Minutes from our last meeting follow. Please review and comment.=20
    =
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Ron=20
    <P>CCAMP Minutes=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Kireeti Kompella - Status Update=20
    <P>Draft Status Update=20
    <P>generalized signalling - finished last call,have implementation =
status,=20
    <BR>ready for ietf last call=20
    <P>call for consensus to send to ietf last call:=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt&nbsp; =
informational=20
    =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    -architecture-02.txt&nbsp; informational=20
    =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    -ccamp-sdhsonet-control-00.txt&nbsp; informational=20
    <P>Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a=20
    <BR>working group document?=20
    <P>NO OBJECTIONS=20
    <P>Kireeti: There was a call for design team for "GMPLS profile for=20
    ason/astn"=20
    <P>Tolbridge: g709 framework was going to go back to the ITU to =
produce=20
    <BR>".g.709 for dummies".&nbsp; Have not met yet.=20
    <P>Kireeti: happy to remove from plate of CCAMP if ITU will handle.=20
    <P>Osama: we have a draft at ITU-T that is a wg document=20
    <P>Kireeti: need a more concise statement from ITU=05=20
    <P>Kireeti: If you have any comments on the documents=20
    <BR>(additions/subtractions/etc.), please post to the list.=20
    <P>Kireeti: there will be a charter update at some point=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Steve Tolbridge=20
    <P>Wasam Alanqar is liaison to ITU-T SG 15.=20
    <P>(2) communications to IETF CCAMP <BR>&nbsp; - signaling protocol =
work in=20
    Q14.15 <BR>&nbsp; - detector-controller interface (DCI) from Q.11/15 =

    <P>See proceedings for URLs that show location of docs.=20
    <P>Documents sent to IETF from Q14.15 <BR>&nbsp; - PNNI-based =
signaling=20
    <BR>&nbsp; - GMPLS RSVP-TE based signaling <BR>&nbsp; - GMPLS CR-LDP =
based=20
    signaling=20
    <P>Outlined a variety of "gaps" in the current work: <BR>&nbsp; - =
Call and=20
    connection separation <BR>&nbsp; - Additional error codes/value =
<BR>&nbsp; -=20
    Restart mechanisms <BR>&nbsp; - Support for crankback <BR>&nbsp; - =
Support=20
    for soft permanent connection=20
    <P>See proceedings for details.=20
    <P>Eric Mannie: Referring to slide "Identified Gaps".&nbsp; Gaps =
seem to be=20
    <BR>very small.&nbsp; Most of the points are solved, can be easily =
solved,=20
    or <BR>are in the process of being solved.=20
    <P>Tolbridge: This was a preliminary scan.&nbsp; Further review, =
might turn=20
    up <BR>more issues.&nbsp; Technologies are similar, so lets identify =
and=20
    minimize <BR>gaps.=20
    <P>Dimitri: ITU requirements precede much of IETF work.&nbsp; =
Preliminary=20
    <BR>discussions indicate that the current gaps are covered by =
existing=20
    <BR>protocol work.&nbsp; Areas where additional work will be =
required are=20
    <BR>probably minimal, but need to be looked at.&nbsp; IETF may gain =
final=20
    <BR>improvements by looking at ITU work.=20
    <P>Yong Xue: ITU is working on v2 ASON document so more things could =
turn=20
    <BR>up as "gaps".&nbsp; Further communication between ITU and IETF =
should=20
    <BR>continue.=20
    <P>Tolbridge: Technology will evolve within both =
organizations.&nbsp; Should=20
    <BR>expend effort to make sure that they evolve together.=20
    <P>Eva: ??? what was the point ???=20
    <P>[ can we supplement with other copy of the minutes ]=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Lou Berger=20
    <P>www.labn.net/gmpls-survey/...=20
    <P>17 organisations responded, mostly equipment vendors <BR>1 =
provider=20
    <BR>about 50% are independent implementation=20
    <P>charts no. of implementations as a function of feature <BR>17 gen =
label=20
    and bw encoding <BR>12 sonet/sdh label and traffic parameters <BR>17 =
bidir=20
    lsps <BR>...=20
    <P>no questions=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Eric Mannie - gmpls recovery terminology=20
    <P>Eric provided overview of terminology draft.&nbsp; Draft covers:=20
    <BR>&nbsp; - LSP protection and restoration <BR>&nbsp; - LSPs =
controlled by=20
    a GMPLS control place <BR>&nbsp; - End-to-end segment and span =
recovery=20
    <P>Kireeti: Please send comments to list about whether or not this =
should=20
    <BR>be a wg document. Sense of room:=20
    <P>About 20 have read document - all agree that this is a wg =
document.=20
    <P>Yong: All carriers have a different definition of=20
    <BR>protection/restoration.&nbsp; We need more carriers involved in =
the=20
    <BR>process.&nbsp; IP and transport folks rarely have the same =
perspective.=20
    <P>Kireeti: SP input came from TE WG and the SP representative on =
the=20
    <BR>design team (KPNQwest).&nbsp; Point is well-taken.&nbsp; =
Carriers please=20
    make <BR>comments.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Chen Lee - "Exclude Routes"=20
    <P>Draft defines a new RSVP-TE object that allows specification of=20
    <BR>intermediate "objects" to avoid - avoid highly utilized =
nodes/ASs.=20
    <P>Wanted wg consensus on definition of this object.&nbsp; Current =
draft=20
    does <BR>!(A,B,C,D), but do we need to support (A, !B, !C, D).=20
    <P>Yakov: Regarding slide "application inter-area".&nbsp; As far as =
I=20
    <BR>understand, you want to exclude certain routers/links.&nbsp; =
What is=20
    <BR>purpose of excluding links?&nbsp; If you just specify a link, =
what does=20
    <BR>that do?=20
    <P>Lee: You may want =05=20
    <P>Yakov: If you just want link diversity, then you want SLRGs, not =
links.=20
    <P>Yakov: Regarding "application - avoid highly utilized =
node/as".&nbsp; Why=20
    <BR>do this? Why not explicit route A, B, E, F?=20
    <P>Lee: What if you just know what you don't want, but know explicit =
route.=20
    <P>Kireeti: One of the issues.&nbsp; When you do explicit routing =
with loose=20
    <BR>hops, this is very similar.&nbsp; However, don't want to do TE=20
    <BR>node-by-node.&nbsp; Want head-end or offline computations, not=20
    hop-by-hop <BR>TE. The point is not to overload RSVP-TE with all of =
this=20
    information <BR>- don't want to do this computation during the =
signaling=20
    process <BR>anyway.=20
    <P>Ron: Take discussion to lists.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% draft-shiomoto-ccamp-multiarea-te-00.txt=20
    <P>hierarchical lsps for multiarea te=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lowr layer for =
abr-abr=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; upper layer going =
ingress to=20
    egress=20
    <P>use of O-LSP for E-LSP routing. <BR>next step: should be included =
in=20
    multiarea te framework=20
    <P>no questions <BR>no support from floor, take to list=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% draft-imajuku-ml-routing-01.txt=20
    <P>LSR and PXC in same node. Number of links between the two should =
be=20
    <BR>advertised as available resource in the switching capability no=20
    questions <BR>from floor=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Jerry Ash - draft-ash-multi-area-te-compare-00.txt=20
    <P>comparison draft looks at existing proposals, try to converge on =
a=20
    reduced <BR>set=20
    <P>4 main types: <BR>distributed eg kompella scenario 1 <BR>path =
computation=20
    server, PCS, eg kompella scenario 2/4, 5 <BR>interarea summary =
methods=20
    <BR>multiple path comparison=20
    <P>criteria: optimality, scalabilty, resoration, path selection =
performance,=20
    <BR>path selection fuctionality=20
    <P>next steps: discuss options on list for consensus on selected =
method=20
    <BR>if confirmed proceed with pcs, query and crankback exytensions=20
    <P>Yakov: You state that PCS achieves optimal section.&nbsp; How =
much=20
    topology <BR>information does the PCS need?=20
    <P>Ash: Has full-topology of backbone area.=20
    <P>Yakov: Therefore only optimal w.r.t. the backbone area.=20
    <P>Ash: Well it varies.=20
    <P>Yakov: Statement that PCS scales is "interesting".&nbsp; : =
Normally=20
    <BR>distributed approaches scale better.=20
    <P>Ash: Flooding is an issue with distributed schemes.=20
    <P>Yakov: There is also computational load.&nbsp; Box may be a =
bottleneck.=20
    <P>Ash: That does not make it less scalable. [laughter here ]=20
    <P>McDysan: What happens when a router is controlling optical paths =
and=20
    <BR>router goes berserk.&nbsp; Might want to do "stability during=20
    <BR>mismanagement" characterization.&nbsp; Very valuable from SP =
point of=20
    view.=20
    <P>???: Single ISP or multiple ISPs?=20
    <P>Ash: Single ISP.=20
    <P>???: Why is protection hard in different areas?=20
    <P>Ash: Can be done.&nbsp; Much discussion between authors on this.=20
    <P>Kireeti: As a router vendor, I take exception to the comment that =

    <BR>routers are more likely to screw up than OXCs.=20
    <P>Yakov: If you do protection/restoration on a per-area basis, =
then=05=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt=20
    <P>Summarized modifications to document - see presentation.=20
    <P>Note: Remember that this wg id detailed the architecture of the =
GMPLS=20
    <BR>building blocks, but not the detailed semantic of the technology =

    <BR>dependent structures, fields, objects, etc.=20
    <P>Ready for WG last call? About 20.=20
    <P>Bilel: Would be useful to send this to ITU and recommend use of =
GMPLS.=20
    <P>Kireeti: Are you suggesting that we take the document to ITU?=20
    <P>Bilel: Yes.&nbsp; With perhaps an exercise to see if it meets=20
    requirements.=20
    <P>Kireeti: Who thinks that the document is not ready?&nbsp; NONE=20
    <P>Kireeti: Please be diligent is making any comments.&nbsp; Want to =
send to=20
    <BR>ADS and request publications as an informational RFC.=20
    <P>next: meeting to sort out label issue, send updated drafts for =
last=20
    review, <BR>go to iesg last call.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt <BR>% =
Eric=20
    Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt=20
    <P>Presented history and latest changes made.=20
    <P>Next steps - small revisions to drafts (specifically label =
coding) and=20
    <BR>then go to IETF last call.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt =

    <P>Presented history and latest changes made.=20
    <P>Target is informational RFC.&nbsp; Let's have last review and =
last call=20
    <BR>before next IETF.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt=20
    <P>Reviewed document status.&nbsp; Would like WG to adopt working =
item?=20
    <P>SENSE OF ROOM: SUPPORT 10-15.&nbsp; NO OBJECTIONS.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt=20
    <P>Reviewed scenarios in document.&nbsp; Is working group will to =
accept=20
    this <BR>as a WG document?=20
    <P>NO RESPONSE FROM THE ROOM (maybe 3 for, none against).=20
    <P>Ron: Take this item to the mailing list.=20
    <P>Kireeti: How many SPs in the room.&nbsp; 20-25.=20
    <P>Kireeti: How many folks are interested in transport.&nbsp; MOST =
EVERYONE=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Osama Aboul-Magd -- =
draft-aboulmagd-ccamp-call-conn-separation-00.txt.=20

    <P>Draft addresses one of the issues that Tolbridge highlighted in =
his=20
    <BR>talk - call and connection control separation.=20
    <P>Proposal to accept document as a WG item.=20
    <P>Kireeti: There is an explicit statement from ITU requiring this.=20
    <BR>There is nothing in the charter about this.&nbsp; This is good=20
    stuff.&nbsp; Ron <BR>and I will go through a charter revision with =
Ads and=20
    discuss putting <BR>this in the charter.&nbsp; Also need to address =
other=20
    gaps that were raised <BR>by ITU.=20
    <P>Scott: When you propose to add something to WG, it would be =
helpful to=20
    <BR>state where it fits in the existing charter OR how and why =
charter=20
    <BR>should be extended.=20
    <P>Eva: I think that it fits into the character as a requirement to =
the=20
    <BR>signaling protocols.=20
    <P>Scott: OK - that is a good clean explanation that might save =
chairs=20
    <BR>some time.=20
    <P>Yong: I second Eva's comment.=20
    <P>Kireeti: Need to figure out how to address other issues as well.=20
    <BR>Also, MPLS OAM will be discussed in MPLS WG tomorrow.=20
    <P>Osama: What is outcome?=20
    <P>Kireeti: Let's think about this.&nbsp; See about doing same for =
RSVP and=20
    <BR>then move forward.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% John Lang - LMP status (draft -03)=20
    <P>Current status: <BR>&nbsp; - Finished WG last call <BR>&nbsp; - =
Fixed=20
    several edits <BR>&nbsp; - Added text to security considerations=20
    <P>Open Issues: <BR>&nbsp; - Security =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
    currently md5 is defined for LMP authentication=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Another proposal exists in =
draft-sankar=20
    for Ipsec usage <BR>&nbsp; - Make local/remote id different in class =
type=20
    instead of object class=20
    <P>Bert: I raised the local/remote id issue, but there were also =
other=20
    <BR>issues where things could be combined.&nbsp; Did you review =
other parts=20
    of <BR>document as well?=20
    <P>John: We did.&nbsp; Your comment reflects this class, but not =
others.=20
    <P>NO OBJECTIONS TO PROPOSED CHANGES=20
    <P>John Sadler: I have some open issues.&nbsp; Test message and ???. =

    <P>John: Test message was updated based on comments in last call and =

    <BR>should be consistent with OIF work.=20
    <P>John Sadler: Does not talk about control/address fields.&nbsp; Do =
not=20
    talk <BR>about 1662 frame format.=20
    <P>John: We can look at this.=20
    <P>Kireeti: OIF compatibility is not a requirement, but if we get =
that=20
    <BR>for free (or cheap) great.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Tom Nadeau - MIBs for GMPLS=20
    <P>Reviewed status of current documents, minor changes, etc.&nbsp; =
Want=20
    GMPLS <BR>MIBs to be compatible with MPLS MIBs when then become =
RFCs.=20
    <P>Summary: <BR>&nbsp; - Make mpls-tev2 MIB CCAMP (or MPLS) wg =
document=20
    <BR>&nbsp; - Make GMPLS-label MIB CCAMP wg document. <BR>&nbsp; - =
GMPLS-TC=20
    MIB as CCAMP wg document to capture new GMPLS-related TCs. =
<BR>&nbsp; - Drop=20
    GMPLS-LSR MIB (will use as it is including new TC change).=20
    <P>Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?=20
    <P>Tom: New indexing scheme relies on having the label MIB - for =
MPLS=20
    <BR>index is label.&nbsp; For GMPLS there is more stuff in the =
GMPLS-label=20
    MIB.=20
    <P>Kireeti: Need to see new version and then move forward.&nbsp; =
Nice if we=20
    <BR>could decouple them.&nbsp; Will discuss with chairs and Ads =
where this=20
    <BR>should go.=20
    <P>Scott: Seems general, so belongs in CCAMP.=20
    <P>Tolbridge: "general" frequently means more than one thing.=20
    <P>Kireeti: We have "classical" MPLS and non-packet based MPLS.=20
    <BR>Generalized covers both.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling =
and=20
    <BR>restoration=20
    <P>Presented drafts.=20
    <P>Kireeti: Protection group should consider these docs.&nbsp; More=20
    discussion <BR>on the list.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Ron Bonica=20
    <P>Issues: <BR>&nbsp; - Should we define protocols yet? <BR>&nbsp; - =
IP=20
    centric VS Tunnel Centric tools=20
    <P>We need a tool that tells us about the IP layer and the tunnels =
that=20
    <BR>support it.&nbsp; IP network may be supported by multiple types =
of=20
    tunnels <BR>- don't want separate tools for each type.=20
    <P>Proposal - adopt tunnel tracing requirements as a wg document.=20
    <BR>Continue work on protocol specification.&nbsp; Orthogonal to any =
open=20
    <BR>discussions about MPLS OAM.=20
    <P>Kireeti: Discussion to list.=20
    <P>???: Is the proposal to accept a new (03) draft that incorporates =

    <BR>comments from the list.=20
    <P>Ron: not the intention.&nbsp; Accepting the doc just means that =
it is a=20
    <BR>good enough starting point and we can spin revs later.=20
    =
<P>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
=20
    <BR>% Dimitri - protection and restoration=20
    <P>Will submit draft as an individual ID.&nbsp; Want comments from =
the list.=20

    <P>Kireeti: Thanks.=20
    =
<P>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <BR>Ronald P.=20
    Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ph: 703 886 1681 <BR>vBNS =

    Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; page: 1 888 268 8021 =

    <BR>Ashburn, Va. =
<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <BR>"Not=20
    all who wander are lost."=20
    =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    -- J.R.R. Tolkien</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_F+QXrvtPWqlTFzj4dOBxpQ)--

Delivery-date: Mon, 08 Apr 2002 14:21:06 -0700
Date: Mon, 08 Apr 2002 17:23:07 -0400
From: Eve Varma <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 53 CCAMP Minutes

--------------BB629C23F06C9C85070A54DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Per your request from further down within the text - "can we supplement with
other copy of the minutes", here are some of my notes.

Cheers,
    Eve

--------------------------------------------------------------------
Call for Design Team for GMPLS Profile for ASON/ASTN

ITU-T Liaison
Steve Trowbridge provided a report of the work of ITU-T Q14, as well as from Q11
identifying the areas that need further work, as outlined in the liaison to the
IETF.  He also reviewed the Detector Controller Interface, clarifying this is
over and above the actual payload.  It's the view of the anomalies and detectors
from a control plane perspective, and identified the key information flows to be
communicated across this interface.

Eric Mannie indicated that these gaps are very small, and were on their way to
being solved.  He asked if these were all the gaps?  Steve said this doesn't mean
that there wouldn't be something else identified, but would like to see
disconnects addressed and resolved.

Dimitrios Pendarakis said the issue here is that the ITU-T has a set of
requirements preceding this work, and have had some preliminary discussions.
Many are more clarification and applicability.  However, there may be some areas
where some additional work might be involved.  The IETF gained alot from the OIF
experience, and he suggested this would be a good opportunity with the ITU-T as
well.

Yong Xue said the ITU-T is now working on version 2 of the document (G.7713), and
should be considered.

Eve Varma provided a clarification that this was really for G.7713.2 (GMPLS
RSVP-TE), though in the future as the G.7713 (protocol-neutral) capability set
expands, the protocols may also need extension
-----------------------------------------------------------------------

Ron Bonica wrote:

> Folks,
>
> Minutes from our last meeting follow. Please review and comment.
>
>                                           Ron
>
> CCAMP Minutes
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Kireeti Kompella - Status Update
>
> Draft Status Update
>
> generalized signalling - finished last call,have implementation status,
> ready for ietf last call
>
> call for consensus to send to ietf last call:
>         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  informational
>                                 -architecture-02.txt  informational
>                                 -ccamp-sdhsonet-control-00.txt  informational
>
> Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a
> working group document?
>
> NO OBJECTIONS
>
> Kireeti: There was a call for design team for "GMPLS profile for ason/astn"
>
> Tolbridge: g709 framework was going to go back to the ITU to produce
> ".g.709 for dummies".  Have not met yet.
>
> Kireeti: happy to remove from plate of CCAMP if ITU will handle.
>
> Osama: we have a draft at ITU-T that is a wg document
>
> Kireeti: need a more concise statement from ITU
>
> Kireeti: If you have any comments on the documents
> (additions/subtractions/etc.), please post to the list.
>
> Kireeti: there will be a charter update at some point
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Steve Tolbridge
>
> Wasam Alanqar is liaison to ITU-T SG 15.
>
> (2) communications to IETF CCAMP
>   - signaling protocol work in Q14.15
>   - detector-controller interface (DCI) from Q.11/15
>
> See proceedings for URLs that show location of docs.
>
> Documents sent to IETF from Q14.15
>   - PNNI-based signaling
>   - GMPLS RSVP-TE based signaling
>   - GMPLS CR-LDP based signaling
>
> Outlined a variety of "gaps" in the current work:
>   - Call and connection separation
>   - Additional error codes/value
>   - Restart mechanisms
>   - Support for crankback
>   - Support for soft permanent connection
>
> See proceedings for details.
>
> Eric Mannie: Referring to slide "Identified Gaps".  Gaps seem to be
> very small.  Most of the points are solved, can be easily solved, or
> are in the process of being solved.
>
> Tolbridge: This was a preliminary scan.  Further review, might turn up
> more issues.  Technologies are similar, so lets identify and minimize
> gaps.
>
> Dimitri: ITU requirements precede much of IETF work.  Preliminary
> discussions indicate that the current gaps are covered by existing
> protocol work.  Areas where additional work will be required are
> probably minimal, but need to be looked at.  IETF may gain final
> improvements by looking at ITU work.
>
> Yong Xue: ITU is working on v2 ASON document so more things could turn
> up as "gaps".  Further communication between ITU and IETF should
> continue.
>
> Tolbridge: Technology will evolve within both organizations.  Should
> expend effort to make sure that they evolve together.
>
> Eva: ??? what was the point ???
>
> [ can we supplement with other copy of the minutes ]
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Lou Berger
>
> www.labn.net/gmpls-survey/...
>
> 17 organisations responded, mostly equipment vendors
> 1 provider
> about 50% are independent implementation
>
> charts no. of implementations as a function of feature
> 17 gen label and bw encoding
> 12 sonet/sdh label and traffic parameters
> 17 bidir lsps
> ...
>
> no questions
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Eric Mannie - gmpls recovery terminology
>
> Eric provided overview of terminology draft.  Draft covers:
>   - LSP protection and restoration
>   - LSPs controlled by a GMPLS control place
>   - End-to-end segment and span recovery
>
> Kireeti: Please send comments to list about whether or not this should
> be a wg document. Sense of room:
>
> About 20 have read document - all agree that this is a wg document.
>
> Yong: All carriers have a different definition of
> protection/restoration.  We need more carriers involved in the
> process.  IP and transport folks rarely have the same perspective.
>
> Kireeti: SP input came from TE WG and the SP representative on the
> design team (KPNQwest).  Point is well-taken.  Carriers please make
> comments.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Chen Lee - "Exclude Routes"
>
> Draft defines a new RSVP-TE object that allows specification of
> intermediate "objects" to avoid - avoid highly utilized nodes/ASs.
>
> Wanted wg consensus on definition of this object.  Current draft does
> !(A,B,C,D), but do we need to support (A, !B, !C, D).
>
> Yakov: Regarding slide "application inter-area".  As far as I
> understand, you want to exclude certain routers/links.  What is
> purpose of excluding links?  If you just specify a link, what does
> that do?
>
> Lee: You may want 
>
> Yakov: If you just want link diversity, then you want SLRGs, not links.
>
> Yakov: Regarding "application - avoid highly utilized node/as".  Why
> do this? Why not explicit route A, B, E, F?
>
> Lee: What if you just know what you don't want, but know explicit route.
>
> Kireeti: One of the issues.  When you do explicit routing with loose
> hops, this is very similar.  However, don't want to do TE
> node-by-node.  Want head-end or offline computations, not hop-by-hop
> TE. The point is not to overload RSVP-TE with all of this information
> - don't want to do this computation during the signaling process
> anyway.
>
> Ron: Take discussion to lists.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % draft-shiomoto-ccamp-multiarea-te-00.txt
>
> hierarchical lsps for multiarea te
>         lowr layer for abr-abr
>         upper layer going ingress to egress
>
> use of O-LSP for E-LSP routing.
> next step: should be included in multiarea te framework
>
> no questions
> no support from floor, take to list
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % draft-imajuku-ml-routing-01.txt
>
> LSR and PXC in same node. Number of links between the two should be
> advertised as available resource in the switching capability no questions
> from floor
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Jerry Ash - draft-ash-multi-area-te-compare-00.txt
>
> comparison draft looks at existing proposals, try to converge on a reduced
> set
>
> 4 main types:
> distributed eg kompella scenario 1
> path computation server, PCS, eg kompella scenario 2/4, 5
> interarea summary methods
> multiple path comparison
>
> criteria: optimality, scalabilty, resoration, path selection performance,
> path selection fuctionality
>
> next steps: discuss options on list for consensus on selected method
> if confirmed proceed with pcs, query and crankback exytensions
>
> Yakov: You state that PCS achieves optimal section.  How much topology
> information does the PCS need?
>
> Ash: Has full-topology of backbone area.
>
> Yakov: Therefore only optimal w.r.t. the backbone area.
>
> Ash: Well it varies.
>
> Yakov: Statement that PCS scales is "interesting".  : Normally
> distributed approaches scale better.
>
> Ash: Flooding is an issue with distributed schemes.
>
> Yakov: There is also computational load.  Box may be a bottleneck.
>
> Ash: That does not make it less scalable. [laughter here ]
>
> McDysan: What happens when a router is controlling optical paths and
> router goes berserk.  Might want to do "stability during
> mismanagement" characterization.  Very valuable from SP point of view.
>
> ???: Single ISP or multiple ISPs?
>
> Ash: Single ISP.
>
> ???: Why is protection hard in different areas?
>
> Ash: Can be done.  Much discussion between authors on this.
>
> Kireeti: As a router vendor, I take exception to the comment that
> routers are more likely to screw up than OXCs.
>
> Yakov: If you do protection/restoration on a per-area basis, then
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt
>
> Summarized modifications to document - see presentation.
>
> Note: Remember that this wg id detailed the architecture of the GMPLS
> building blocks, but not the detailed semantic of the technology
> dependent structures, fields, objects, etc.
>
> Ready for WG last call? About 20.
>
> Bilel: Would be useful to send this to ITU and recommend use of GMPLS.
>
> Kireeti: Are you suggesting that we take the document to ITU?
>
> Bilel: Yes.  With perhaps an exercise to see if it meets requirements.
>
> Kireeti: Who thinks that the document is not ready?  NONE
>
> Kireeti: Please be diligent is making any comments.  Want to send to
> ADS and request publications as an informational RFC.
>
> next: meeting to sort out label issue, send updated drafts for last review,
> go to iesg last call.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
> % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
>
> Presented history and latest changes made.
>
> Next steps - small revisions to drafts (specifically label coding) and
> then go to IETF last call.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt
>
> Presented history and latest changes made.
>
> Target is informational RFC.  Let's have last review and last call
> before next IETF.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt
>
> Reviewed document status.  Would like WG to adopt working item?
>
> SENSE OF ROOM: SUPPORT 10-15.  NO OBJECTIONS.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt
>
> Reviewed scenarios in document.  Is working group will to accept this
> as a WG document?
>
> NO RESPONSE FROM THE ROOM (maybe 3 for, none against).
>
> Ron: Take this item to the mailing list.
>
> Kireeti: How many SPs in the room.  20-25.
>
> Kireeti: How many folks are interested in transport.  MOST EVERYONE
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.
>
> Draft addresses one of the issues that Tolbridge highlighted in his
> talk - call and connection control separation.
>
> Proposal to accept document as a WG item.
>
> Kireeti: There is an explicit statement from ITU requiring this.
> There is nothing in the charter about this.  This is good stuff.  Ron
> and I will go through a charter revision with Ads and discuss putting
> this in the charter.  Also need to address other gaps that were raised
> by ITU.
>
> Scott: When you propose to add something to WG, it would be helpful to
> state where it fits in the existing charter OR how and why charter
> should be extended.
>
> Eva: I think that it fits into the character as a requirement to the
> signaling protocols.
>
> Scott: OK - that is a good clean explanation that might save chairs
> some time.
>
> Yong: I second Eva's comment.
>
> Kireeti: Need to figure out how to address other issues as well.
> Also, MPLS OAM will be discussed in MPLS WG tomorrow.
>
> Osama: What is outcome?
>
> Kireeti: Let's think about this.  See about doing same for RSVP and
> then move forward.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % John Lang - LMP status (draft -03)
>
> Current status:
>   - Finished WG last call
>   - Fixed several edits
>   - Added text to security considerations
>
> Open Issues:
>   - Security
>       - currently md5 is defined for LMP authentication
>       - Another proposal exists in draft-sankar for Ipsec usage
>   - Make local/remote id different in class type instead of object class
>
> Bert: I raised the local/remote id issue, but there were also other
> issues where things could be combined.  Did you review other parts of
> document as well?
>
> John: We did.  Your comment reflects this class, but not others.
>
> NO OBJECTIONS TO PROPOSED CHANGES
>
> John Sadler: I have some open issues.  Test message and ???.
>
> John: Test message was updated based on comments in last call and
> should be consistent with OIF work.
>
> John Sadler: Does not talk about control/address fields.  Do not talk
> about 1662 frame format.
>
> John: We can look at this.
>
> Kireeti: OIF compatibility is not a requirement, but if we get that
> for free (or cheap) great.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Tom Nadeau - MIBs for GMPLS
>
> Reviewed status of current documents, minor changes, etc.  Want GMPLS
> MIBs to be compatible with MPLS MIBs when then become RFCs.
>
> Summary:
>   - Make mpls-tev2 MIB CCAMP (or MPLS) wg document
>   - Make GMPLS-label MIB CCAMP wg document.
>   - GMPLS-TC MIB as CCAMP wg document to capture new GMPLS-related TCs.
>   - Drop GMPLS-LSR MIB (will use as it is including new TC change).
>
> Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?
>
> Tom: New indexing scheme relies on having the label MIB - for MPLS
> index is label.  For GMPLS there is more stuff in the GMPLS-label MIB.
>
> Kireeti: Need to see new version and then move forward.  Nice if we
> could decouple them.  Will discuss with chairs and Ads where this
> should go.
>
> Scott: Seems general, so belongs in CCAMP.
>
> Tolbridge: "general" frequently means more than one thing.
>
> Kireeti: We have "classical" MPLS and non-packet based MPLS.
> Generalized covers both.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling and
> restoration
>
> Presented drafts.
>
> Kireeti: Protection group should consider these docs.  More discussion
> on the list.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Ron Bonica
>
> Issues:
>   - Should we define protocols yet?
>   - IP centric VS Tunnel Centric tools
>
> We need a tool that tells us about the IP layer and the tunnels that
> support it.  IP network may be supported by multiple types of tunnels
> - don't want separate tools for each type.
>
> Proposal - adopt tunnel tracing requirements as a wg document.
> Continue work on protocol specification.  Orthogonal to any open
> discussions about MPLS OAM.
>
> Kireeti: Discussion to list.
>
> ???: Is the proposal to accept a new (03) draft that incorporates
> comments from the list.
>
> Ron: not the intention.  Accepting the doc just means that it is a
> good enough starting point and we can spin revs later.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> % Dimitri - protection and restoration
>
> Will submit draft as an individual ID.  Want comments from the list.
>
> Kireeti: Thanks.
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "Not all who wander are lost."
>                 -- J.R.R. Tolkien

--------------BB629C23F06C9C85070A54DE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>Per your request from further down within the text - "can we supplement
with other copy of the minutes", here are some of my notes.
<p>Cheers,
<br>&nbsp;&nbsp;&nbsp; Eve
<p>--------------------------------------------------------------------
<br><u>Call for Design Team for GMPLS Profile for ASON/ASTN</u>
<p><i>ITU-T Liaison</i>
<br>Steve Trowbridge provided a report of the work of ITU-T Q14, as well
as from Q11 identifying the areas that need further work, as outlined in
the liaison to the IETF.&nbsp; He also reviewed the Detector Controller
Interface, clarifying this is over and above the actual payload.&nbsp;
It's the view of the anomalies and detectors from a control plane perspective,
and identified the key information flows to be communicated across this
interface.
<p>Eric Mannie indicated that these gaps are very small, and were on their
way to being solved.&nbsp; He asked if these were all the gaps?&nbsp; Steve
said this doesn't mean that there wouldn't be something else identified,
but would like to see disconnects addressed and resolved.
<p>Dimitrios Pendarakis said the issue here is that the ITU-T has a set
of requirements preceding this work, and have had some preliminary discussions.&nbsp;
Many are more clarification and applicability.&nbsp; However, there may
be some areas where some additional work might be involved.&nbsp; The IETF
gained alot from the OIF experience, and he suggested this would be a good
opportunity with the ITU-T as well.
<p>Yong Xue said the ITU-T is now working on version 2 of the document
(G.7713), and should be considered.
<p>Eve Varma provided a clarification that this was really for G.7713.2
(GMPLS RSVP-TE), though in the future as the G.7713 (protocol-neutral)
capability set expands, the protocols may also need extension
<br>-----------------------------------------------------------------------
<br>&nbsp;
<p>Ron Bonica wrote:
<blockquote TYPE=CITE>Folks,
<p>Minutes from our last meeting follow. Please review and comment.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ron
<p>CCAMP Minutes
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Kireeti Kompella - Status Update
<p>Draft Status Update
<p>generalized signalling - finished last call,have implementation status,
<br>ready for ietf last call
<p>call for consensus to send to ietf last call:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt&nbsp;
informational
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-architecture-02.txt&nbsp; informational
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-ccamp-sdhsonet-control-00.txt&nbsp; informational
<p>Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a
<br>working group document?
<p>NO OBJECTIONS
<p>Kireeti: There was a call for design team for "GMPLS profile for ason/astn"
<p>Tolbridge: g709 framework was going to go back to the ITU to produce
<br>".g.709 for dummies".&nbsp; Have not met yet.
<p>Kireeti: happy to remove from plate of CCAMP if ITU will handle.
<p>Osama: we have a draft at ITU-T that is a wg document
<p>Kireeti: need a more concise statement from ITU
<p>Kireeti: If you have any comments on the documents
<br>(additions/subtractions/etc.), please post to the list.
<p>Kireeti: there will be a charter update at some point
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Steve Tolbridge
<p>Wasam Alanqar is liaison to ITU-T SG 15.
<p>(2) communications to IETF CCAMP
<br>&nbsp; - signaling protocol work in Q14.15
<br>&nbsp; - detector-controller interface (DCI) from Q.11/15
<p>See proceedings for URLs that show location of docs.
<p>Documents sent to IETF from Q14.15
<br>&nbsp; - PNNI-based signaling
<br>&nbsp; - GMPLS RSVP-TE based signaling
<br>&nbsp; - GMPLS CR-LDP based signaling
<p>Outlined a variety of "gaps" in the current work:
<br>&nbsp; - Call and connection separation
<br>&nbsp; - Additional error codes/value
<br>&nbsp; - Restart mechanisms
<br>&nbsp; - Support for crankback
<br>&nbsp; - Support for soft permanent connection
<p>See proceedings for details.
<p>Eric Mannie: Referring to slide "Identified Gaps".&nbsp; Gaps seem to
be
<br>very small.&nbsp; Most of the points are solved, can be easily solved,
or
<br>are in the process of being solved.
<p>Tolbridge: This was a preliminary scan.&nbsp; Further review, might
turn up
<br>more issues.&nbsp; Technologies are similar, so lets identify and minimize
<br>gaps.
<p>Dimitri: ITU requirements precede much of IETF work.&nbsp; Preliminary
<br>discussions indicate that the current gaps are covered by existing
<br>protocol work.&nbsp; Areas where additional work will be required are
<br>probably minimal, but need to be looked at.&nbsp; IETF may gain final
<br>improvements by looking at ITU work.
<p>Yong Xue: ITU is working on v2 ASON document so more things could turn
<br>up as "gaps".&nbsp; Further communication between ITU and IETF should
<br>continue.
<p>Tolbridge: Technology will evolve within both organizations.&nbsp; Should
<br>expend effort to make sure that they evolve together.
<p>Eva: ??? what was the point ???
<p>[ can we supplement with other copy of the minutes ]
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Lou Berger
<p>www.labn.net/gmpls-survey/...
<p>17 organisations responded, mostly equipment vendors
<br>1 provider
<br>about 50% are independent implementation
<p>charts no. of implementations as a function of feature
<br>17 gen label and bw encoding
<br>12 sonet/sdh label and traffic parameters
<br>17 bidir lsps
<br>...
<p>no questions
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Eric Mannie - gmpls recovery terminology
<p>Eric provided overview of terminology draft.&nbsp; Draft covers:
<br>&nbsp; - LSP protection and restoration
<br>&nbsp; - LSPs controlled by a GMPLS control place
<br>&nbsp; - End-to-end segment and span recovery
<p>Kireeti: Please send comments to list about whether or not this should
<br>be a wg document. Sense of room:
<p>About 20 have read document - all agree that this is a wg document.
<p>Yong: All carriers have a different definition of
<br>protection/restoration.&nbsp; We need more carriers involved in the
<br>process.&nbsp; IP and transport folks rarely have the same perspective.
<p>Kireeti: SP input came from TE WG and the SP representative on the
<br>design team (KPNQwest).&nbsp; Point is well-taken.&nbsp; Carriers please
make
<br>comments.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Chen Lee - "Exclude Routes"
<p>Draft defines a new RSVP-TE object that allows specification of
<br>intermediate "objects" to avoid - avoid highly utilized nodes/ASs.
<p>Wanted wg consensus on definition of this object.&nbsp; Current draft
does
<br>!(A,B,C,D), but do we need to support (A, !B, !C, D).
<p>Yakov: Regarding slide "application inter-area".&nbsp; As far as I
<br>understand, you want to exclude certain routers/links.&nbsp; What is
<br>purpose of excluding links?&nbsp; If you just specify a link, what
does
<br>that do?
<p>Lee: You may want 
<p>Yakov: If you just want link diversity, then you want SLRGs, not links.
<p>Yakov: Regarding "application - avoid highly utilized node/as".&nbsp;
Why
<br>do this? Why not explicit route A, B, E, F?
<p>Lee: What if you just know what you don't want, but know explicit route.
<p>Kireeti: One of the issues.&nbsp; When you do explicit routing with
loose
<br>hops, this is very similar.&nbsp; However, don't want to do TE
<br>node-by-node.&nbsp; Want head-end or offline computations, not hop-by-hop
<br>TE. The point is not to overload RSVP-TE with all of this information
<br>- don't want to do this computation during the signaling process
<br>anyway.
<p>Ron: Take discussion to lists.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% draft-shiomoto-ccamp-multiarea-te-00.txt
<p>hierarchical lsps for multiarea te
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lowr layer for abr-abr
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; upper layer going ingress
to egress
<p>use of O-LSP for E-LSP routing.
<br>next step: should be included in multiarea te framework
<p>no questions
<br>no support from floor, take to list
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% draft-imajuku-ml-routing-01.txt
<p>LSR and PXC in same node. Number of links between the two should be
<br>advertised as available resource in the switching capability no questions
<br>from floor
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Jerry Ash - draft-ash-multi-area-te-compare-00.txt
<p>comparison draft looks at existing proposals, try to converge on a reduced
<br>set
<p>4 main types:
<br>distributed eg kompella scenario 1
<br>path computation server, PCS, eg kompella scenario 2/4, 5
<br>interarea summary methods
<br>multiple path comparison
<p>criteria: optimality, scalabilty, resoration, path selection performance,
<br>path selection fuctionality
<p>next steps: discuss options on list for consensus on selected method
<br>if confirmed proceed with pcs, query and crankback exytensions
<p>Yakov: You state that PCS achieves optimal section.&nbsp; How much topology
<br>information does the PCS need?
<p>Ash: Has full-topology of backbone area.
<p>Yakov: Therefore only optimal w.r.t. the backbone area.
<p>Ash: Well it varies.
<p>Yakov: Statement that PCS scales is "interesting".&nbsp; : Normally
<br>distributed approaches scale better.
<p>Ash: Flooding is an issue with distributed schemes.
<p>Yakov: There is also computational load.&nbsp; Box may be a bottleneck.
<p>Ash: That does not make it less scalable. [laughter here ]
<p>McDysan: What happens when a router is controlling optical paths and
<br>router goes berserk.&nbsp; Might want to do "stability during
<br>mismanagement" characterization.&nbsp; Very valuable from SP point
of view.
<p>???: Single ISP or multiple ISPs?
<p>Ash: Single ISP.
<p>???: Why is protection hard in different areas?
<p>Ash: Can be done.&nbsp; Much discussion between authors on this.
<p>Kireeti: As a router vendor, I take exception to the comment that
<br>routers are more likely to screw up than OXCs.
<p>Yakov: If you do protection/restoration on a per-area basis, then
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt
<p>Summarized modifications to document - see presentation.
<p>Note: Remember that this wg id detailed the architecture of the GMPLS
<br>building blocks, but not the detailed semantic of the technology
<br>dependent structures, fields, objects, etc.
<p>Ready for WG last call? About 20.
<p>Bilel: Would be useful to send this to ITU and recommend use of GMPLS.
<p>Kireeti: Are you suggesting that we take the document to ITU?
<p>Bilel: Yes.&nbsp; With perhaps an exercise to see if it meets requirements.
<p>Kireeti: Who thinks that the document is not ready?&nbsp; NONE
<p>Kireeti: Please be diligent is making any comments.&nbsp; Want to send
to
<br>ADS and request publications as an informational RFC.
<p>next: meeting to sort out label issue, send updated drafts for last
review,
<br>go to iesg last call.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
<br>% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt
<p>Presented history and latest changes made.
<p>Next steps - small revisions to drafts (specifically label coding) and
<br>then go to IETF last call.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt
<p>Presented history and latest changes made.
<p>Target is informational RFC.&nbsp; Let's have last review and last call
<br>before next IETF.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt
<p>Reviewed document status.&nbsp; Would like WG to adopt working item?
<p>SENSE OF ROOM: SUPPORT 10-15.&nbsp; NO OBJECTIONS.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt
<p>Reviewed scenarios in document.&nbsp; Is working group will to accept
this
<br>as a WG document?
<p>NO RESPONSE FROM THE ROOM (maybe 3 for, none against).
<p>Ron: Take this item to the mailing list.
<p>Kireeti: How many SPs in the room.&nbsp; 20-25.
<p>Kireeti: How many folks are interested in transport.&nbsp; MOST EVERYONE
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.
<p>Draft addresses one of the issues that Tolbridge highlighted in his
<br>talk - call and connection control separation.
<p>Proposal to accept document as a WG item.
<p>Kireeti: There is an explicit statement from ITU requiring this.
<br>There is nothing in the charter about this.&nbsp; This is good stuff.&nbsp;
Ron
<br>and I will go through a charter revision with Ads and discuss putting
<br>this in the charter.&nbsp; Also need to address other gaps that were
raised
<br>by ITU.
<p>Scott: When you propose to add something to WG, it would be helpful
to
<br>state where it fits in the existing charter OR how and why charter
<br>should be extended.
<p>Eva: I think that it fits into the character as a requirement to the
<br>signaling protocols.
<p>Scott: OK - that is a good clean explanation that might save chairs
<br>some time.
<p>Yong: I second Eva's comment.
<p>Kireeti: Need to figure out how to address other issues as well.
<br>Also, MPLS OAM will be discussed in MPLS WG tomorrow.
<p>Osama: What is outcome?
<p>Kireeti: Let's think about this.&nbsp; See about doing same for RSVP
and
<br>then move forward.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% John Lang - LMP status (draft -03)
<p>Current status:
<br>&nbsp; - Finished WG last call
<br>&nbsp; - Fixed several edits
<br>&nbsp; - Added text to security considerations
<p>Open Issues:
<br>&nbsp; - Security
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - currently md5 is defined for LMP authentication
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Another proposal exists in draft-sankar
for Ipsec usage
<br>&nbsp; - Make local/remote id different in class type instead of object
class
<p>Bert: I raised the local/remote id issue, but there were also other
<br>issues where things could be combined.&nbsp; Did you review other parts
of
<br>document as well?
<p>John: We did.&nbsp; Your comment reflects this class, but not others.
<p>NO OBJECTIONS TO PROPOSED CHANGES
<p>John Sadler: I have some open issues.&nbsp; Test message and ???.
<p>John: Test message was updated based on comments in last call and
<br>should be consistent with OIF work.
<p>John Sadler: Does not talk about control/address fields.&nbsp; Do not
talk
<br>about 1662 frame format.
<p>John: We can look at this.
<p>Kireeti: OIF compatibility is not a requirement, but if we get that
<br>for free (or cheap) great.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Tom Nadeau - MIBs for GMPLS
<p>Reviewed status of current documents, minor changes, etc.&nbsp; Want
GMPLS
<br>MIBs to be compatible with MPLS MIBs when then become RFCs.
<p>Summary:
<br>&nbsp; - Make mpls-tev2 MIB CCAMP (or MPLS) wg document
<br>&nbsp; - Make GMPLS-label MIB CCAMP wg document.
<br>&nbsp; - GMPLS-TC MIB as CCAMP wg document to capture new GMPLS-related
TCs.
<br>&nbsp; - Drop GMPLS-LSR MIB (will use as it is including new TC change).
<p>Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?
<p>Tom: New indexing scheme relies on having the label MIB - for MPLS
<br>index is label.&nbsp; For GMPLS there is more stuff in the GMPLS-label
MIB.
<p>Kireeti: Need to see new version and then move forward.&nbsp; Nice if
we
<br>could decouple them.&nbsp; Will discuss with chairs and Ads where this
<br>should go.
<p>Scott: Seems general, so belongs in CCAMP.
<p>Tolbridge: "general" frequently means more than one thing.
<p>Kireeti: We have "classical" MPLS and non-packet based MPLS.
<br>Generalized covers both.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling and
<br>restoration
<p>Presented drafts.
<p>Kireeti: Protection group should consider these docs.&nbsp; More discussion
<br>on the list.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Ron Bonica
<p>Issues:
<br>&nbsp; - Should we define protocols yet?
<br>&nbsp; - IP centric VS Tunnel Centric tools
<p>We need a tool that tells us about the IP layer and the tunnels that
<br>support it.&nbsp; IP network may be supported by multiple types of
tunnels
<br>- don't want separate tools for each type.
<p>Proposal - adopt tunnel tracing requirements as a wg document.
<br>Continue work on protocol specification.&nbsp; Orthogonal to any open
<br>discussions about MPLS OAM.
<p>Kireeti: Discussion to list.
<p>???: Is the proposal to accept a new (03) draft that incorporates
<br>comments from the list.
<p>Ron: not the intention.&nbsp; Accepting the doc just means that it is
a
<br>good enough starting point and we can spin revs later.
<p>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>% Dimitri - protection and restoration
<p>Will submit draft as an individual ID.&nbsp; Want comments from the
list.
<p>Kireeti: Thanks.
<p>===========================================
<br>Ronald P. Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ph: 703 886 1681
<br>vBNS Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; page: 1 888 268
8021
<br>Ashburn, Va.
<br>===========================================
<br>"Not all who wander are lost."
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-- J.R.R. Tolkien</blockquote>
</html>

--------------BB629C23F06C9C85070A54DE--

Delivery-date: Sun, 07 Apr 2002 18:29:14 -0700
Date: Sun, 07 Apr 2002 21:17:44 -0400
From: Ron Bonica <[email-masked]>
Subject: IETF 53 CCAMP Minutes
To: [email-masked]

Folks,

Minutes from our last meeting follow. Please review and comment.

                                          Ron

CCAMP Minutes

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Kireeti Kompella - Status Update

Draft Status Update

generalized signalling - finished last call,have implementation status,
ready for ietf last call

call for consensus to send to ietf last call:
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  informational
				-architecture-02.txt  informational
				-ccamp-sdhsonet-control-00.txt  informational

Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a
working group document?

NO OBJECTIONS

Kireeti: There was a call for design team for "GMPLS profile for ason/astn"

Tolbridge: g709 framework was going to go back to the ITU to produce
".g.709 for dummies".  Have not met yet.

Kireeti: happy to remove from plate of CCAMP if ITU will handle.

Osama: we have a draft at ITU-T that is a wg document

Kireeti: need a more concise statement from ITU

Kireeti: If you have any comments on the documents
(additions/subtractions/etc.), please post to the list.

Kireeti: there will be a charter update at some point

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Steve Tolbridge

Wasam Alanqar is liaison to ITU-T SG 15.

(2) communications to IETF CCAMP
  - signaling protocol work in Q14.15
  - detector-controller interface (DCI) from Q.11/15

See proceedings for URLs that show location of docs.

Documents sent to IETF from Q14.15
  - PNNI-based signaling
  - GMPLS RSVP-TE based signaling
  - GMPLS CR-LDP based signaling

Outlined a variety of "gaps" in the current work:
  - Call and connection separation
  - Additional error codes/value
  - Restart mechanisms
  - Support for crankback
  - Support for soft permanent connection

See proceedings for details.

Eric Mannie: Referring to slide "Identified Gaps".  Gaps seem to be
very small.  Most of the points are solved, can be easily solved, or
are in the process of being solved.

Tolbridge: This was a preliminary scan.  Further review, might turn up
more issues.  Technologies are similar, so lets identify and minimize
gaps.

Dimitri: ITU requirements precede much of IETF work.  Preliminary
discussions indicate that the current gaps are covered by existing
protocol work.  Areas where additional work will be required are
probably minimal, but need to be looked at.  IETF may gain final
improvements by looking at ITU work.

Yong Xue: ITU is working on v2 ASON document so more things could turn
up as "gaps".  Further communication between ITU and IETF should
continue.

Tolbridge: Technology will evolve within both organizations.  Should
expend effort to make sure that they evolve together.

Eva: ??? what was the point ???

[ can we supplement with other copy of the minutes ]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Lou Berger

www.labn.net/gmpls-survey/...

17 organisations responded, mostly equipment vendors
1 provider
about 50% are independent implementation

charts no. of implementations as a function of feature
17 gen label and bw encoding
12 sonet/sdh label and traffic parameters
17 bidir lsps
...

no questions

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie - gmpls recovery terminology

Eric provided overview of terminology draft.  Draft covers:
  - LSP protection and restoration
  - LSPs controlled by a GMPLS control place
  - End-to-end segment and span recovery

Kireeti: Please send comments to list about whether or not this should
be a wg document. Sense of room:

About 20 have read document - all agree that this is a wg document.

Yong: All carriers have a different definition of
protection/restoration.  We need more carriers involved in the
process.  IP and transport folks rarely have the same perspective.

Kireeti: SP input came from TE WG and the SP representative on the
design team (KPNQwest).  Point is well-taken.  Carriers please make
comments.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Chen Lee - "Exclude Routes"

Draft defines a new RSVP-TE object that allows specification of
intermediate "objects" to avoid - avoid highly utilized nodes/ASs.

Wanted wg consensus on definition of this object.  Current draft does
!(A,B,C,D), but do we need to support (A, !B, !C, D).

Yakov: Regarding slide "application inter-area".  As far as I
understand, you want to exclude certain routers/links.  What is
purpose of excluding links?  If you just specify a link, what does
that do?

Lee: You may want 

Yakov: If you just want link diversity, then you want SLRGs, not links.

Yakov: Regarding "application - avoid highly utilized node/as".  Why
do this? Why not explicit route A, B, E, F?

Lee: What if you just know what you don't want, but know explicit route.

Kireeti: One of the issues.  When you do explicit routing with loose
hops, this is very similar.  However, don't want to do TE
node-by-node.  Want head-end or offline computations, not hop-by-hop
TE. The point is not to overload RSVP-TE with all of this information
- don't want to do this computation during the signaling process
anyway.

Ron: Take discussion to lists.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% draft-shiomoto-ccamp-multiarea-te-00.txt

hierarchical lsps for multiarea te
	lowr layer for abr-abr
	upper layer going ingress to egress

use of O-LSP for E-LSP routing.
next step: should be included in multiarea te framework

no questions
no support from floor, take to list

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% draft-imajuku-ml-routing-01.txt

LSR and PXC in same node. Number of links between the two should be
advertised as available resource in the switching capability no questions
from floor

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Jerry Ash - draft-ash-multi-area-te-compare-00.txt

comparison draft looks at existing proposals, try to converge on a reduced
set

4 main types:
distributed eg kompella scenario 1
path computation server, PCS, eg kompella scenario 2/4, 5
interarea summary methods
multiple path comparison

criteria: optimality, scalabilty, resoration, path selection performance,
path selection fuctionality

next steps: discuss options on list for consensus on selected method
if confirmed proceed with pcs, query and crankback exytensions

Yakov: You state that PCS achieves optimal section.  How much topology
information does the PCS need?

Ash: Has full-topology of backbone area.

Yakov: Therefore only optimal w.r.t. the backbone area.

Ash: Well it varies.

Yakov: Statement that PCS scales is "interesting".  : Normally
distributed approaches scale better.

Ash: Flooding is an issue with distributed schemes.

Yakov: There is also computational load.  Box may be a bottleneck.

Ash: That does not make it less scalable. [laughter here ]

McDysan: What happens when a router is controlling optical paths and
router goes berserk.  Might want to do "stability during
mismanagement" characterization.  Very valuable from SP point of view.

???: Single ISP or multiple ISPs?

Ash: Single ISP.

???: Why is protection hard in different areas?

Ash: Can be done.  Much discussion between authors on this.

Kireeti: As a router vendor, I take exception to the comment that
routers are more likely to screw up than OXCs.

Yakov: If you do protection/restoration on a per-area basis, then

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt

Summarized modifications to document - see presentation.

Note: Remember that this wg id detailed the architecture of the GMPLS
building blocks, but not the detailed semantic of the technology
dependent structures, fields, objects, etc.

Ready for WG last call? About 20.

Bilel: Would be useful to send this to ITU and recommend use of GMPLS.

Kireeti: Are you suggesting that we take the document to ITU?

Bilel: Yes.  With perhaps an exercise to see if it meets requirements.

Kireeti: Who thinks that the document is not ready?  NONE

Kireeti: Please be diligent is making any comments.  Want to send to
ADS and request publications as an informational RFC.

next: meeting to sort out label issue, send updated drafts for last review,
go to iesg last call.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt

Presented history and latest changes made.

Next steps - small revisions to drafts (specifically label coding) and
then go to IETF last call.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt

Presented history and latest changes made.

Target is informational RFC.  Let's have last review and last call
before next IETF.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt

Reviewed document status.  Would like WG to adopt working item?

SENSE OF ROOM: SUPPORT 10-15.  NO OBJECTIONS.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt

Reviewed scenarios in document.  Is working group will to accept this
as a WG document?

NO RESPONSE FROM THE ROOM (maybe 3 for, none against).

Ron: Take this item to the mailing list.

Kireeti: How many SPs in the room.  20-25.

Kireeti: How many folks are interested in transport.  MOST EVERYONE

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.

Draft addresses one of the issues that Tolbridge highlighted in his
talk - call and connection control separation.

Proposal to accept document as a WG item.

Kireeti: There is an explicit statement from ITU requiring this.
There is nothing in the charter about this.  This is good stuff.  Ron
and I will go through a charter revision with Ads and discuss putting
this in the charter.  Also need to address other gaps that were raised
by ITU.

Scott: When you propose to add something to WG, it would be helpful to
state where it fits in the existing charter OR how and why charter
should be extended.

Eva: I think that it fits into the character as a requirement to the
signaling protocols.

Scott: OK - that is a good clean explanation that might save chairs
some time.

Yong: I second Eva's comment.

Kireeti: Need to figure out how to address other issues as well.
Also, MPLS OAM will be discussed in MPLS WG tomorrow.

Osama: What is outcome?

Kireeti: Let's think about this.  See about doing same for RSVP and
then move forward.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% John Lang - LMP status (draft -03)

Current status:
  - Finished WG last call
  - Fixed several edits
  - Added text to security considerations

Open Issues:
  - Security
      - currently md5 is defined for LMP authentication
      - Another proposal exists in draft-sankar for Ipsec usage
  - Make local/remote id different in class type instead of object class

Bert: I raised the local/remote id issue, but there were also other
issues where things could be combined.  Did you review other parts of
document as well?

John: We did.  Your comment reflects this class, but not others.

NO OBJECTIONS TO PROPOSED CHANGES

John Sadler: I have some open issues.  Test message and ???.

John: Test message was updated based on comments in last call and
should be consistent with OIF work.

John Sadler: Does not talk about control/address fields.  Do not talk
about 1662 frame format.

John: We can look at this.

Kireeti: OIF compatibility is not a requirement, but if we get that
for free (or cheap) great.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tom Nadeau - MIBs for GMPLS

Reviewed status of current documents, minor changes, etc.  Want GMPLS
MIBs to be compatible with MPLS MIBs when then become RFCs.

Summary:
  - Make mpls-tev2 MIB CCAMP (or MPLS) wg document
  - Make GMPLS-label MIB CCAMP wg document.
  - GMPLS-TC MIB as CCAMP wg document to capture new GMPLS-related TCs.
  - Drop GMPLS-LSR MIB (will use as it is including new TC change).

Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?

Tom: New indexing scheme relies on having the label MIB - for MPLS
index is label.  For GMPLS there is more stuff in the GMPLS-label MIB.

Kireeti: Need to see new version and then move forward.  Nice if we
could decouple them.  Will discuss with chairs and Ads where this
should go.

Scott: Seems general, so belongs in CCAMP.

Tolbridge: "general" frequently means more than one thing.

Kireeti: We have "classical" MPLS and non-packet based MPLS.
Generalized covers both.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling and
restoration

Presented drafts.

Kireeti: Protection group should consider these docs.  More discussion
on the list.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Ron Bonica

Issues:
  - Should we define protocols yet?
  - IP centric VS Tunnel Centric tools

We need a tool that tells us about the IP layer and the tunnels that
support it.  IP network may be supported by multiple types of tunnels
- don't want separate tools for each type.

Proposal - adopt tunnel tracing requirements as a wg document.
Continue work on protocol specification.  Orthogonal to any open
discussions about MPLS OAM.

Kireeti: Discussion to list.

???: Is the proposal to accept a new (03) draft that incorporates
comments from the list.

Ron: not the intention.  Accepting the doc just means that it is a
good enough starting point and we can spin revs later.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Dimitri - protection and restoration

Will submit draft as an individual ID.  Want comments from the list.

Kireeti: Thanks.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Not all who wander are lost."
                -- J.R.R. Tolkien

Delivery-date: Thu, 04 Apr 2002 02:34:40 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Ron Bonica' <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Please read and comment on GMPLS P&R DT documents
Date: Tue, 2 Apr 2002 12:17:53 +0200

Hello Ron,

We took the definition of null traffic from g.gps and only adapted it to
"LSP/span recovery". The null traffic is the traffic you have when there is
no normal or extra traffic over the recovery LSP/span. Null traffic is not
selected (chosen) at the egress. We could also say that this is not a user
data traffic.

Extra traffic is typically a low priority user data traffic (that could be
qualified as normal traffic if it was not transported using standby recovery
resources).

The draft just gives definitions, some of them are not used anywhere else in
the same draft, correct. They are just expected to be used in other drafts,
or to help to better understand other definitions.

Kind regards,

Eric

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, April 01, 2002 12:45 AM
To: Sudheer Dharanikota; CCAMP WG
Subject: RE: Please read and comment on GMPLS P&R DT documents

Sudheer,

In Section 4.2.C of the terminology document, could you expand on the
definition of "null traffic"? How is it different from "extra traffic"?

Also, you don't use the term outside of section 4.2.C. Should this be cause
for concern?

                                                Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sudheer Dharanikota
> Sent: Wednesday, March 13, 2002 12:28 PM
> To: CCAMP WG
> Subject: Please read and comment on GMPLS P&R DT documents
>
>
> Hi Folks:
>
> Please note that the "GMPLS Protection and Restoration
> Design Team"
> has produced the following two documents (1st version)...
>
> Recovery (Protection and Restoration) Terminology for GMPLS
> http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery
> -terminology-00.txt
>
> Analysis for GMPLS-based Recovery Mechanisms(including
> Protection and Restoration)
> http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-an
> alysis-00.txt
>
> We request you to read and comment on them as quickly as you
> can.
>
> Regards,
>
> GMPLS P&R Design Team
>
>
>

Delivery-date: Wed, 03 Apr 2002 15:17:48 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: George Young <[email-masked]>
Cc: [email-masked]
Subject: RE: sub-ip summary for internet drafts
Date: Thu, 4 Apr 2002 01:17:31 +0200 

And it is also highly recommend to post a summary
to [email-masked]

Below is an old announcement about that

Bert 
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 3:02 PM
To: idsummary
Subject: ACTION: Summaries for sub-IP related Internet Drafts

All, but specifically I-D Authors/Editors

Over the last several months, we have seen A LOT of I-Ds submitted/posted
which appear to be targeted for one or more WGs in the new sub-IP area.
(ccamp, gsmp, ipo, iporpr, tewg, mpls and ppvpn) These are mostly
individual I-Ds, that is those that do not start with 
        draft-ietf-<someWgName>
but this mesage referrs to ALL I-Ds related to the Sub IP WGs.
In fact we believe we have some 200-300 of such documents.

It is sort of impossible to try and read them all and decide in which WG
(if any) they might fit. So in order to help us (WG chairs and ADs) to 
work our way through all these documents, we want the AUTHORS/EDITORS of 
such existing documents to do the following:

- Before May 18th, pls send ONE SINGLE email per I-D to the email alias
  
       [email-masked]

  That email should be formatted and contain content as
  explained below.

  Pls DO NOT send these emails to any WG mailing list. 

  The idsummary mailing list will be archived publically at 

      ftp://subip.ietf.org/pub/lists/idsummary*

  Since these are non-WG documents (yet) any comments/discussion
  can/should take place at: 

      [email-masked]

  But initially the idea is to just collect the data.

- When doing a revision of these documents or writing a new I-D,
  please pls add a section at the beginning of your document that contains
  the same information we are asking for here so that readers of your
  document can also see it.

All these emails will be archived and the WG chairs, ADs, Technical Advisors
and Directorate will review them and report back (target is end of May)
what we want to do with each of the documents.

If we do not receive a note about an I-D we will assume that the I-D
authors/editors do not intend to publish it as a RFC.

Further, if you assume this pictorial overview of the work we are doing
in the sub-IP area, then pls indicate where in the picture your document
fits.

   --- pictorial overview of work in the sup-IP area --------------

  The Working Groups at the top are those that will use the
  Common Control and Measurement Protocols that we're 
  defining in the CCAMP WG.

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

  The technologies at the bottom allow us to create paths and so those
  are the ones we want to measure and control via the Common Control
  and Measurement Protocols coming out of CCAMP. One of those 
  technologies (MPLS) is defined by IETF, others are (have been) defined 
  in other standards organisations. However, we want to focus mainly on 
  the use of such technologies for IP.

  So for example the IPO and IPORPR WGs are assumed to be active at 
  the bottom because we want to focus on the IP use of such technologies.

Bert and Scott
--------------------
The ONE SINGLE email per I-D should be as follows:

-  Subject: <targetWgName> <nameOfID>
   
   the targetWgName is the WG that you as authors/editors
   think that this document should live in. If you have no specific
   WG as the target WG, then use subIP as the name.

   the nameOfID is the filename of the draft, e.g. draft-xxx-yyy-zzz-00.txt

- In the body of the email must have the following sections with these 
  section titles:

NAME OF I-D:

  Write it down as a URL so we can click on it to see it.  e.g. 

  http://www.ietf.org/internet-drafts/draft-xxx-yyy-zzz-00.txt

SUMMARY

  This should contain a summary of the content of the document
  Potentially it can be the abstract. But pls make sure that it helps
  the reader undestand what the document is all about.
  PLEASE TRY TO KEEP IT DOWN TO TWO PARAGRAPHS

RELATED DOCUMENTS

  A list of URLs for other I-Ds (or non-IETF documents) that you think
relate,
  compete, complement or overlap with your document.  "none" if none

WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

WHY IS IT TARGETED AT THIS WG

  You must explain how the ID addresses a workitem in the current WG
  charter as listed on the WG charter page on the IETF web site. If
  it addresses only part of a work item, then please explain if there
  are other documents that could be merged with this one to become one
  document to address the complete work item.

JUSTIFICATION

  Why do you think it is justified for the WG to consider this document.

  In the case that you cannot explain how this document addresses
  a specific WG charter work item, then explain and justify why the
  WG should even consider this work and what the description of 
  a possible new work item would be for the WG. Suggest possible
  milestones for that work item.

  Please realize, that new work items need wide support within a
  WG, but also they need agreement from the WG chairs and ADs,
  and even when they get that, the whole IESG and IAB must review and
  approve new-work items before they get added to a WG charter.

  Please understand that we already have a lot of work in our WG
  charters, and that we would rather see that finished (or at least
  be well undeway) before we undertake any new work items.

Delivery-date: Wed, 03 Apr 2002 15:14:32 -0800
Date: Wed, 3 Apr 2002 15:14:04 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: CCAMP WG Last Call on GMPLS Routing Documents

Hi,

This is to announce a two week WG Last Call on the GMPLS routing
documents, i.e.:
draft-ietf-ccamp-gmpls-routing-03.txt
draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

FYI: these documents are intended to be Standards Track.

The Last Call will end at 1700 EDT, April 17th.

Kireeti.

Delivery-date: Wed, 03 Apr 2002 15:10:19 -0800
Date: Wed, 3 Apr 2002 15:08:21 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: George Young <[email-masked]>
cc: <[email-masked]>
Subject: Re: sub-ip summary for internet drafts

On Wed, 3 Apr 2002, George Young wrote:

> Is there a special requirement for a sub-ip summary in an internet
> draft aimed at this WG? I checked the ietf page and couldn't find it
> documented anywhere.

It is highly recommended that a "sub-ip summary" be included in all
drafts aimed at a sub-IP WG.

Kireeti.

Delivery-date: Wed, 03 Apr 2002 11:23:06 -0800
content-class: urn:content-classes:message
Subject: sub-ip summary for internet drafts
Date: Wed, 3 Apr 2002 14:17:21 -0500
From: "George Young" <[email-masked]>
To: <[email-masked]>

Is there a special requirement for a sub-ip summary in an internet draft =
aimed at this WG? I checked the ietf page and couldn't find it =
documented anywhere.

Regards,
George R. Young
Meriton Networks Inc.
3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9628
email: [email-masked]

Delivery-date: Mon, 01 Apr 2002 23:23:17 -0800
From: Jonathan Lang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on LMP
Date: Mon, 1 Apr 2002 23:15:47 -0800 

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_01C1DA16.360AD5E0
Content-Type: text/plain;
	charset="iso-8859-1"

Baktha,
   Please see comments inline.
 
Thanks,
Jonathan

-----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Friday, March 22, 2002 11:23 AM
To: Jonathan Lang
Cc: [email-masked]
Subject: Comments on LMP

Hi Jonathan,

        Looks the following comments that I sent some time ago
        got lost.

Thanks,

/Baktha

X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Mar 2002 23:02:27 -0500
To: Jonathan Lang <[email-masked]>
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on LMP
Cc: [email-masked], [email-masked]

Hi Jonathan

         We have the following comments on LMP draft 3:
--------------------------------------------------
1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks
about Message ID usage. It states,
"Unacknowledged messages sent with the MESSAGE_ID object   SHOULD be
retransmitted until the message is acknowledged or until a retry limit is
reached."

What are the subsequent actions that need to take place when the above
conditions occur ? 
 
[Jonathan]If a retry limit is reached, the message must not be
retransmitted.     
 
 2. When Nacking a link summary, the current message format doesn't allow
indicate what's wrong with each interface mapping.. "per-interface" error
codes would be helpful. i.e. The TE link and each data link object in the
Nack message   needs an error code to localize the failure. 
 
[Jonathan] From Section 13.7.3: "The DATA_LINK objects included in the
LinkSummaryNack message MUST include accpetable values for all negotiable
parameters.  If the LinkSummaryNack includes DATA_LINK Objects for
non-negotiable parameters, they MUST be copied from the DATA_LINK Objects
received in the LinkSummary message."
 
Why isn't this enough to indicate what's wrong with each interface mapping?
 
 3. When a channel status msg is received with message ID less than   an
earlier (TE-Link) message, it might still be accepted per the draft. So, in
the case where it is accepted, should the accepted message ID become the
basis for all future message ID (validations)? 
 
[Jonathan]Message Id values are stored for each TE-Link as well as data
channel.  The stored Message_Id values are only updated when a message
arrives with a Message_Id value that is greater than the currently stored
value.
 
4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the
current LMP draft does not support it. 
 
 [Jonathan] LMP defines the CCID as a 32-bit field.  For the in-band case of
OIF/OUNI, an IPv4 address could be used.
 
 ------------------------------------------------------------
Thanks,

/Baktha Muralidharan
Cisco Systems, Inc.
Chelmsford, MA. 

------_=_NextPart_001_01C1DA16.360AD5E0
Content-Type: text/html;
	charset="iso-8859-1"

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

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002>Baktha,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002>&nbsp;&nbsp;<SPAN 
class=177311507-02042002>&nbsp;</SPAN>Please see comments 
inline.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002>Jonathan</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=721485515-26032002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Baktha Muralidharan 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, March 22, 2002 11:23 
  AM<BR><B>To:</B> Jonathan Lang<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> Comments on LMP<BR><BR></DIV></FONT>Hi 
  Jonathan,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Looks 
  the following comments that I sent some time 
  ago<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>got 
  lost.<BR><BR>Thanks,<BR><BR>/Baktha<BR><BR><BR>
  <BLOCKQUOTE cite type="cite">
    <DIV>X-Sender: [email-masked]<BR>X-Mailer: QUALCOMM Windows 
    Eudora Version 4.3.2<BR>Date: Thu, 14 Mar 2002 23:02:27 -0500<BR>To: 
    Jonathan Lang &lt;[email-masked]&gt;<BR>From: Baktha Muralidharan 
    &lt;[email-masked]&gt;<BR>Subject: Comments on LMP<BR>Cc: 
    [email-masked], [email-masked]<BR><BR>Hi 
    Jonathan<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We have the 
    following comments on LMP draft 
    3:<BR>--------------------------------------------------<BR><FONT 
    face="Courier New, Courier">1. In the current LMP draft 
    (draft-ietf-ccamp-lmp-03.txt), section 7 talks<SPAN 
    class=721485515-26032002><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;</FONT></SPAN>about Message ID usage. It 
    states,<BR>"Unacknowledged messages sent with the MESSAGE_ID object<SPAN 
    class=721485515-26032002><FONT color=#0000ff face=Arial size=2>&nbsp; 
    &nbsp;</FONT></SPAN>SHOULD be retransmitted until the message is 
    acknowledged or until a retry limit is reached."<BR><BR>What are the 
    subsequent actions that need to take place when the above conditions occur 
    ?<SPAN class=721485515-26032002><FONT color=#0000ff face=Arial 
    size=2>&nbsp;</FONT></SPAN></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN class=721485515-26032002><FONT 
    color=#0000ff face=Arial size=2></FONT></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002>[Jonathan]If a retry limit is reached, the message 
    must not be retransmitted<SPAN 
    class=177311507-02042002>.&nbsp;</SPAN>&nbsp;&nbsp;<SPAN 
    class=172164302-28032002>&nbsp;&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN class=721485515-26032002><FONT 
    color=#0000ff face=Arial size=2>&nbsp;</FONT></SPAN></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN 
    class=721485515-26032002>&nbsp;</SPAN>2. When Nacking a link summary, the 
    current message format doesn't allow indicate what's wrong with each 
    interface mapping.. "per-interface" error codes would be helpful. i.e. The 
    TE link and each data link object in the Nack message<SPAN 
    class=721485515-26032002><FONT color=#0000ff face=Arial size=2>&nbsp; 
    &nbsp;</FONT></SPAN>needs an error code to localize the failure.<SPAN 
    class=721485515-26032002><FONT color=#0000ff face=Arial 
    size=2>&nbsp;</FONT></SPAN></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN 
    class=721485515-26032002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN class=721485515-26032002><FONT 
    color=#0000ff face=Arial size=2>[Jonathan]</FONT>&nbsp;<FONT 
    color=#0000ff><FONT size=2><FONT face=Arial>From Section 13.7.3: "The 
    DATA_LINK objects included in the LinkSummaryNack message MUST include 
    accpetable values for all negotiable parameters.&nbsp; If the 
    LinkSummaryNack includes DATA_LINK Objects for non-negotiable parameters, 
    they MUST be copied from the DATA_LINK&nbsp;Objects received in the 
    LinkSummary message."</FONT></FONT></FONT></SPAN></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN class=721485515-26032002><FONT 
    color=#0000ff><FONT size=2><FONT 
    face=Arial></FONT></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN class=721485515-26032002><FONT 
    color=#0000ff><FONT size=2><FONT face=Arial>Why isn't this enough to 
    indicate what's wrong with each interface 
    mapping?</FONT></FONT></FONT></SPAN></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN 
    class=721485515-26032002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New, Courier"><SPAN 
    class=721485515-26032002>&nbsp;</SPAN>3. When a channel status msg is 
    received with message ID less than<SPAN class=721485515-26032002><FONT 
    color=#0000ff face=Arial size=2>&nbsp; &nbsp;</FONT></SPAN>an earlier 
    (TE-Link) message, it might still be accepted per the draft. So, in the case 
    where it is accepted, should the accepted message ID become the basis for 
    all future message ID (validations)?<FONT size=2><FONT color=#0000ff><FONT 
    face=Arial><SPAN 
    class=721485515-26032002>&nbsp;</SPAN></FONT></FONT></FONT></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><FONT size=2><FONT 
    color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New, Courier"><FONT size=2><FONT 
    color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002>[Jonathan]Message Id values are stored for each 
    TE-Link as well as data channel.&nbsp; The stored Message_Id values are only 
    updated when a message arrives with a Message_Id value that is greater than 
    the currently stored value.</SPAN></FONT></FONT></FONT></FONT></DIV>
    <DIV><FONT face="Courier New, Courier"><FONT size=2><FONT 
    color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New, Courier">4. CC ID can be numbered (i.e. IPv4 
    format) per OIF/OUNI. However, the current LMP draft does not support 
    it.</FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT color=#0000ff><FONT face=Arial><SPAN 
    class=721485515-26032002></SPAN></FONT></FONT><SPAN 
    class=721485515-26032002><FONT color=#0000ff face=Arial 
    size=2>&nbsp;[Jonathan] LMP defines the CCID as a 32-bit field.&nbsp; For 
    the in-band case of OIF/OUNI, an IPv4 address could be 
    used.</FONT></SPAN></DIV>
    <DIV><SPAN class=721485515-26032002></SPAN>&nbsp;</DIV>
    <DIV><SPAN 
    class=721485515-26032002>&nbsp;</SPAN>------------------------------------------------------------<BR>Thanks,<BR><BR>/Baktha 
    Muralidharan<BR>Cisco Systems, Inc.<BR>Chelmsford, MA. 
</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1DA16.360AD5E0--

Delivery-date: Mon, 01 Apr 2002 23:14:45 -0800
Cc: Sudheer Dharanikota <[email-masked]>, CCAMP WG <[email-masked]>
Date: Tue, 02 Apr 2002 09:11:34 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Ron Bonica <[email-masked]>
Original-CC: Sudheer Dharanikota <[email-masked]>, CCAMP WG <[email-masked]>
Subject: Re: Please read and comment on GMPLS P&R DT documents

This is a multi-part message in MIME format.
--------------376C6662C53EFE483D2A6C2B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ron,

>From draft Rec. G.gps:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/ggps-v01-0110.doc
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/ggps-v01-0110.pdf

3.10	Signal:

3.10.1	Normal traffic signal - Traffic signal that is protected by two
alternative transport entities, called working and protection entities.

3.10.2	Extra traffic signal - Traffic signal that is carried over the protection
transport entity and/or bandwidth when that transport entity/bandwidth is not
being used for the protection of a normal traffic signal; i.e. when protection
transport entity is standby. Whenever the protection transport entity/bandwidth
is required to protect or restore the normal traffic on the working entity, the
extra traffic is pre-empted. Extra traffic is not protected.

3.10.3	Null signal - The null signal is indicated on the protection transport
entity if it is not used to carry normal or extra traffic. The null signal can
be any kind of signal that conforms to the signal structure of the specific
layer and is ignored (not selected) at the tail end of the protection.

Figures 2 to 5 in G.gps show the null signal.

Regards,

Maarten

Ron Bonica wrote:
> 
> Sudheer,
> 
> In Section 4.2.C of the terminology document, could you expand on the
> definition of "null traffic"? How is it different from "extra traffic"?
> 
> Also, you don't use the term outside of section 4.2.C. Should this be cause
> for concern?
> 
>                                                 Ron
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Sudheer Dharanikota
> > Sent: Wednesday, March 13, 2002 12:28 PM
> > To: CCAMP WG
> > Subject: Please read and comment on GMPLS P&R DT documents
> >
> >
> > Hi Folks:
> >
> > Please note that the "GMPLS Protection and Restoration
> > Design Team"
> > has produced the following two documents (1st version)...
> >
> > Recovery (Protection and Restoration) Terminology for GMPLS
> > http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery
> > -terminology-00.txt
> >
> > Analysis for GMPLS-based Recovery Mechanisms(including
> > Protection and Restoration)
> > http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-an
> > alysis-00.txt
> >
> > We request you to read and comment on them as quickly as you
> > can.
> >
> > Regards,
> >
> > GMPLS P&R Design Team
> >
> >
> >
--------------376C6662C53EFE483D2A6C2B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------376C6662C53EFE483D2A6C2B--

Delivery-date: Mon, 01 Apr 2002 23:14:42 -0800
From: Jonathan Lang <[email-masked]>
To: 'Soo-Hyun Choi' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: LMP over UDP
Date: Mon, 1 Apr 2002 23:04:57 -0800 

Soo-Hyun,
  I am told that this is because they don't want to run out of protocol IDs
and they only have 255 available (this is only an 8-bit field - see
http://www.iana.org/assignments/protocol-numbers).

Thanks,
Jonathan

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:[email-masked]]
> Sent: Saturday, March 30, 2002 1:02 AM
> To: Jonathan Lang; [email-masked]
> Cc: [email-masked]; Jonathan Lang
> Subject: Re: LMP over UDP
> 
> 
> Hi, Jonathan,
> 
> I don't understand why the IESG would reject the LMP over raw 
> IP unless you
> have a very very compelling reason.
> Could you clarify more on this?
> 
> Regards,
> Soo-Hyun Choi
> 
> ----- Original Message -----
> From: "Jonathan Lang" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; "Jonathan Lang" <[email-masked]>
> Sent: Friday, March 22, 2002 10:51 AM
> Subject: LMP over UDP
> 
> 
> > All,
> >
> > I had a discussion with Scott in Minnesota about 
> progressing LMP through
> the
> > IESG.  He had given the LMP draft a "pre-IESG" review 
> (looking for obvious
> > rejection material) and realized that it wouldn't fly as 
> LMP over raw IP -
> > they're not giving out IP protocol IDs unless you have a very very
> > compelling reason.  Instead we will run LMP over UDP, and 
> get a UDP port
> for
> > LMP from IANA.  Fixing this now will short-circuit an 
> almost certain IESG
> > rejection.
> >
> > Thanks,
> > Jonathan
> >
> >
> 

Delivery-date: Mon, 01 Apr 2002 00:56:58 -0800
Date: Mon, 01 Apr 2002 14:24:17 +0530
From: [email-masked]
Organization: HCL Technologies Ltd
To: [email-masked], [email-masked]
Subject: Query in OIF-UNI-1.0 Implementation Aggrement

Hi,
    I have the following doubt.

    If there is cleanup timeout (Path celanup or Resv celanup) in
UNI_C(client side) or in UNI_N(network side), whether we can consider
that as "Network Failue" and start Graceful deletion in respective side
itself by considering direction. Because, if I consider cleanup timeout
as "Network Failue", then I should not send PathErr or ResvErr to the
ingress or egress end.

    For example, if there is Resv cleanup timeout expired in source
UNI_C, then instead of sending ResvTear (as in normal RSVP) message, I
can send ResvErr to source UNI_N(network side). Thinking from the
implementation prespectivem, since I consider cleanup timeout situation
as "Network Failue"(not fault handling situation), I will have to inform
the respective application (in this case, source UNI_C application) with
PathErr(direction is important) message using corresponding Path State
details.

    My observation is that hello synchronization will handle this
situation as fault handling scenario. Anyway, please clarify that what
action can be taken, when state cleanup timeout expires. Whether
"graceful deletion" or ?...

Thanks,
Rajaraman. B