From Majordomo-Owner@psg.com Sat Apr 6 03:51:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06179 for ; Sat, 6 Apr 2002 03:51:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tlvE-000OWm-00 for ccamp-archive@ietf.org; Sat, 06 Apr 2002 00:51:44 -0800 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Majordomo results: Subscribe archive address Reply-To: majordomo@psg.com Message-Id: Date: Sat, 06 Apr 2002 00:51:44 -0800 -- >>>> >>>> subscribe ccamp **** Your request to majordomo@psg.com: **** **** subscribe ccamp ccamp-archive@ietf.org **** **** must be authenticated. To accomplish this, another request must be **** sent in with an authorization key, which has been sent to: **** ccamp-archive@ietf.org **** **** If the message is not received, there is generally a problem with **** the address. Before reporting this as a problem, please note the **** following: **** **** You only need to give an address to the subscribe command if you want **** to receive list mail at a different address from where you sent the **** command. Otherwise you can simply omit it. **** **** If you do give an address to the subscribe command, it must be a legal **** address. It should not consist solely of your name. The address must **** point to a machine that is reachable from the list server. **** **** If you have any questions about the policy of the list owner, please **** contact "ccamp-approval@psg.com". **** **** Thanks! **** **** majordomo@psg.com >>>> >>>> From Majordomo-Owner@psg.com Sat Apr 6 04:38:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06177 for ; Sat, 6 Apr 2002 03:51:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tlvE-000OWn-00 for ccamp-archive@ietf.org; Sat, 06 Apr 2002 00:51:44 -0800 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Confirmation for subscribe ccamp Reply-To: majordomo@psg.com Message-Id: 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 "ccamp@psg.com". If you really want this action to be taken, please send the following commands (exactly as shown) back to "majordomo@psg.com": auth 814be824f832613ede6200d498fdab86 subscribe ccamp ccamp-archive@ietf.org 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 \ ccamp-archive@ietf.org If you have any questions about the policy of the list owner, please contact "ccamp-approval@psg.com". Thanks! majordomo@psg.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Apr 2002 21:53:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Apr 2002 14:36:22 -0700 Message-Id: <4.3.2.7.2.20020430164811.054b8520@sword.cisco.com> Date: Tue, 30 Apr 2002 17:34:28 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_28241288==_.ALT" --=====================_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...> =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_28241288==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com
 --=====================_28241288==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Apr 2002 13:25:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Apr 2002 10:33:23 -0700 Message-Id: <4.3.2.7.2.20020430102015.00bacf10@mira1.cisco.com> Date: Tue, 30 Apr 2002 10:27:52 -0700 To: Zhi-Wei Lin From: Suresh Katukam Subject: Re: Fwd: Re: SE style in optical neyworks Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 13:10:56 -0700 Message-ID: From: Jonathan Lang To: 'Michiel van Everdingen' , Zafar Ali Cc: ccamp@ops.ietf.org Subject: RE: Question on LMP. Date: Mon, 29 Apr 2002 13:02:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michiel, > > 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...> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 12:20:00 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E602259EE8@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Zafar Ali , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Mon, 29 Apr 2002 15:17:45 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EFB2.8A7BC48E" 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:zali@cisco.com] >Sent: Sunday, April 28, 2002 1:53 AM >To: Kireeti Kompella >Cc: ccamp@ops.ietf.org >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" RE: TE metric and graceful restart

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:zali@cisco.com]
>Sent: Sunday, April 28, 2002 1:53 AM
>To: Kireeti Kompella
>Cc: ccamp@ops.ietf.org
>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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 10:15:34 -0700 Message-Id: <4.3.2.7.2.20020429130957.02b8ebc8@mail.labn.net> Date: Mon, 29 Apr 2002 13:13:03 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-signaling-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: mpls@UU.NET >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-08.txt >Date: Mon, 29 Apr 2002 07:53:12 -0400 >Sender: owner-mpls@UU.NET > >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: > mailserv@ietf.org. >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: <20020426141009.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 10:15:29 -0700 Message-Id: <4.3.2.7.2.20020429130957.02d81ef8@mail.labn.net> Date: Mon, 29 Apr 2002 13:13:09 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: mpls@UU.NET >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-06.txt >Date: Mon, 29 Apr 2002 07:53:17 -0400 >Sender: owner-mpls@UU.NET > >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: > mailserv@ietf.org. >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: <20020426141019.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 10:15:23 -0700 Message-Id: <4.3.2.7.2.20020429130957.02d8f290@mail.labn.net> Date: Mon, 29 Apr 2002 13:13:16 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: mpls@UU.NET >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-07.txt >Date: Mon, 29 Apr 2002 07:53:22 -0400 >Sender: owner-mpls@UU.NET > >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: > mailserv@ietf.org. >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: <20020426141028.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 08:59:29 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CCD6D69.B251024D@lucent.com> Date: Mon, 29 Apr 2002 17:57:29 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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...> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 06:29:31 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: encoding link id for unnumbered interfaces Date: Mon, 29 Apr 2002 09:27:03 -0400 Message-ID: <9BBB98592D94084DB7118F889CFD3EC50A88B3@atlntex01.movaz.com> Thread-Topic: encoding link id for unnumbered interfaces Thread-Index: AcHtZFqF4drZUk+qRXqbi38gWzJiZACGo/Ww From: "Dovolsky, Dan" To: 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:yakov@juniper.net] Sent: Friday, April 26, 2002 4:46 PM To: Naidu, Venkata Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Apr 2002 02:21:35 -0700 Message-ID: <023b01c1ef37$88e78ac0$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: "Fedyk Don [BL60:1A00:EXCH]" Cc: Subject: Re: Suggested label and Label Set tlv doubts Date: Mon, 29 Apr 2002 14:37:13 +1000 Organization: wipro technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-58c5dc32-5b4f-11d6-af80-0080c8048dde" 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:venkat.dabb@wipro.com] Sent: Friday, April 26, 2002 6:03 AM To: ccamp@ops.ietf.org 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
hello Don,
 
       =20         For every mail that leaves out of = my=20 inbox, my employer attaches the disclaimer as a part of
       =20         organization security policy. I = can't do=20 anything abt it and i guess it also doesn't have anything = to
       =20         do to make my queries invalid on a = public=20 list either and should not be a problem to discuss queries
       =20         and make things clear ..After all = we are=20 here to share veiws and ideas and come out with better = solutions.
       =20        
       =20         Don't really understand why this = should=20 become an issue at all. Neway, if the disclaimer hurts any=20 individual,
       =20         please excuse me ...n sorry abt it = ...other wise i don't see any reason why one should not answer the=20 queiries 
          &nbs= p;     
       =20         Please find my questions in the = mail=20 attached ..
 
thanks and regards
venkat
       =20        
          &nbs= p;  
 
          &nbs= p;=20
----- Original Message -----
From:=20 Fedyk, Don = [BL60:1A00:EXCH]=20
To: venkat
Sent: Saturday, April 27, 2002 = 1:34=20 AM
Subject: RE: Suggested label = and Label=20 Set tlv doubts

Venkat
 
Your=20 disclaimer makes your message invalid on a public list. You might want = to=20 rephrase your question as an individual.
 
Don
-----Original Message-----
From: Venkat Dabbara=20 [mailto:venkat.dabb@wipro.com]
Sent: Friday, April 26, = 2002 6:03=20 AM
To: ccamp@ops.ietf.org
Subject:<= /B>=20 Suggested label and Label Set tlv doubts

hai ,
 
          &nbs= p;=20 Since the suggested label and label set tlvs are optional in a = Generalized=20 label request, how do i handle
    =    =20     a situation when someone has sent a request with = both the=20 TLVs present ??
   
    =    =20     Do label set tlv has higher priority over = suggested label=20 in which case i can go ahead ignoring the
    =    =20     suggested label and try to satisfy the request = with label=20 set as constraint on label or do i need to
          &nbs= p; satisfy=20 the suggested label constraint since my upstream has sent me the = suggested=20 label with
    =    =20     an assumption that it will be satisfied and = moreover=20 since it would have created a crossconnect also.
    =    =20     And ignore the label set tlv.
 
    =    =20     I understand that this is a scenario where = upstream is=20 malfunctioning but that needs to be handled for sure = and
          &nbs= p;=20 cannot be ignored
 
    =    =20     Please do clarify things ...
 
thanks
venkat
------=_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-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 27 Apr 2002 23:00:06 -0700 Message-Id: <4.3.2.7.2.20020426212818.048c1a70@sword.cisco.com> Date: Sun, 28 Apr 2002 01:59:28 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_56078156==_.ALT" --=====================_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. > > > > > > =============== > > Zafar Ali > > Cisco Systems > > (734) 276-2459 > > 100 S Main St. #200 > > Ann Arbor, MI 48104. > > email: zali@cisco.com > >-- >+------------------------------------------------------------------+ >| 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:MvanEverdingen@lucent.com | >+------------------------------------------------------------------+ =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_56078156==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com

--
+------------------------------------------------------------------+
| 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:MvanEverdingen@lucent.com |
+------------------------------------------------------------------+
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

 --=====================_56078156==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 27 Apr 2002 22:55:04 -0700 Message-Id: <4.3.2.7.2.20020428012108.02f15830@sword.cisco.com> Date: Sun, 28 Apr 2002 01:52:55 -0400 To: Kireeti Kompella From: Zafar Ali Subject: RE: TE metric and graceful restart Cc: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_55742152==_.ALT" --=====================_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: zali@cisco.com --=====================_55742152==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com
--=====================_55742152==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 27 Apr 2002 22:04:33 -0700 Date: Sat, 27 Apr 2002 22:01:11 -0700 (PDT) From: Kireeti Kompella To: Zafar Ali cc: Subject: RE: TE metric and graceful restart Message-ID: <20020427215235.P22240-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 27 Apr 2002 09:22:52 -0700 Message-Id: <4.3.2.7.2.20020427112229.02cbe6f8@sword.cisco.com> Date: Sat, 27 Apr 2002 12:16:39 -0400 To: "Don Fedyk", Alex Zinin , Yakov Rekhter From: Zafar Ali Subject: RE: TE metric and graceful restart Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6710238==_.ALT" --=====================_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:zinin@psg.com] > > Sent: Friday, April 26, 2002 2:55 PM > > To: Yakov Rekhter > > Cc: ccamp@ops.ietf.org > > 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: zali@cisco.com --=====================_6710238==_.ALT Content-Type: text/html; charset="us-ascii" 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:zinin@psg.com]
> Sent: Friday, April 26, 2002 2:55 PM
> To: Yakov Rekhter
> Cc: ccamp@ops.ietf.org
> 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: zali@cisco.com --=====================_6710238==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 19:55:18 -0700 Date: Fri, 26 Apr 2002 19:54:47 -0700 (PDT) From: Kireeti Kompella To: "Naidu, Venkata" cc: Subject: RE: TE metric and graceful restart Message-ID: <20020426193755.H17288-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 19:38:32 -0700 Date: Fri, 26 Apr 2002 19:36:33 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin cc: Subject: Re: TE metric and graceful restart Message-ID: <20020426193328.B17288-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 14:18:39 -0700 Message-ID: <39469E08BD83D411A3D900204840EC5576314B@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Yakov Rekhter'" , Don Fedyk Cc: Alex Zinin , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Fri, 26 Apr 2002 17:17:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" -> 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:48:47 -0700 Message-ID: <39469E08BD83D411A3D900204840EC5576314A@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Alex Zinin'" , Zafar Ali Cc: Yakov Rekhter , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Fri, 26 Apr 2002 16:48:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:46:11 -0700 Message-Id: <200204262045.g3QKjtT76045@merlot.juniper.net> To: "Naidu, Venkata" cc: ccamp@ops.ietf.org Subject: Re: encoding link id for unnumbered interfaces MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60334.1019853955.1@juniper.net> Date: Fri, 26 Apr 2002 13:45:55 -0700 From: Yakov Rekhter > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:42:43 -0700 Message-Id: <200204262041.g3QKfnT75701@merlot.juniper.net> To: "Don Fedyk" cc: Alex Zinin , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58787.1019853709.1@juniper.net> Date: Fri, 26 Apr 2002 13:41:49 -0700 From: Yakov Rekhter 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:zinin@psg.com] > > Sent: Friday, April 26, 2002 2:55 PM > > To: Yakov Rekhter > > Cc: ccamp@ops.ietf.org > > 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" > > > > > > > RE: TE metric and graceful restart > > > >

Yakov >

> >

I have a question. Do you mean that a node that is restarting >
its routing view and learning from it's neighbors should mar k >
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 :zinin@psg.com] >
> Sent: Friday, April 26, 2002 2:55 PM >
> To: Yakov Rekhter >
> Cc: ccamp@ops.ietf.org >
> Subject: Re: TE metric and graceful restart >
> >
> >
> Yakov, >
> >
>   How does this improve the situation given t hat >
>   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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:38:43 -0700 Message-Id: <200204262038.g3QKcNT75477@merlot.juniper.net> To: Zafar Ali cc: Alex Zinin , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57583.1019853503.1@juniper.net> Date: Fri, 26 Apr 2002 13:38:23 -0700 From: Yakov Rekhter 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: zali@cisco.com > --=====================_27231316==_.ALT > Content-Type: text/html; charset="us-ascii" > > > 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: zali@cisco.com > > --=====================_27231316==_.ALT-- > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:37:04 -0700 Message-ID: <39469E08BD83D411A3D900204840EC55763149@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: Yakov Rekhter , ccamp@ops.ietf.org Subject: RE: encoding link id for unnumbered interfaces Date: Fri, 26 Apr 2002 16:36:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:22:27 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E602201393@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Alex Zinin Cc: Yakov Rekhter , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Fri, 26 Apr 2002 16:22:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ED60.0532A314" 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:zinin@psg.com] > Sent: Friday, April 26, 2002 4:00 PM > To: Fedyk, Don [BL60:1A00:EXCH] > Cc: Yakov Rekhter; ccamp@ops.ietf.org > 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" RE: TE metric and graceful restart

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:zinin@psg.com]
> Sent: Friday, April 26, 2002 4:00 PM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: Yakov Rekhter; ccamp@ops.ietf.org
> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:21:28 -0700 Message-Id: <4.3.2.7.2.20020426160854.04b2a438@sword.cisco.com> Date: Fri, 26 Apr 2002 16:20:47 -0400 To: Alex Zinin From: Zafar Ali Subject: Re: TE metric and graceful restart Cc: Yakov Rekhter , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27231316==_.ALT" --=====================_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: zali@cisco.com --=====================_27231316==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com --=====================_27231316==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:15:56 -0700 Message-ID: <39469E08BD83D411A3D900204840EC55763148@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Yakov Rekhter'" , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Fri, 26 Apr 2002 16:15:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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. -> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 13:00:49 -0700 Date: Fri, 26 Apr 2002 13:00:13 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <19016367636.20020426130013@psg.com> To: "Don Fedyk" CC: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 12:59:42 -0700 Date: Fri, 26 Apr 2002 12:58:16 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <6516250829.20020426125816@psg.com> To: Zafar Ali CC: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 12:37:44 -0700 Message-Id: <4.3.2.7.2.20020426152754.04b2a438@sword.cisco.com> Date: Fri, 26 Apr 2002 15:36:28 -0400 To: Alex Zinin , Yakov Rekhter From: Zafar Ali Subject: Re: TE metric and graceful restart Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24572523==_.ALT" --=====================_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: zali@cisco.com --=====================_24572523==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com --=====================_24572523==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 12:12:50 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60220124B@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Alex Zinin , Yakov Rekhter Cc: ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Fri, 26 Apr 2002 15:12:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ED56.433DDC64" 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:zinin@psg.com] > Sent: Friday, April 26, 2002 2:55 PM > To: Yakov Rekhter > Cc: ccamp@ops.ietf.org > 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" RE: TE metric and graceful restart

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:zinin@psg.com]
> Sent: Friday, April 26, 2002 2:55 PM
> To: Yakov Rekhter
> Cc: ccamp@ops.ietf.org
> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 11:56:35 -0700 Date: Fri, 26 Apr 2002 11:54:41 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <17912435083.20020426115441@psg.com> To: Yakov Rekhter CC: ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 10:34:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Mannie, Eric" To: 'Manoj Agiwal' , "Gmpls-Ops (E-mail)" , ccamp@ops.ietf.org, "mpls@UU. NET (E-mail)" 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:ManojA@netbrahma.com] Sent: Thursday, April 25, 2002 10:10 AM To: Gmpls-Ops (E-mail); ccamp@ops.ietf.org; 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 ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 07:32:26 -0700 Message-ID: <001901c1ed09$8009d0a0$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: Subject: Suggested label and Label Set tlv doubts Date: Fri, 26 Apr 2002 20:02:39 +1000 Organization: wipro technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ec5d3c55-5914-11d6-af80-0080c8048dde" 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
hai ,
 
          &nbs= p; Since=20 the suggested label and label set tlvs are optional in a Generalized = label=20 request, how do i handle
       =20     a situation when someone has sent a request with both = the=20 TLVs present ??
   
       =20     Do label set tlv has higher priority over suggested = label in=20 which case i can go ahead ignoring the
       =20     suggested label and try to satisfy the request with = label set=20 as constraint on label or do i need to
          &nbs= p; satisfy=20 the suggested label constraint since my upstream has sent me the = suggested label=20 with
       =20     an assumption that it will be satisfied and moreover = since it=20 would have created a crossconnect also.
       =20     And ignore the label set tlv.
 
       =20     I understand that this is a scenario where upstream = is=20 malfunctioning but that needs to be handled for sure and
          &nbs= p; cannot=20 be ignored
 
       =20     Please do clarify things ...
 
thanks
venkat
------=_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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 06:45:17 -0700 Cc: "Gmpls-Ops (E-mail)" , ccamp@ops.ietf.org, "mpls@UU. NET (E-mail)" Message-ID: <3CC95952.335D8AAB@lucent.com> Date: Fri, 26 Apr 2002 15:42:42 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Manoj Agiwal Original-CC: "Gmpls-Ops (E-mail)" , ccamp@ops.ietf.org, "mpls@UU. NET (E-mail)" Subject: Re: VT Switching Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 05:44:30 -0700 Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048E@mailserver.netbrahma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "''Ccamp (E-mail)'" Cc: "'Gmpls-Ops (E-mail)'" , "'mpls@UU. NET (E-mail)'" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Apr 2002 03:14:14 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CC92789.711EA6C9@lucent.com> Date: Fri, 26 Apr 2002 12:10:17 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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. > = > > =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: zali@cisco.com -- = +------------------------------------------------------------------+ | 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Apr 2002 12:50:21 -0700 Message-Id: <200204251947.g3PJlvT99089@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75848.1019764077.1@juniper.net> Date: Thu, 25 Apr 2002 12:47:57 -0700 From: Yakov Rekhter 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Apr 2002 10:25:52 -0700 Message-Id: <4.3.2.7.2.20020425111458.02d57510@sword.cisco.com> Date: Thu, 25 Apr 2002 13:23:18 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9785130==_.ALT" --=====================_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 > =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_9785130==_.ALT Content-Type: text/html; charset="us-ascii" 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: zali@cisco.com
 --=====================_9785130==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Apr 2002 09:17:23 -0700 Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048C@mailserver.netbrahma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "Gmpls-Ops (E-mail)" , , "mpls@UU. NET (E-mail)" 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 ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Apr 2002 06:01:07 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CC7FD0D.ACB20EA8@lucent.com> Date: Thu, 25 Apr 2002 14:56:45 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Apr 2002 01:22:58 -0700 Message-ID: From: Heiles Juergen To: "'David Wang'" , "'ccamp@ops.ietf.org'" Cc: Todor Markov , "Steven D. Sensel" Subject: RE: Question about SONET Transparency Date: Thu, 25 Apr 2002 10:21:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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:david.wang@metro-optix.com] > Sent: Wednesday, April 24, 2002 6:15 PM > To: 'ccamp@ops.ietf.org' > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Apr 2002 23:36:19 -0700 Message-Id: <4.3.2.7.2.20020425021443.05167eb8@sword.cisco.com> Date: Thu, 25 Apr 2002 02:31:53 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24531834==_.ALT" --=====================_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 > ......" > > > 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:MvanEverdingen@lucent.com | >+------------------------------------------------------------------+ =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 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 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. 

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.



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



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


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 some 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 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 ...<snip>..."
> > Does this imply that the "control channel management" procedure is not *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 following in the draft as a way by which LMP Hellos on a given control channel can be disabled,
> =93If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to=20 zero.=94
> Or one can choose a very high value for the HelloInterval and HelloDeadInterval.
>
> Nonetheless, the configuration parameters for the control channels need to be exchanged using the using Config, ConfigAck, and ConfigNack 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" 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 ?
>
> 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 failure and
> > > control channel failure during RSVP-TE recovery process, etc.
> >
> > 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.
>
> > 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.
>
> > > 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".
>
> 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.
>
> > > > 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           =             &nbs= p;            &n= bsp;      |
| Systems Engineer           &n= bsp;            =             &nbs= p;            |
| 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:Mv= anEverdingen@lucent.com |
+------------------------------------------------------------------+
=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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Apr 2002 15:18:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: David Wang To: "'ccamp@ops.ietf.org'" Cc: Todor Markov , "Steven D. Sensel" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Apr 2002 02:50:09 -0700 Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CC67F3C.4DBC8C10@lucent.com> Date: Wed, 24 Apr 2002 11:47:40 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 ...= ..." > > 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Apr 2002 00:46:24 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CC66251.9989E554@lucent.com> Date: Wed, 24 Apr 2002 09:44:17 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com] > > Sent: Sunday, April 21, 2002 11:00 PM > > To: Jonathan Lang > > Cc: 'ccamp@ops.ietf.org' > > Subject: Re: LMP & neighbor discovery > > > > > > Hello Jonathan, all, > > > > Does "" 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. > > 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, > > > > > > > > > > > > > > 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:MvanEverdingen@lucent.com | > > +------------------------------------------------------------------+ > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 20:40:07 -0700 Message-ID: From: Jonathan Lang To: MvanEverdingen@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Tue, 23 Apr 2002 20:29:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michiel, > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Sunday, April 21, 2002 11:00 PM > To: Jonathan Lang > Cc: 'ccamp@ops.ietf.org' > Subject: Re: LMP & neighbor discovery > > > Hello Jonathan, all, > > Does "" 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. 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, > > > > > > > > > > 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:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 16:20:23 -0700 Message-Id: <4.3.2.7.2.20020423184117.02d768d0@sword.cisco.com> Date: Tue, 23 Apr 2002 19:15:29 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22563855==_.ALT" --=====================_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 > ......" >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 > > > > > > ...... =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 Dear Michiel,

Please see comments in-lined. Jonathan, et all please correct me if I 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 ...<snip>..."
Does this imply that the "control channel management" procedure is not *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 following in the draft as a way by which LMP Hellos on a given control channel can be disabled,
=93If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero.=94
Or one can choose a very high value for the HelloInterval and HelloDeadInterval.

Nonetheless, the configuration parameters for the control channels need to be exchanged using the using Config, ConfigAck, and ConfigNack 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" 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 ?

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 failure and
> control channel failure during RSVP-TE recovery process, etc.

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.

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.



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

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.



> > As stated in section 1= 3 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=20 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=20 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=20 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>...

=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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 07:35:19 -0700 Message-Id: <200204231434.g3NEYbT31446@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: draft-ietf-ccamp-ospf-gmpls-extensions-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95886.1019572477.1@juniper.net> Date: Tue, 23 Apr 2002 07:34:37 -0700 From: Yakov Rekhter 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: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: ccamp@ops.ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135046.I-D@ietf.org> 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: <20020422135046.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 07:35:13 -0700 Message-Id: <200204231432.g3NEW3T31384@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: draft-ietf-ccamp-gmpls-routing-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95344.1019572323.1@juniper.net> Date: Tue, 23 Apr 2002 07:32:03 -0700 From: Yakov Rekhter 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: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: ccamp@ops.ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135056.I-D@ietf.org> 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: <20020422135056.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 04:14:13 -0700 Message-Id: <200204231112.HAA11639@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135036.I-D@ietf.org> 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: <20020422135036.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 04:14:10 -0700 Message-Id: <200204231113.HAA11674@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135056.I-D@ietf.org> 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: <20020422135056.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 04:14:04 -0700 Message-Id: <200204231112.HAA11658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135046.I-D@ietf.org> 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: <20020422135046.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 04:14:01 -0700 Message-Id: <200204231112.HAA11623@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135019.I-D@ietf.org> 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: <20020422135019.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Apr 2002 02:17:45 -0700 Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CC5260A.9FF64440@lucent.com> Date: Tue, 23 Apr 2002 11:14:50 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Zafar, Thanks for your answers. You start by stating "The control channel failure detection mechanism is required if ......" 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 > > > > ...... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Apr 2002 16:02:28 -0700 Message-Id: <4.3.2.7.2.20020422181158.040166a0@sword.cisco.com> Date: Mon, 22 Apr 2002 18:59:45 -0400 To: "Ravi Ravindran", Michiel van Everdingen From: Zafar Ali Subject: RE: Question on LMP. Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_31894842==_.ALT" --=====================_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:zali@cisco.com] >Sent: Monday, April 22, 2002 12:47 PM >To: Michiel van Everdingen >Cc: Manoj Sontakke; Jonathan Lang; ccamp@ops.ietf.org >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. > ================= 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" 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:zali@cisco.com]
Sent: Monday, April 22, 2002 12:47 PM
To: Michiel van Everdingen
Cc: Manoj Sontakke; Jonathan Lang; ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Apr 2002 12:13:09 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E63046F4@zcard0ke.ca.nortel.com> From: "Ravi Ravindran" To: "'Zafar Ali'" , Michiel van Everdingen Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Question on LMP. Date: Mon, 22 Apr 2002 15:08:38 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA31.1BD26578" 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:zali@cisco.com] Sent: Monday, April 22, 2002 12:47 PM To: Michiel van Everdingen Cc: Manoj Sontakke; Jonathan Lang; ccamp@ops.ietf.org 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:manojs@sasken.com ] > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > To: ccamp@ops.ietf.org > > > > 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 > > ------_=_NextPart_001_01C1EA31.1BD26578 Content-Type: text/html; 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:zali@cisco.com]
Sent: Monday, April 22, 2002 12:47 PM
To: Michiel van Everdingen
Cc: Manoj Sontakke; Jonathan Lang; ccamp@ops.ietf.org
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:manojs@sasken.com]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: ccamp@ops.ietf.org
> > > > 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Apr 2002 09:52:06 -0700 Message-Id: <4.3.2.7.2.20020422112137.042e26f8@sword.cisco.com> Date: Mon, 22 Apr 2002 12:47:23 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9573626==_.ALT" --=====================_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:manojs@sasken.com] > > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > > To: ccamp@ops.ietf.org > > > > > 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 > > > > --=====================_9573626==_.ALT Content-Type: text/html; charset="iso-8859-1" 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 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:manojs@sasken.com]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > > --------------------------------------------------------------
> > > > -----------------------------
> > > > Q1.  Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > > >            =      -----------------          = ;     -----------------
> > > >            =      |            &nb= sp;  |            &nb= sp;  |            &nb= sp;  |
> > > >            =      |            if1|---------------|if1         = ;   |
> > > >            =      |            if2|---------------|if2         = ;   |
> > > >            =      |     OXC 1     |            &nb= sp;  |     OXC 2     |
> > > >            =      |             d1|---------------|d1         &= nbsp;   |
> > > >            =      |             d2|---------------|d2         &= nbsp;   |
> > > >            =      -----------------
> > > > -----------------
> > > >
> > > >
> > > > 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=20 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=92s 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=85 Zafar
>
> <snip>
--=====================_9573626==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Apr 2002 06:51:24 -0700 Message-ID: <9027F68B07E7D511AE9400B0D0787DC0070489@mailserver.netbrahma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "'ccamp@ops.ietf.org'" , "mpls@UU. NET (E-mail)" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Apr 2002 00:34:02 -0700 Message-ID: <3CC3BC8A.1D24A54@sasken.com> Date: Mon, 22 Apr 2002 13:02:26 +0530 From: Manoj Sontakke Organization: Sasken Communication Technologies Ltd. MIME-Version: 1.0 To: Michiel van Everdingen CC: Zafar Ali , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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:manojs@sasken.com] > > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > > To: ccamp@ops.ietf.org > > > > > 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 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Apr 2002 23:33:38 -0700 Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CC3AE95.C87B52E@lucent.com> Date: Mon, 22 Apr 2002 08:32:53 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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:manojs@sasken.com] > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > To: ccamp@ops.ietf.org > > > > 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 > = > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Apr 2002 23:11:28 -0700 Message-ID: <3CC3A952.FB6DFE87@lucent.com> Date: Mon, 22 Apr 2002 08:10:26 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: applicability of LMP's verify procedure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Apr 2002 23:03:35 -0700 Cc: "'ccamp@ops.ietf.org'" Message-ID: <3CC3A6DB.EBB29F47@lucent.com> Date: Mon, 22 Apr 2002 07:59:55 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: "'ccamp@ops.ietf.org'" Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, all, Does "" 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, > > > > > > 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Apr 2002 05:36:40 -0700 Message-ID: From: Heiles Juergen To: "'venkat'" , Maarten Vissers , Vinay Vernekar Cc: "ccamp+AEA-ops.ietf.org" , "gmpls-ops+AEA-mplsrc.com" Subject: RE: Need for hierarchical SONET/SDH LSPs. Date: Fri, 19 Apr 2002 14:33:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" 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- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Apr 2002 02:26:24 -0700 Message-ID: From: neil.2.harrison@bt.com To: Heinrich.Hummel@icn.siemens.de, ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Subject: RE: Need for hierarchical SONET/SDH LSPs. Date: Fri, 19 Apr 2002 10:22:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E783.C40330C0" 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:Heinrich.Hummel@icn.siemens.de] Sent: 19 April 2002 08:33 To: 'Vinay Vernekar'; ccamp@ops.ietf.org; gmpls-ops@mplsrc.com 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"
Heinrich...please see below.  regards, Neil
-----Original Message-----
From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de]
Sent: 19 April 2002 08:33
To: 'Vinay Vernekar'; ccamp@ops.ietf.org; gmpls-ops@mplsrc.com
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Apr 2002 00:38:29 -0700 Message-ID: From: Hummel Heinrich To: "'Vinay Vernekar'" , ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Subject: AW: Need for hierarchical SONET/SDH LSPs. Date: Fri, 19 Apr 2002 09:33:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E774.80C521B0" 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:vinay.vernekar@wipro.com] Gesendet: Dienstag, 16. April 2002 15:18 An: ccamp@ops.ietf.org; gmpls-ops@mplsrc.com 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"
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.
 
Heinrich Hummel
Siemens
 
 
 
 
 

 
 -----Ursprüngliche Nachricht-----
Von: Vinay Vernekar [mailto:vinay.vernekar@wipro.com]
Gesendet: Dienstag, 16. April 2002 15:18
An: ccamp@ops.ietf.org; gmpls-ops@mplsrc.com
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 -
 
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
 
------_=_NextPart_001_01C1E774.80C521B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Apr 2002 13:22:41 -0700 Message-ID: From: Jonathan Lang To: 'S Ramesh' , ccamp@ops.ietf.org Cc: OIF Subject: RE: LMP Doubt Date: Thu, 18 Apr 2002 13:12:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh, Please see inline. Thanks, Jonathan > -----Original Message----- > From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > Sent: Thursday, April 18, 2002 2:45 AM > To: ccamp@ops.ietf.org > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Apr 2002 10:22:26 -0700 Message-ID: From: "Cheng, Dean" To: 'Yakov Rekhter' , ccamp@ops.ietf.org Subject: RE: encoding link id for unnumbered interfaces Date: Thu, 18 Apr 2002 10:19:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:yakov@juniper.net] > Sent: Thursday, April 18, 2002 6:00 AM > To: ccamp@ops.ietf.org > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Apr 2002 06:03:24 -0700 Message-Id: <200204181300.g3ID04T31154@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: encoding link id for unnumbered interfaces MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52093.1019134804.1@juniper.net> Date: Thu, 18 Apr 2002 06:00:04 -0700 From: Yakov Rekhter 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Apr 2002 02:50:19 -0700 Message-ID: <009d01c1e69a$eedd09e0$77dca8c0@Sonal.alc.wipinfo.soft.net> Reply-To: "venkat" From: "Venkat Dabbara" To: "Maarten Vissers" , "Vinay Vernekar" Cc: , Subject: Re: Need for hierarchical SONET/SDH LSPs. Date: Thu, 18 Apr 2002 15:36:04 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-acdc5fdf-52af-11d6-af80-0080c8048dde" 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Apr 2002 02:41:16 -0700 Message-ID: <3CBE9597.CBBA09B9@npd.hcltech.com> Date: Thu, 18 Apr 2002 15:14:55 +0530 From: S Ramesh Organization: HCL Technologies Limited. MIME-Version: 1.0 To: "ccamp@ops.ietf.org" CC: OIF , S R a m e s h Subject: LMP Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Apr 2002 09:09:35 -0700 Reply-To: From: "Vishal Sharma" To: "Zhi-Wei Lin" Cc: "Kireeti Kompella" , "CCAMP" , "Greg Bernstein" , "Eric Mannie" , "Ronald P. Bonica" , , 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:zwlin@lucent.com] > Sent: Wednesday, April 17, 2002 11:56 AM > To: v.sharma@ieee.org > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > >>Behalf Of Kireeti Kompella > >>Sent: Tuesday, March 19, 2002 11:42 AM > >>To: ccamp@ops.ietf.org > >>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) > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Apr 2002 08:59:47 -0700 Message-ID: <3CBD9B0E.4070300@lucent.com> Date: Wed, 17 Apr 2002 11:55:58 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: v.sharma@ieee.org CC: Kireeti Kompella , CCAMP , Greg Bernstein , Eric Mannie , "Ronald P. Bonica" Subject: Re: Progressing draft-ccamp-sdhsonet-control-frmwrk-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Kireeti Kompella >>Sent: Tuesday, March 19, 2002 11:42 AM >>To: ccamp@ops.ietf.org >>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) >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Apr 2002 00:02:08 -0700 Message-ID: <20020417070048.40550.qmail@web13001.mail.yahoo.com> Date: Wed, 17 Apr 2002 00:00:48 -0700 (PDT) From: Jianwu HE Subject: about TE link (GMPLS) and SNPP link (ASON) To: Zhi-Wei Lin Cc: ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 jianwuhe@hotmail.com Beijing Univ.of Posts and Telecomm. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 22:53:14 -0700 Message-Id: <4.3.2.7.2.20020416103122.04b51348@sword.cisco.com> Date: Wed, 17 Apr 2002 01:41:28 -0400 To: Bala Rajagopalan , , mlazer@att.com From: Zafar Ali Subject: RE: UNI end-to-end sessions Cc: , , Bala Rajagopalan Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_97277567==_.ALT" --=====================_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 >oif-signal@oiforum.com (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:Diego.Caviglia@marconi.com] > > Sent: Wednesday, April 10, 2002 4:21 AM > > To: mlazer@att.com > > Cc: "Gino Carrozzo" > 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: diego.caviglia@marconi.com > > Tel: +39 0 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > > > > > "Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 > > 04.41.05 > > > > Sent by: owner-ccamp@ops.ietf.org > > > > > > To: "Gino Carrozzo" , "ccamp" > > > > cc: > > > > 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 > > mlazer@att.com > > > > -----Original Message----- > > From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] > > Sent: Tuesday, April 09, 2002 5:45 AM > > To: ccamp > > Cc: braja@tellium.com > > 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" At 09:45 AM 4/10/2002 -0400, Bala Rajagopalan wrote:

Please post UNI related messages to
oif-signal@oiforum.com (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:Diego.Caviglia@marconi.com]
> Sent: Wednesday, April 10, 2002 4:21 AM
> To: mlazer@att.com
> 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: diego.caviglia@marconi.com
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
>
>
>
> "Lazer, Monica A, ALCNS" <mlazer@att.com>@ops.ietf.org on 10/04/2002
> 04.41.05
>
> Sent by:  owner-ccamp@ops.ietf.org
>
>
> To:   "Gino Carrozzo" <g.carrozzo@cpr.it>, "ccamp"
> <ccamp@ops.ietf.org>
> cc:   <braja@tellium.com>
>
> 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
> mlazer@att.com
>
> -----Original Message-----
> From: Gino Carrozzo [mailto:g.carrozzo@cpr.it]
> Sent: Tuesday, April 09, 2002 5:45 AM
> To: ccamp
> Cc: braja@tellium.com
> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 22:47:32 -0700 Reply-To: From: "Vishal Sharma" To: "venkat" , Subject: RE: Doubts regarding SONET/SDH label Date: Wed, 17 Apr 2002 01:52:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 15:23:06 -0700 Message-ID: From: Jonathan Lang To: "'MvanEverdingen@lucent.com'" Cc: "'ccamp@ops.ietf.org'" Subject: FW: LMP & neighbor discovery Date: Tue, 16 Apr 2002 15:13:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michiel, > > 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:MvanEverdingen@lucent.com] > > > Sent: Thursday, April 11, 2002 9:03 AM > > > To: Jonathan Lang > > > Cc: ccamp@ops.ietf.org > > > 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:MvanEverdingen@lucent.com] > > > > > Sent: Tuesday, April 09, 2002 12:41 AM > > > > > To: ccamp@ops.ietf.org > > > > > 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:MvanEverdingen@lucent.com | > > > > > > > > > +------------------------------------------------------------------+ > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 08:20:37 -0700 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" Cc: "CCAMP" , "Greg Bernstein" , "Eric Mannie" , "Ronald P. Bonica" Subject: Progressing draft-ccamp-sdhsonet-control-frmwrk-00.txt Date: Tue, 16 Apr 2002 11:26:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Tuesday, March 19, 2002 11:42 AM > To: ccamp@ops.ietf.org > 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) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 08:09:35 -0700 Cc: ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Message-ID: <3CBC3E6A.7D7EDB99@lucent.com> Date: Tue, 16 Apr 2002 17:08:26 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Vinay Vernekar Original-CC: ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Subject: Re: Need for hierarchical SONET/SDH LSPs. Content-Type: multipart/mixed; boundary="------------1EC28BB1FFF446944CCE43C7" 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:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------1EC28BB1FFF446944CCE43C7-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 06:44:44 -0700 Message-Id: <4.3.2.7.2.20020416094154.04d4c168@sword.cisco.com> Date: Tue, 16 Apr 2002 09:43:32 -0400 To: Michiel van Everdingen From: Zafar Ali Subject: Re: Question on LMP. Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_39133400==_.ALT" --=====================_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:manojs@sasken.com] > > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > > To: ccamp@ops.ietf.org > > > > > 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 > > > > --=====================_39133400==_.ALT Content-Type: text/html; charset="iso-8859-1" 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:manojs@sasken.com]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > > --------------------------------------------------------------
> > > > -----------------------------
> > > > Q1.  Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > > >            =      -----------------          = ;     -----------------
> > > >            =      |            &nb= sp;  |            &nb= sp;  |            &nb= sp;  |
> > > >            =      |            if1|---------------|if1         = ;   |
> > > >            =      |            if2|---------------|if2         = ;   |
> > > >            =      |     OXC 1     |            &nb= sp;  |     OXC 2     |
> > > >            =      |             d1|---------------|d1         &= nbsp;   |
> > > >            =      |             d2|---------------|d2         &= nbsp;   |
> > > >            =      -----------------
> > > > -----------------
> > > >
> > > >
> > > > 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=20 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=92s 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=85 Zafar
>
> <snip>
--=====================_39133400==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 06:26:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E54A.08853F52" Subject: RE: Question on LMP-MIB ? Date: Tue, 16 Apr 2002 09:24:27 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C914D46E@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: Question on LMP-MIB ? Thread-Index: AcHk/VHrAh08Idq3TsWElERe1z6xUAATKQuA From: "Martin Dubuc" To: "Zafar Ali" , "Loc Chu" , , 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:zali@cisco.com] Sent: Monday, April 15, 2002 5:36 PM To: Loc Chu; ccamp@ops.ietf.org; Dimitri.Papadimitriou@alcatel.be 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
Zafar,
 
You=20 could keep the remote IPCC address in the LMP MIB (after I add this = field to the=20 control channel table).
 
Martin
-----Original Message-----
From: Zafar Ali=20 [mailto:zali@cisco.com]
Sent: Monday, April 15, 2002 5:36=20 PM
To: Loc Chu; ccamp@ops.ietf.org;=20 Dimitri.Papadimitriou@alcatel.be
Subject: Re: Question on = LMP-MIB=20 ?

At 04:13 PM 4/15/2002 -0500, Loc = Chu=20 wrote:
Hi all,

The Section 3 of the = LMP draft=20 states:

"To establish a control channel, the destination IP = address=20 on the  far end of
 the control channel must be known. = This=20 knowledge may be manually configured
 or automatically = discovered."=20

Also, Section 9 of the LMP draft states:

"The manner = in=20 which a Config message is addressed may depend on the signaling=20
 transport mechanism.  When the transport mechanism is = a=20 point-to-point link, Config
 messages SHOULD be sent to the = Multicast address (224.0.0.1).  Otherwise, Config =
 messages=20 MUST be sent to an IP address on the neighboring node.  This is = configured
 at both ends of the control channel." =

In case=20 of IPCC's are out-of-fiber/out-of-band and NOT point-to-point link, = we have=20 to
use a specific IP address for the remote end of the = IPCC.  Where=20 do we keep the remote
IPCC Address ? =

Hi Loc,

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

Thanks

Regards... Zafar


if not, is it possible to have a field = in=20 lmpControlChannelEntry MIB for configuring
the remote IPCC = address such=20 as:

lmpCcRemoteIpAddr OBJECT-TYPE
  =20 = SYNTAX           &= nbsp;  =20 InetAddress
   MAX-ACCESS    = read-create=20
  =20 = STATUS           &= nbsp;  =20 current
   DESCRIPTION "IP address associated with = remote=20 IPCC."
   ::=3D { lmpControlChannelEntry 23 } =

Thanks in=20 advance for your help or any clarification since my question is too=20
implementation specific.

Regards, 
--=20
Loc Chu
Software Development
Engineer         Alcatel, USA=20
Research &
Innovation          &nb=
sp;     
1000 Coit Rd. Plano, TX 75075 M/S:CTO2
Advanced Routers and Cross Connects   Phone: =
972-477-2463 
Fax:
972-477-2972
 =20
------_=_NextPart_001_01C1E54A.08853F52-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 06:20:33 -0700 Message-ID: <00f101c1e549$2d9690a0$b1dca8c0@alc.wipinfo.soft.net> From: "Vinay Vernekar" To: , Subject: Need for hierarchical SONET/SDH LSPs. Date: Tue, 16 Apr 2002 18:48:19 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-49e12798-512e-11d6-af80-0080c8048dde" 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
Hi,
Can I have a SONET/SDH LSP that passes through a = SONET ADM=20 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=20 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=20 ingress, B as transit and C as the egress??
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. It also mentions that tunnels = should be=20 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=20 should be possible, because the signal type remains same i.e VC-4 = even the=20 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-- ------=_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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 05:57:00 -0700 Cc: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CBC1F6E.75818D46@lucent.com> Date: Tue, 16 Apr 2002 14:56:14 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Zafar Ali Original-CC: Manoj Sontakke , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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:manojs@sasken.com] > > > > Sent: Thursday, April 11, 2002 7:02 AM > > > > To: ccamp@ops.ietf.org > > > > 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 > = > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Apr 2002 05:38:44 -0700 Cc: "'Manoj Sontakke'" , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CBC1A27.5BD0E37F@lucent.com> Date: Tue, 16 Apr 2002 14:33:43 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Ravi Ravindran Original-CC: "'Manoj Sontakke'" , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com] > Sent: Monday, April 15, 2002 10:54 AM > To: Ravindran, Ravi [CAR:0V13:EXCH] > Cc: 'Manoj Sontakke'; Jonathan Lang; ccamp@ops.ietf.org > 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:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 20:45:24 -0700 Message-Id: <4.3.2.7.2.20020415234022.025cab70@sword.cisco.com> Date: Mon, 15 Apr 2002 17:36:00 -0400 To: Loc Chu , ccamp@ops.ietf.org, Dimitri.Papadimitriou@alcatel.be From: Zafar Ali Subject: Re: Question on LMP-MIB ? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3052419==_.ALT" --=====================_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" 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 14:37:04 -0700 Message-Id: <4.3.2.7.2.20020415173011.04ac8ef0@sword.cisco.com> Date: Mon, 15 Apr 2002 17:35:16 -0400 To: Loc Chu , ccamp@ops.ietf.org, Dimitri.Papadimitriou@alcatel.be From: Zafar Ali Subject: Re: Question on LMP-MIB ? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24540397==_.ALT" --=====================_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" 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 14:15:23 -0700 Message-ID: <3CBB4291.D3300A8E@alcatel.com> Date: Mon, 15 Apr 2002 16:13:54 -0500 From: Loc Chu Organization: Research & Innovation MIME-Version: 1.0 To: ccamp@ops.ietf.org, Dimitri.Papadimitriou@alcatel.be Subject: Question on LMP-MIB ? Content-Type: multipart/alternative; boundary="------------4D851535EE0E6DB39204E4CD" --------------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 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 13:53:02 -0700 Date: Mon, 15 Apr 2002 13:50:18 -0700 (PDT) From: Kireeti Kompella Message-Id: <200204152050.g3FKoIp76199@kummer.juniper.net> To: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 10:15:47 -0700 Message-Id: <4.3.2.7.2.20020415124315.016baaa0@sword.cisco.com> Date: Mon, 15 Apr 2002 13:13:21 -0400 To: Manoj Sontakke , Jonathan Lang From: Zafar Ali Subject: Re: Question on LMP. Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8825029==_.ALT" --=====================_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:manojs@sasken.com] > > > Sent: Thursday, April 11, 2002 7:02 AM > > > To: ccamp@ops.ietf.org > > > 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 --=====================_8825029==_.ALT Content-Type: text/html; charset="iso-8859-1" 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:manojs@sasken.com]
> > Sent: Thursday, April 11, 2002 7:02 AM
> > To: ccamp@ops.ietf.org
> > Subject: Question on LMP.
> >
> >
> > Hi,
> >
> > I have two questions on LMP.
> >
> > --------------------------------------------------------------
> > -----------------------------
> > Q1.  Control Channel Question
> >
> > Assuming a configuration as shown.
> >
> >
> >            =      -----------------          = ;     -----------------
> >            =      |            &nb= sp;  |            &nb= sp;  |            &nb= sp;  |
> >            =      |            if1|---------------|if1         = ;   |
> >            =      |            if2|---------------|if2         = ;   |
> >            =      |     OXC 1     |            &nb= sp;  |     OXC 2     |
> >            =      |             d1|---------------|d1         &= nbsp;   |
> >            =      |             d2|---------------|d2         &= nbsp;   |
> >            =      -----------------
> > -----------------
> >
> >
> > 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=92s 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=85 Zafar

<snip> --=====================_8825029==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 09:56:01 -0700 Message-Id: <4.3.2.7.2.20020415093011.00b55d08@mira1.cisco.com> Date: Mon, 15 Apr 2002 09:54:02 -0700 To: mpls@UU.NET From: Suresh Katukam Subject: Re: Fwd: Re: SE style in optical networks Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 09:44:06 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E63046E0@zcard0ke.ca.nortel.com> From: "Ravi Ravindran" To: "'Michiel van Everdingen'" Cc: "'Manoj Sontakke'" , Jonathan Lang , ccamp@ops.ietf.org Subject: RE: Question on LMP. Date: Mon, 15 Apr 2002 12:40:16 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E49C.393012CC" 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:MvanEverdingen@lucent.com] Sent: Monday, April 15, 2002 10:54 AM To: Ravindran, Ravi [CAR:0V13:EXCH] Cc: 'Manoj Sontakke'; Jonathan Lang; ccamp@ops.ietf.org 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ ------_=_NextPart_001_01C1E49C.393012CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question on LMP.

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:MvanEverdingen@lucent.c= om]
Sent: Monday, April 15, 2002 10:54 AM
To: Ravindran, Ravi [CAR:0V13:EXCH]
Cc: 'Manoj Sontakke'; Jonathan Lang; = ccamp@ops.ietf.org
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          &n= bsp;           &n= bsp;           &n= bsp;        |
| Systems = Engineer          &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;  |
| Lucent Technologies - Optical Networking = Group           &= nbsp;       |
| Botterstraat 45, 1271 = XL       Phone : +31 35 687 = 4883           = |
| P.O. Box 18, 1270 = AA           = Fax   : +31 35 687 = 5976           = |
| Huizen, The = Netherlands        mailto:MvanEverdingen@lucent.c= om  |
+--------------------------------------------------------------= ----+

------_=_NextPart_001_01C1E49C.393012CC-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 07:55:30 -0700 Cc: "'Manoj Sontakke'" , Jonathan Lang , ccamp@ops.ietf.org Message-ID: <3CBAE970.F717D179@lucent.com> Date: Mon, 15 Apr 2002 16:53:36 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Ravi Ravindran Original-CC: "'Manoj Sontakke'" , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 07:31:22 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CBAE3E2.37666FA9@lucent.com> Date: Mon, 15 Apr 2002 16:29:54 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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:MvanEverdingen@lucent.com] > > Sent: Thursday, April 11, 2002 9:03 AM > > To: Jonathan Lang > > Cc: ccamp@ops.ietf.org > > 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:MvanEverdingen@lucent.com] > > > > Sent: Tuesday, April 09, 2002 12:41 AM > > > > To: ccamp@ops.ietf.org > > > > 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:MvanEverdingen@lucent.com | > > > > > > +------------------------------------------------------------------+ > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 06:41:28 -0700 Message-ID: <3CBAD87E.4030403@lucent.com> Date: Mon, 15 Apr 2002 09:41:18 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: Suresh Katukam CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Fwd: Re: SE style in optical neyworks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 06:37:39 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E63046DE@zcard0ke.ca.nortel.com> From: "Ravi Ravindran" To: "'Manoj Sontakke'" , Jonathan Lang Cc: ccamp@ops.ietf.org Subject: RE: Question on LMP. Date: Mon, 15 Apr 2002 09:36:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E482.8E453A2C" 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:manojs@sasken.com] Sent: Monday, April 15, 2002 5:53 AM To: Jonathan Lang Cc: ccamp@ops.ietf.org 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:manojs@sasken.com] > > Sent: Thursday, April 11, 2002 7:02 AM > > To: ccamp@ops.ietf.org > > 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 RE: Question on LMP.

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:manojs@sasken.com]
Sent: Monday, April 15, 2002 5:53 AM
To: Jonathan Lang
Cc: ccamp@ops.ietf.org
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:manojs@sasken.com]
> > Sent: Thursday, April 11, 2002 7:02 = AM
> > To: ccamp@ops.ietf.org
> > Subject: Question on LMP.
> >
> >
> > Hi,
> >
> > I have two questions on LMP.
> >
> > = --------------------------------------------------------------
> > -----------------------------
> > Q1.  Control Channel Question
> >
> > Assuming a configuration as shown.
> >
> >
> = >           &n= bsp;     = -----------------         &= nbsp;     -----------------
> = >           &n= bsp;     = |            = ;   = |            = ;   = |            = ;   |
> = >           &n= bsp;     = |            = if1|---------------|if1        &= nbsp;   |
> >       &n= bsp;         = |            = if2|---------------|if2        &= nbsp;   |
> = >           &n= bsp;     |     OXC = 1     = |            = ;   |     OXC 2     = |
> = >           &n= bsp;     = |            = ; = d1|---------------|d1        &nb= sp;    |
> = >           &n= bsp;     = |            = ; = d2|---------------|d2        &nb= sp;    |
> = >           &n= bsp;     -----------------
> > -----------------
> >
> >
> > 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 05:21:34 -0700 Message-ID: <001401c1e454$2be37fc0$77dca8c0@Sonal.alc.wipinfo.soft.net> Reply-To: "venkat" From: "Venkat Dabbara" To: Subject: Doubts regarding SONET/SDH label Date: Mon, 15 Apr 2002 18:04:30 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-db77ff03-505c-11d6-af80-0080c8048dde" 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 02:53:09 -0700 Message-ID: <3CBAA2DF.AF15A2B@sasken.com> Date: Mon, 15 Apr 2002 15:22:31 +0530 From: Manoj Sontakke Organization: Sasken Communication Technologies Ltd. MIME-Version: 1.0 To: Jonathan Lang CC: ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:manojs@sasken.com] > > Sent: Thursday, April 11, 2002 7:02 AM > > To: ccamp@ops.ietf.org > > 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 > > > > ::= > > > > > > ::= > > > > > > > > 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 and 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Apr 2002 01:33:40 -0700 Cc: John Ellson , CCAMP WG Message-ID: <3CBA8FFF.84283055@lucent.com> Date: Mon, 15 Apr 2002 10:31:59 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sudheer Dharanikota Original-CC: John Ellson , CCAMP WG Subject: Re: SE style in optical neyworks Content-Type: multipart/mixed; boundary="------------F7F455C8377629472E8BC2AE" 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:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------F7F455C8377629472E8BC2AE-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 14 Apr 2002 23:23:54 -0700 Message-Id: <4.3.2.7.2.20020415021219.02191b10@sword.cisco.com> Date: Mon, 15 Apr 2002 02:19:05 -0400 To: Kireeti Kompella From: Zafar Ali Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Cc: Yakov Rekhter , , , , , , , , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_45743045==_.ALT" --=====================_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 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 =93link-local=94 makes much = sense for exchanging the interface identifiers for the unnumbered interfaces.

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.

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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 20:13:08 -0700 Message-ID: <3CB7A176.D7EFC69D@nayna.com> Date: Fri, 12 Apr 2002 20:09:42 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: John Ellson CC: Suresh Katukam , Zhi-Wei Lin , Khuzema Pithewan , CCAMP WG Subject: Re: SE style in optical neyworks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 16:36:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CB76E2E.4080901@lucent.com> Date: Fri, 12 Apr 2002 19:30:54 -0400 From: John Ellson To: Sudheer Dharanikota CC: Suresh Katukam , Zhi-Wei Lin , Khuzema Pithewan , CCAMP WG 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 16:22:48 -0700 Message-ID: From: Jonathan Lang To: 'Fugui Wang' Cc: "ccamp (E-mail)" Subject: RE: draft-ietf-ccamp-lmp-03.txt, CHANNEL_STATUS Date: Fri, 12 Apr 2002 16:15:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Fugui, You are correct. These are bad edits. Thanks, Jonathan > -----Original Message----- > From: Fugui Wang [mailto:fwang@axiowave.com] > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 16:22:09 -0700 Message-ID: From: Fugui Wang To: "'jplang@calient.net'" Cc: "ccamp (E-mail)" Subject: draft-ietf-ccamp-lmp-03.txt, CHANNEL_STATUS Date: Fri, 12 Apr 2002 19:20:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 16:22:06 -0700 Message-ID: From: Jonathan Lang To: 'Manoj Sontakke' , ccamp@ops.ietf.org Subject: RE: Question on LMP. Date: Fri, 12 Apr 2002 16:13:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Manoj Sontakke [mailto:manojs@sasken.com] > Sent: Thursday, April 11, 2002 7:02 AM > To: ccamp@ops.ietf.org > 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 > > ::= > > > ::= > > > > 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 and 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 15:06:37 -0700 Message-Id: <4.3.2.7.2.20020412150415.00b9abf8@mira1.cisco.com> Date: Fri, 12 Apr 2002 15:05:36 -0700 To: Sudheer Dharanikota From: Suresh Katukam Subject: Re: SE style in optical neyworks Cc: John Ellson , Zhi-Wei Lin , Khuzema Pithewan , CCAMP WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 15:04:27 -0700 Message-Id: <4.3.2.7.2.20020412150328.00b782a0@mira1.cisco.com> Date: Fri, 12 Apr 2002 15:03:46 -0700 To: ccamp@ops.ietf.org, mpls@UU.NET From: Suresh Katukam Subject: Fwd: Re: SE style in optical neyworks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed > >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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 14:40:07 -0700 Message-ID: From: Jonathan Lang To: 'Michiel van Everdingen' Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Fri, 12 Apr 2002 14:32:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michiel, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Thursday, April 11, 2002 9:03 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > 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:MvanEverdingen@lucent.com] > > > Sent: Tuesday, April 09, 2002 12:41 AM > > > To: ccamp@ops.ietf.org > > > 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:MvanEverdingen@lucent.com | > > > > +------------------------------------------------------------------+ > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 14:15:42 -0700 Message-ID: <3CB74D74.DB226163@nayna.com> Date: Fri, 12 Apr 2002 14:11:16 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: John Ellson CC: Suresh Katukam , Zhi-Wei Lin , Khuzema Pithewan , CCAMP WG Subject: Re: SE style in optical neyworks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 09:24:01 -0700 Message-ID: <2135200C183FD5119588009027DE57230151AFF2@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Yakov Rekhter'" , Zhi-Wei Lin Cc: ccamp@ops.ietf.org Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents Date: Fri, 12 Apr 2002 09:22:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:yakov@juniper.net] Sent: Friday, April 12, 2002 7:09 AM To: Zhi-Wei Lin Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 09:04:54 -0700 Message-ID: From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: LMP MIB Date: Fri, 12 Apr 2002 18:03:11 +0200 MIME-Version: 1.0 Content-Type: text/plain > >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: smilint@ibr.cs.tu-bs.de 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: smilint@ibr.cs.tu-bs.de [mailto:smilint@ibr.cs.tu-bs.de] 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 07:51:08 -0700 Message-Id: <4.3.2.7.2.20020412104700.025639e8@bucket> Date: Fri, 12 Apr 2002 10:49:43 -0400 To: "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: RE: LMP MIB Cc: Kireeti Kompella , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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:kireeti@juniper.net] > > Sent: Thursday, April 11, 2002 7:34 PM > > To: ccamp@ops.ietf.org > > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 07:24:50 -0700 Message-ID: From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: LMP MIB Date: Fri, 12 Apr 2002 16:24:18 +0200 MIME-Version: 1.0 Content-Type: text/plain 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:kireeti@juniper.net] > Sent: Thursday, April 11, 2002 7:34 PM > To: ccamp@ops.ietf.org > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 07:11:30 -0700 Message-Id: <200204121408.g3CE8ZT60454@merlot.juniper.net> To: Zhi-Wei Lin cc: ccamp@ops.ietf.org Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18286.1018620515.1@juniper.net> Date: Fri, 12 Apr 2002 07:08:35 -0700 From: Yakov Rekhter 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 05:41:59 -0700 Message-ID: <3CB6D5AA.40001@lucent.com> Date: Fri, 12 Apr 2002 08:40:10 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 04:07:02 -0700 Message-ID: <37701240971DD31193970000F6CCB9F7033A46C1@duke.datcon.co.uk> From: Andy Kilpatrick To: Juniper - Kireeti Kompella Cc: ccamp@ops.ietf.org, Meriton - Martin Dubuc , Calient - Jonathan Lang Subject: RE: LMP MIB Date: Fri, 12 Apr 2002 12:05:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: ak@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: Juniper - Kireeti Kompella Sent: 11 April 2002 18:33 To: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Apr 2002 01:40:33 -0700 Date: Fri, 12 Apr 2002 01:39:18 -0700 (PDT) From: Kireeti Kompella To: Zafar Ali cc: Yakov Rekhter , , , , , , , , , Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Message-ID: <20020412013354.X64564-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 22:45:32 -0700 Message-Id: <4.3.2.7.2.20020412013258.046b6e78@sword.cisco.com> Date: Fri, 12 Apr 2002 01:42:21 -0400 To: kireeti@juniper.net, Yakov Rekhter , abanerjee@calient.net, jdrake@calient.net, greg@ciena.com, dwfedyk@nortelnetworks.com, eric.mannie@gtsgroup.com, dsaha@tellium.com, v.sharma@ieee.org From: Zafar Ali Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Cc: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16882155==_.ALT" --=====================_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 Dear Fellow Authors:

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?

Thanks

Regards=85 Zafar --=====================_16882155==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 16:18:59 -0700 Date: Thu, 11 Apr 2002 16:18:20 -0700 (PDT) From: Kireeti Kompella To: Baktha Muralidharan cc: Subject: Re: LMP MIB Message-ID: <20020411161247.E63479-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 16:06:59 -0700 Date: Thu, 11 Apr 2002 16:00:45 -0700 From: Alex Zinin Reply-To: Alex Zinin Organization: Nexsi Systems Message-ID: <1192435487.20020411160045@nexsi.com> To: Yakov Rekhter Cc: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 12:51:11 -0700 Message-Id: <4.3.2.7.2.20020411154047.0171d308@funnel.cisco.com> Date: Thu, 11 Apr 2002 15:49:49 -0400 To: ccamp@ops.ietf.org From: Baktha Muralidharan Subject: Re: LMP MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 10:35:09 -0700 Date: Thu, 11 Apr 2002 10:33:30 -0700 (PDT) From: Kireeti Kompella To: Subject: LMP MIB Message-ID: <20020411102142.E62313-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 09:04:35 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CB5B3CE.472F5CC7@lucent.com> Date: Thu, 11 Apr 2002 18:03:26 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com] > > Sent: Tuesday, April 09, 2002 12:41 AM > > To: ccamp@ops.ietf.org > > 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:MvanEverdingen@lucent.com | > > +------------------------------------------------------------------+ > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 07:02:33 -0700 Message-ID: <3CB5975F.5D8655D9@sasken.com> Date: Thu, 11 Apr 2002 19:32:07 +0530 From: Manoj Sontakke Organization: Sasken Communication Technologies Ltd. MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ::= ::= 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 and helps improve the message realiability ? ----------------------------------------------------------------------------------------- Any comments in this regard will be appreciated. Thanks, Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Apr 2002 06:19:37 -0700 Message-Id: <200204111314.g3BDE5T90036@merlot.juniper.net> To: Alex Zinin cc: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17591.1018530845.1@juniper.net> Date: Thu, 11 Apr 2002 06:14:05 -0700 From: Yakov Rekhter 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 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 19:05:23 -0700 Message-ID: From: Jonathan Lang To: 'Michiel van Everdingen' , ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Wed, 10 Apr 2002 18:56:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Michiel, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Tuesday, April 09, 2002 12:41 AM > To: ccamp@ops.ietf.org > 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:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 17:55:55 -0700 Message-ID: <2135200C183FD5119588009027DE5723FD2FB7@wntcsdexg02.csd.ciena.com> From: "Ong, Lyndon" To: "'Suresh Katukam'" , Zhi-Wei Lin Cc: ccamp@ops.ietf.org Subject: RE: Question on Restart Procedure - Restart Time Date: Wed, 10 Apr 2002 17:55:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:skatukam@cisco.com] Sent: Wednesday, April 10, 2002 5:25 PM To: Zhi-Wei Lin Cc: ccamp@ops.ietf.org 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 >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 17:25:44 -0700 Message-ID: <008401c1e0ef$4469e240$21bffe81@soohyunc> From: "Soo-Hyun Choi" To: "Zhi-Wei Lin" , "Sudheer Dharanikota" Cc: "Diego Caviglia" , , "Gino Carrozzo , "ccamp , ", Subject: Re: UNI end-to-end sessions Date: Thu, 11 Apr 2002 09:24:38 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C1E13A.B42B3D90" 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 ; mlazer@att.com ; Gino Carrozzo 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: diego.caviglia@marconi.com >>Tel: +39 0 10 6003 808 >>Via A. Negrone 1A 16153 Genoa (Italy) >>http://www.marconi.com >> >>"Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 >>04.41.05 >> >>Sent by: owner-ccamp@ops.ietf.org >> >>To: "Gino Carrozzo" , "ccamp" >>cc: >> >>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 >>mlazer@att.com >> >>-----Original Message----- >>From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] >>Sent: Tuesday, April 09, 2002 5:45 AM >>To: ccamp >>Cc: braja@tellium.com >>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
Hi,
 
As you might know, the NNI interoperability test at = the=20 Supercomm 2002 has been cancelled.
But, you can still refer to the document=20 (oif2002.025) _just_ for your reference.
(It's under heavy discussion among the = principal=20 members in the OIF.)
 
Soo-Hyun
----- Original Message = -----
From: Zhi-Wei = Lin
Cc: Diego Caviglia ; mlazer@att.com ; Gino = Carrozzo=20 <g.carrozzo ; ccamp <ccamp ; <braja ; oif-signal@oiforum.com =
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=20 the Supercomm NNI work effort
(there is no private NNI effort = within OIF).=20 For folks involved with OIF
and Supercomm NNI, see OIF2002.025, = Section=20 7.4, which clearly includes
the facility to transport UNI-specific = information (such as TNA) from
source UNI to destination = UNI.

This=20 is not part of the IETF GMPLS documents yet. I view the GMPLS work =
in IETF=20 as laying a foundation for using IP-based protocols. For
example, = the OIF=20 and ITU-T may use these protocols to extend the
capability to = support=20 UNI-based, and E-NNI-based signaling and routing.
In fact this is = exactly=20 what was done for the UNI.

Zhi

FYI, I've also added oif-signal@oiforum.com to = the cc:=20 list



Sudheer Dharanikota wrote:

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


------=_NextPart_000_0080_01C1E13A.B42B3D90-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 17:25:41 -0700 Message-Id: <4.3.2.7.2.20020410172308.00b61a20@mira1.cisco.com> Date: Wed, 10 Apr 2002 17:24:46 -0700 To: Zhi-Wei Lin From: Suresh Katukam Subject: Re: Question on Restart Procedure - Restart Time Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 16:22:23 -0700 Message-ID: <3CB4C8B0.7030609@lucent.com> Date: Wed, 10 Apr 2002 19:20:16 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: Suresh Katukam CC: ccamp@ops.ietf.org Subject: Re: Question on Restart Procedure - Restart Time Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 14:53:14 -0700 Message-Id: <4.3.2.7.2.20020410145106.00b43778@mira1.cisco.com> Date: Wed, 10 Apr 2002 14:51:48 -0700 To: ccamp@ops.ietf.org From: Suresh Katukam Subject: Question on Restart Procedure - Restart Time Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 14:39:03 -0700 Message-ID: <3CB4B04F.8534ED42@nayna.com> Date: Wed, 10 Apr 2002 14:36:15 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Zhi-Wei Lin CC: Diego Caviglia , mlazer@att.com, "Gino Carrozzo , "ccamp , ", oif-signal@oiforum.com Subject: Re: UNI end-to-end sessions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 14:27:47 -0700 Message-ID: <3CB4ADBC.6120FAC7@nayna.com> Date: Wed, 10 Apr 2002 14:25:16 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: v.sharma@ieee.org CC: Suresh Katukam , CCAMP WG Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Sudheer Dharanikota > > Sent: Tuesday, April 09, 2002 8:32 PM > > To: Suresh Katukam > > Cc: ccamp@ops.ietf.org > > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 13:36:43 -0700 Message-ID: <3CB4A1E0.3070601@lucent.com> Date: Wed, 10 Apr 2002 16:34:40 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: Sudheer Dharanikota CC: Diego Caviglia , mlazer@att.com, "Gino Carrozzo , "ccamp , ", oif-signal@oiforum.com Subject: Re: UNI end-to-end sessions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 oif-signal@oiforum.com 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: diego.caviglia@marconi.com >>Tel: +39 0 10 6003 808 >>Via A. Negrone 1A 16153 Genoa (Italy) >>http://www.marconi.com >> >>"Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 >>04.41.05 >> >>Sent by: owner-ccamp@ops.ietf.org >> >>To: "Gino Carrozzo" , "ccamp" >>cc: >> >>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 >>mlazer@att.com >> >>-----Original Message----- >>From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] >>Sent: Tuesday, April 09, 2002 5:45 AM >>To: ccamp >>Cc: braja@tellium.com >>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 >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 12:17:25 -0700 Reply-To: From: "Vishal Sharma" To: "Sudheer Dharanikota" , "Suresh Katukam" Cc: Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents Date: Wed, 10 Apr 2002 15:21:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Sudheer Dharanikota > Sent: Tuesday, April 09, 2002 8:32 PM > To: Suresh Katukam > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 07:35:18 -0700 Message-ID: <3CB44D1C.83360D83@nayna.com> Date: Wed, 10 Apr 2002 07:33:00 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Diego Caviglia CC: mlazer@att.com, "Gino Carrozzo , "ccamp , " Subject: Re: UNI end-to-end sessions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com > > "Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 > 04.41.05 > > Sent by: owner-ccamp@ops.ietf.org > > To: "Gino Carrozzo" , "ccamp" > cc: > > 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 > mlazer@att.com > > -----Original Message----- > From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] > Sent: Tuesday, April 09, 2002 5:45 AM > To: ccamp > Cc: braja@tellium.com > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 07:03:25 -0700 Message-ID: <05707214338CD5119BFF0040A5B170D3E8213A@mail3.tellium.com> From: Bala Rajagopalan To: 'Diego Caviglia' , mlazer@att.com Cc: "\"Gino Carrozzo\" , "\"ccamp\" , Bala Rajagopalan Subject: RE: UNI end-to-end sessions Date: Wed, 10 Apr 2002 09:45:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Please post UNI related messages to oif-signal@oiforum.com (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:Diego.Caviglia@marconi.com] > Sent: Wednesday, April 10, 2002 4:21 AM > To: mlazer@att.com > Cc: "Gino Carrozzo" 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: diego.caviglia@marconi.com > Tel: +39 0 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com > > > > "Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 > 04.41.05 > > Sent by: owner-ccamp@ops.ietf.org > > > To: "Gino Carrozzo" , "ccamp" > > cc: > > 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 > mlazer@att.com > > -----Original Message----- > From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] > Sent: Tuesday, April 09, 2002 5:45 AM > To: ccamp > Cc: braja@tellium.com > 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 > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Apr 2002 01:23:36 -0700 Subject: RE: UNI end-to-end sessions To: mlazer@att.com Cc: ""Gino Carrozzo" , ""ccamp" , " From: "Diego Caviglia" Date: Wed, 10 Apr 2002 10:20:57 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com "Lazer, Monica A, ALCNS" @ops.ietf.org on 10/04/2002 04.41.05 Sent by: owner-ccamp@ops.ietf.org To: "Gino Carrozzo" , "ccamp" cc: 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 mlazer@att.com -----Original Message----- From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] Sent: Tuesday, April 09, 2002 5:45 AM To: ccamp Cc: braja@tellium.com 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 Envelope-to: ccamp-data@psg.com 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 Message-ID: <35BD167AAD17F34F84B265D7951855673B7FDF@OCCLUST03EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: UNI end-to-end sessions Thread-Index: AcHfrFu5HX0r0IHDQYKCWoWRqfu9AgAjFn9w From: "Lazer, Monica A, ALCNS" To: "Gino Carrozzo" , "ccamp" Cc: 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 mlazer@att.com -----Original Message----- From: Gino Carrozzo [mailto:g.carrozzo@cpr.it] Sent: Tuesday, April 09, 2002 5:45 AM To: ccamp Cc: braja@tellium.com 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 17:34:13 -0700 Message-ID: <3CB38804.A499D196@nayna.com> Date: Tue, 09 Apr 2002 17:32:04 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Suresh Katukam CC: ccamp@ops.ietf.org Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 17:00:12 -0700 Message-ID: <2135200C183FD5119588009027DE57230151AFD5@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Suresh Katukam'" , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: CCAMP WG Last Call on GMPLS Routing Documents Date: Tue, 9 Apr 2002 16:57:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:skatukam@cisco.com] Sent: Tuesday, April 09, 2002 1:54 PM To: Kireeti Kompella Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 14:37:17 -0700 Date: Tue, 9 Apr 2002 14:33:38 -0700 (PDT) From: Kireeti Kompella To: Suresh Katukam cc: Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents Message-ID: <20020409142820.W56351-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 13:54:34 -0700 Message-Id: <4.3.2.7.2.20020409134622.00ba8378@mira1.cisco.com> Date: Tue, 09 Apr 2002 13:54:00 -0700 To: Kireeti Kompella From: Suresh Katukam Subject: Re: CCAMP WG Last Call on GMPLS Routing Documents Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 13:11:17 -0700 Date: Tue, 9 Apr 2002 13:04:50 -0700 From: Alex Zinin Reply-To: Alex Zinin Organization: Nexsi Systems Message-ID: <549063452.20020409130450@nexsi.com> To: ccamp@ops.ietf.org Cc: OSPF@DISCUSS.MICROSOFT.COM Subject: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 05:44:05 -0700 Message-Id: <200204091240.IAA03315@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020408122630.I-D@ietf.org> 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: <20020408122630.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 02:46:40 -0700 Message-ID: <016501c1dfab$463d2ae0$d7217283@meta.cpr.it> From: "Gino Carrozzo" To: "ccamp" Cc: Subject: UNI end-to-end sessions Date: Tue, 9 Apr 2002 11:45:24 +0200 Organization: META-CPR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Apr 2002 00:43:01 -0700 Message-ID: <3CB29B14.DE4A533D@lucent.com> Date: Tue, 09 Apr 2002 09:41:08 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Apr 2002 18:59:58 -0700 Date: Mon, 08 Apr 2002 21:49:28 -0400 From: Ron Bonica Subject: RE: IETF 53 CCAMP Minutes To: Eve Varma Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_F+QXrvtPWqlTFzj4dOBxpQ)" 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:evarma@lucent.com] Sent: Monday, April 08, 2002 5:23 PM To: Ron Bonica Cc: ccamp@ops.ietf.org 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
I have=20 added this to the minutes.
 
       &nbs= p;            = ;   =20 thanks,
       &nbs= p;            = ;        =20 Ron
 
-----Original Message-----
From: Eve Varma=20 [mailto:evarma@lucent.com]
Sent: Monday, April 08, 2002 5:23 = PM
To: Ron Bonica
Cc:=20 ccamp@ops.ietf.org
Subject: Re: IETF 53 CCAMP=20 Minutes

Hi,=20

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

Cheers,
    Eve=20 =

--------------------------------------------------------------------=20
Call for Design Team for GMPLS Profile for ASON/ASTN=20

ITU-T Liaison
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.  He also reviewed the = Detector=20 Controller Interface, clarifying this is over and above the actual=20 payload.  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

Eric Mannie indicated that these gaps are very small, and were on = their way=20 to being solved.  He asked if these were all the gaps?  = 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

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.  Many are more clarification and = applicability. =20 However, there may be some areas where some additional work might be=20 involved.  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

Yong Xue said the ITU-T is now working on version 2 of the document = (G.7713), and should be considered.=20

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

Ron Bonica wrote:=20

Folks,=20

Minutes from our last meeting follow. Please review and comment.=20 =

           &nbs= p;            = ;            =      =20 Ron=20

CCAMP Minutes=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Kireeti Kompella - Status Update=20

Draft Status Update=20

generalized signalling - finished last call,have implementation = status,=20
ready for ietf last call=20

call for consensus to send to ietf last call:=20
       =20 draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt  = informational=20 =
           &nb= sp;           &nbs= p;       =20 -architecture-02.txt  informational=20 =
           &nb= sp;           &nbs= p;       =20 -ccamp-sdhsonet-control-00.txt  informational=20

Kireeti: Any objects to making fontana-ccamp-gmpls-g709-03.txt a=20
working group document?=20

NO OBJECTIONS=20

Kireeti: There was a call for design team for "GMPLS profile for=20 ason/astn"=20

Tolbridge: g709 framework was going to go back to the ITU to = produce=20
".g.709 for dummies".  Have not met yet.=20

Kireeti: happy to remove from plate of CCAMP if ITU will handle.=20

Osama: we have a draft at ITU-T that is a wg document=20

Kireeti: need a more concise statement from ITU=05=20

Kireeti: If you have any comments on the documents=20
(additions/subtractions/etc.), please post to the list.=20

Kireeti: there will be a charter update at some point=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Steve Tolbridge=20

Wasam Alanqar is liaison to ITU-T SG 15.=20

(2) communications to IETF CCAMP
  - signaling protocol = work in=20 Q14.15
  - detector-controller interface (DCI) from Q.11/15 =

See proceedings for URLs that show location of docs.=20

Documents sent to IETF from Q14.15
  - PNNI-based = signaling=20
  - GMPLS RSVP-TE based signaling
  - GMPLS CR-LDP = based=20 signaling=20

Outlined a variety of "gaps" in the current work:
  - = Call and=20 connection separation
  - Additional error codes/value =
  -=20 Restart mechanisms
  - Support for crankback
  - = Support=20 for soft permanent connection=20

See proceedings for details.=20

Eric Mannie: Referring to slide "Identified Gaps".  Gaps = seem to be=20
very small.  Most of the points are solved, can be easily = solved,=20 or
are in the process of being solved.=20

Tolbridge: This was a preliminary scan.  Further review, = might turn=20 up
more issues.  Technologies are similar, so lets identify = and=20 minimize
gaps.=20

Dimitri: ITU requirements precede much of IETF work.  = Preliminary=20
discussions indicate that the current gaps are covered by = existing=20
protocol work.  Areas where additional work will be = required are=20
probably minimal, but need to be looked at.  IETF may gain = final=20
improvements by looking at ITU work.=20

Yong Xue: ITU is working on v2 ASON document so more things could = turn=20
up as "gaps".  Further communication between ITU and IETF = should=20
continue.=20

Tolbridge: Technology will evolve within both = organizations.  Should=20
expend effort to make sure that they evolve together.=20

Eva: ??? what was the point ???=20

[ can we supplement with other copy of the minutes ]=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Lou Berger=20

www.labn.net/gmpls-survey/...=20

17 organisations responded, mostly equipment vendors
1 = provider=20
about 50% are independent implementation=20

charts no. of implementations as a function of feature
17 gen = label=20 and bw encoding
12 sonet/sdh label and traffic parameters
17 = bidir=20 lsps
...=20

no questions=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Eric Mannie - gmpls recovery terminology=20

Eric provided overview of terminology draft.  Draft covers:=20
  - LSP protection and restoration
  - LSPs = controlled by=20 a GMPLS control place
  - End-to-end segment and span = recovery=20

Kireeti: Please send comments to list about whether or not this = should=20
be a wg document. Sense of room:=20

About 20 have read document - all agree that this is a wg = document.=20

Yong: All carriers have a different definition of=20
protection/restoration.  We need more carriers involved in = the=20
process.  IP and transport folks rarely have the same = perspective.=20

Kireeti: SP input came from TE WG and the SP representative on = the=20
design team (KPNQwest).  Point is well-taken.  = Carriers please=20 make
comments.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Chen Lee - "Exclude Routes"=20

Draft defines a new RSVP-TE object that allows specification of=20
intermediate "objects" to avoid - avoid highly utilized = nodes/ASs.=20

Wanted wg consensus on definition of this object.  Current = draft=20 does
!(A,B,C,D), but do we need to support (A, !B, !C, D).=20

Yakov: Regarding slide "application inter-area".  As far as = I=20
understand, you want to exclude certain routers/links.  = What is=20
purpose of excluding links?  If you just specify a link, = what does=20
that do?=20

Lee: You may want =05=20

Yakov: If you just want link diversity, then you want SLRGs, not = links.=20

Yakov: Regarding "application - avoid highly utilized = node/as".  Why=20
do this? Why not explicit route A, B, E, F?=20

Lee: What if you just know what you don't want, but know explicit = route.=20

Kireeti: One of the issues.  When you do explicit routing = with loose=20
hops, this is very similar.  However, don't want to do TE=20
node-by-node.  Want head-end or offline computations, not=20 hop-by-hop
TE. The point is not to overload RSVP-TE with all of = this=20 information
- don't want to do this computation during the = signaling=20 process
anyway.=20

Ron: Take discussion to lists.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% draft-shiomoto-ccamp-multiarea-te-00.txt=20

hierarchical lsps for multiarea te=20
        lowr layer for = abr-abr=20
        upper layer going = ingress to=20 egress=20

use of O-LSP for E-LSP routing.
next step: should be included = in=20 multiarea te framework=20

no questions
no support from floor, take to list=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% draft-imajuku-ml-routing-01.txt=20

LSR and PXC in same node. Number of links between the two should = be=20
advertised as available resource in the switching capability no=20 questions
from floor=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Jerry Ash - draft-ash-multi-area-te-compare-00.txt=20

comparison draft looks at existing proposals, try to converge on = a=20 reduced
set=20

4 main types:
distributed eg kompella scenario 1
path = computation=20 server, PCS, eg kompella scenario 2/4, 5
interarea summary = methods=20
multiple path comparison=20

criteria: optimality, scalabilty, resoration, path selection = performance,=20
path selection fuctionality=20

next steps: discuss options on list for consensus on selected = method=20
if confirmed proceed with pcs, query and crankback exytensions=20

Yakov: You state that PCS achieves optimal section.  How = much=20 topology
information does the PCS need?=20

Ash: Has full-topology of backbone area.=20

Yakov: Therefore only optimal w.r.t. the backbone area.=20

Ash: Well it varies.=20

Yakov: Statement that PCS scales is "interesting".  : = Normally=20
distributed approaches scale better.=20

Ash: Flooding is an issue with distributed schemes.=20

Yakov: There is also computational load.  Box may be a = bottleneck.=20

Ash: That does not make it less scalable. [laughter here ]=20

McDysan: What happens when a router is controlling optical paths = and=20
router goes berserk.  Might want to do "stability during=20
mismanagement" characterization.  Very valuable from SP = point of=20 view.=20

???: Single ISP or multiple ISPs?=20

Ash: Single ISP.=20

???: Why is protection hard in different areas?=20

Ash: Can be done.  Much discussion between authors on this.=20

Kireeti: As a router vendor, I take exception to the comment that =
routers are more likely to screw up than OXCs.=20

Yakov: If you do protection/restoration on a per-area basis, = then=05=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Eric Mannie -- draft-ietf-ccamp-gmpls-architecture-02.txt=20

Summarized modifications to document - see presentation.=20

Note: Remember that this wg id detailed the architecture of the = GMPLS=20
building blocks, but not the detailed semantic of the technology =
dependent structures, fields, objects, etc.=20

Ready for WG last call? About 20.=20

Bilel: Would be useful to send this to ITU and recommend use of = GMPLS.=20

Kireeti: Are you suggesting that we take the document to ITU?=20

Bilel: Yes.  With perhaps an exercise to see if it meets=20 requirements.=20

Kireeti: Who thinks that the document is not ready?  NONE=20

Kireeti: Please be diligent is making any comments.  Want to = send to=20
ADS and request publications as an informational RFC.=20

next: meeting to sort out label issue, send updated drafts for = last=20 review,
go to iesg last call.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
% = Eric=20 Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt=20

Presented history and latest changes made.=20

Next steps - small revisions to drafts (specifically label = coding) and=20
then go to IETF last call.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Eric Mannie -- draft-ietf-ccamp-gmpls-sonet-sdh-control-00.txt =

Presented history and latest changes made.=20

Target is informational RFC.  Let's have last review and = last call=20
before next IETF.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Dimitri -- draft-ietf-ccamp-gmpls-g709-00.txt=20

Reviewed document status.  Would like WG to adopt working = item?=20

SENSE OF ROOM: SUPPORT 10-15.  NO OBJECTIONS.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Dimitri -- draft-mannie-ccamp-gmpls-lbm-tdm-01.txt=20

Reviewed scenarios in document.  Is working group will to = accept=20 this
as a WG document?=20

NO RESPONSE FROM THE ROOM (maybe 3 for, none against).=20

Ron: Take this item to the mailing list.=20

Kireeti: How many SPs in the room.  20-25.=20

Kireeti: How many folks are interested in transport.  MOST = EVERYONE=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Osama Aboul-Magd -- = draft-aboulmagd-ccamp-call-conn-separation-00.txt.=20

Draft addresses one of the issues that Tolbridge highlighted in = his=20
talk - call and connection control separation.=20

Proposal to accept document as a WG item.=20

Kireeti: There is an explicit statement from ITU requiring this.=20
There is nothing in the charter about this.  This is good=20 stuff.  Ron
and I will go through a charter revision with = Ads and=20 discuss putting
this in the charter.  Also need to address = other=20 gaps that were raised
by ITU.=20

Scott: When you propose to add something to WG, it would be = helpful to=20
state where it fits in the existing charter OR how and why = charter=20
should be extended.=20

Eva: I think that it fits into the character as a requirement to = the=20
signaling protocols.=20

Scott: OK - that is a good clean explanation that might save = chairs=20
some time.=20

Yong: I second Eva's comment.=20

Kireeti: Need to figure out how to address other issues as well.=20
Also, MPLS OAM will be discussed in MPLS WG tomorrow.=20

Osama: What is outcome?=20

Kireeti: Let's think about this.  See about doing same for = RSVP and=20
then move forward.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% John Lang - LMP status (draft -03)=20

Current status:
  - Finished WG last call
  - = Fixed=20 several edits
  - Added text to security considerations=20

Open Issues:
  - Security =
      -=20 currently md5 is defined for LMP authentication=20
      - Another proposal exists in = draft-sankar=20 for Ipsec usage
  - Make local/remote id different in class = type=20 instead of object class=20

Bert: I raised the local/remote id issue, but there were also = other=20
issues where things could be combined.  Did you review = other parts=20 of
document as well?=20

John: We did.  Your comment reflects this class, but not = others.=20

NO OBJECTIONS TO PROPOSED CHANGES=20

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

John Sadler: Does not talk about control/address fields.  Do = not=20 talk
about 1662 frame format.=20

John: We can look at this.=20

Kireeti: OIF compatibility is not a requirement, but if we get = that=20
for free (or cheap) great.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Tom Nadeau - MIBs for GMPLS=20

Reviewed status of current documents, minor changes, etc.  = Want=20 GMPLS
MIBs to be compatible with MPLS MIBs when then become = RFCs.=20

Summary:
  - Make mpls-tev2 MIB CCAMP (or MPLS) wg = document=20
  - Make GMPLS-label MIB CCAMP wg document.
  - = GMPLS-TC=20 MIB as CCAMP wg document to capture new GMPLS-related TCs. =
  - Drop=20 GMPLS-LSR MIB (will use as it is including new TC change).=20

Kireeti: Why would GMPLS-label MIB hold up current MPLS MIB?=20

Tom: New indexing scheme relies on having the label MIB - for = MPLS=20
index is label.  For GMPLS there is more stuff in the = GMPLS-label=20 MIB.=20

Kireeti: Need to see new version and then move forward.  = Nice if we=20
could decouple them.  Will discuss with chairs and Ads = where this=20
should go.=20

Scott: Seems general, so belongs in CCAMP.=20

Tolbridge: "general" frequently means more than one thing.=20

Kireeti: We have "classical" MPLS and non-packet based MPLS.=20
Generalized covers both.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Yoshihiko Suemura (NEC) - extensions to RSVP-TE for signaling = and=20
restoration=20

Presented drafts.=20

Kireeti: Protection group should consider these docs.  More=20 discussion
on the list.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Ron Bonica=20

Issues:
  - Should we define protocols yet?
  - = IP=20 centric VS Tunnel Centric tools=20

We need a tool that tells us about the IP layer and the tunnels = that=20
support it.  IP network may be supported by multiple types = of=20 tunnels
- don't want separate tools for each type.=20

Proposal - adopt tunnel tracing requirements as a wg document.=20
Continue work on protocol specification.  Orthogonal to any = open=20
discussions about MPLS OAM.=20

Kireeti: Discussion to list.=20

???: Is the proposal to accept a new (03) draft that incorporates =
comments from the list.=20

Ron: not the intention.  Accepting the doc just means that = it is a=20
good enough starting point and we can spin revs later.=20 =

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= =20
% Dimitri - protection and restoration=20

Will submit draft as an individual ID.  Want comments from = the list.=20

Kireeti: Thanks.=20 =

=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
Ronald P.=20 Bonica       Ph: 703 886 1681
vBNS = Engineering       page: 1 888 268 8021 =
Ashburn, Va. =
=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
"Not=20 all who wander are lost."=20 =
           &nb= sp;   =20 -- J.R.R. Tolkien

--Boundary_(ID_F+QXrvtPWqlTFzj4dOBxpQ)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Apr 2002 14:21:06 -0700 Message-ID: <3CB20A3A.19A8731B@lucent.com> Date: Mon, 08 Apr 2002 17:23:07 -0400 From: Eve Varma MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org Subject: Re: IETF 53 CCAMP Minutes Content-Type: multipart/alternative; boundary="------------BB629C23F06C9C85070A54DE" --------------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 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 07 Apr 2002 18:29:14 -0700 Date: Sun, 07 Apr 2002 21:17:44 -0400 From: Ron Bonica Subject: IETF 53 CCAMP Minutes To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Apr 2002 02:34:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Mannie, Eric" To: 'Ron Bonica' , Sudheer Dharanikota Cc: "'ccamp@ops.ietf.org'" 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:Ronald.P.Bonica@wcom.com] 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Apr 2002 15:17:48 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: George Young Cc: ccamp@ops.ietf.org Subject: RE: sub-ip summary for internet drafts Date: Thu, 4 Apr 2002 01:17:31 +0200 MIME-Version: 1.0 Content-Type: text/plain And it is also highly recommend to post a summary to id-summary@subip.ietf.org Below is an old announcement about that Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 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- 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 idsummary@subip.ietf.org 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: subip-area@subip.ietf.org 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: 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Apr 2002 15:14:32 -0800 Date: Wed, 3 Apr 2002 15:14:04 -0800 (PST) From: Kireeti Kompella To: Subject: CCAMP WG Last Call on GMPLS Routing Documents Message-ID: <20020403150910.U37228-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Apr 2002 15:10:19 -0800 Date: Wed, 3 Apr 2002 15:08:21 -0800 (PST) From: Kireeti Kompella To: George Young cc: Subject: Re: sub-ip summary for internet drafts Message-ID: <20020403150710.G37228-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Apr 2002 11:23:06 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: sub-ip summary for internet drafts Date: Wed, 3 Apr 2002 14:17:21 -0500 Message-ID: <2B192BF55E1A4440A1176A12D86600C91F29BE@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: sub-ip summary for internet drafts Thread-Index: AcHbREu34sf6zYktTQmNLEmm74hnkw== From: "George Young" To: 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: george.young@meriton.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Apr 2002 23:23:17 -0800 Message-ID: From: Jonathan Lang To: "'muralidb@cisco.com'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Comments on LMP Date: Mon, 1 Apr 2002 23:15:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA16.360AD5E0" 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:muralidb@cisco.com] Sent: Friday, March 22, 2002 11:23 AM To: Jonathan Lang Cc: ccamp@ops.ietf.org Subject: Comments on LMP Hi Jonathan, Looks the following comments that I sent some time ago got lost. Thanks, /Baktha X-Sender: muralidb@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Mar 2002 23:02:27 -0500 To: Jonathan Lang From: Baktha Muralidharan Subject: Comments on LMP Cc: ccamp@ops.ietf.org, muralidb@cisco.com 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"
Baktha,
   Please see comments inline.
 
Thanks,
Jonathan
 
-----Original Message-----
From: Baktha Muralidharan [mailto:muralidb@cisco.com]
Sent: Friday, March 22, 2002 11:23 AM
To: Jonathan Lang
Cc: ccamp@ops.ietf.org
Subject: Comments on LMP

Hi Jonathan,

        Looks the following comments that I sent some time ago
        got lost.

Thanks,

/Baktha


X-Sender: muralidb@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Mar 2002 23:02:27 -0500
To: Jonathan Lang <jplang@calient.net>
From: Baktha Muralidharan <muralidb@cisco.com>
Subject: Comments on LMP
Cc: ccamp@ops.ietf.org, muralidb@cisco.com

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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Apr 2002 23:14:45 -0800 Cc: Sudheer Dharanikota , CCAMP WG Message-ID: <3CA959A6.2BD8AD24@lucent.com> Date: Tue, 02 Apr 2002 09:11:34 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Ron Bonica Original-CC: Sudheer Dharanikota , CCAMP WG Subject: Re: Please read and comment on GMPLS P&R DT documents Content-Type: multipart/mixed; boundary="------------376C6662C53EFE483D2A6C2B" 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:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/ggps-v01-0110.doc ftp://sg15opticalt:otxchange@ftp.itu.int/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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]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:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------376C6662C53EFE483D2A6C2B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Apr 2002 23:14:42 -0800 Message-ID: From: Jonathan Lang To: 'Soo-Hyun Choi' , ccamp@ops.ietf.org Cc: sob@harvard.edu Subject: RE: LMP over UDP Date: Mon, 1 Apr 2002 23:04:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:soohyunc@etri.re.kr] > Sent: Saturday, March 30, 2002 1:02 AM > To: Jonathan Lang; ccamp@ops.ietf.org > Cc: sob@harvard.edu; 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" > To: > Cc: ; "Jonathan Lang" > 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 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Apr 2002 00:56:58 -0800 Message-ID: <3CA82039.E16EAAD5@npd.hcltech.com> Date: Mon, 01 Apr 2002 14:24:17 +0530 From: brajaram@npd.hcltech.com Organization: HCL Technologies Ltd MIME-Version: 1.0 To: ccamp@ops.ietf.org, gmpls-ops@mplsrc.com Subject: Query in OIF-UNI-1.0 Implementation Aggrement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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