Subject: update GMPLS signaling documents
From: Lou Berger <[email-masked]>
To: [email-masked]
Date: Mon, 01 Oct 2001 02:47:44 -0400

FYI -

Updated versions of the signaling and RSVP-TE documents have been 
submitted. The CR-LDP version is forthcoming.  The updates address comments 
received during the August meeting and comment period.

Here's a summary of changes:

draft-ietf-mpls-generalized-signaling-06.txt
Changes from previous version:
o Removed redundant encoding type
o Revised Admin Status Usage (per comments and also removed potential race 
condition) o Clarified text related to interface bundling (To be consistent 
with updated bundling draft.)
o Minor editorial changes and clarifications
o Revised G-PID (per comments on list)

draft-ietf-mpls-generalized-rsvp-te-05.txt
Changes from previous version:
o Revised Admin Status Usage (per comments and also removed potential race 
condition)
o Clarified text related to interface bundling (To be consistent with 
updated bundling draft.)
o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel 
Separation by allowing identification of errored interface.)
o Added U bit to Label RRO subobject (Per comment, to match defined ERO.)
o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during 
recovery with new Recovery_Label (Per last WG session)
o Added IANA Considerations
o Minor editorial changes and clarifications

For those who don't want to wait, the drafts are available from:
http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt

Lou

Delivery-date: Sun, 30 Sep 2001 01:24:37 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Date: Sun, 30 Sep 2001 01:20:28 -0700

Hi All,
       If minimum reservable bandwidth of an STM-16 link in interface
switching capability TLV is VC-3, does this mean it can't switch VC
-2/VC-11 etc ? In other words, if a request comes for establishing an LSP 
with signal type as VC-11, it can't establish this LSP ?
STM-16 has 16 branches, if each of these branches support different
min. reservable bandwidth then does this mean it will be having 16
interface switching capability TLVs ?
Is this a deviation from SDH/SONET where u can't assume that if minimum 
reservable bandwidth is say VC-2 and max. reservable bandwidth is say STM-1, 
it doesn't mean that all the signals viz. VC-4, VC-12, VC-3 etc. (i.e. that 
fall under STM-1 and VC-2) are supported ?

Please correct me if I am wrong.

Regards,
manoj.

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

Delivery-date: Fri, 28 Sep 2001 18:45:45 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bi-directional LSPs  [Contention Resolution]
Date: Fri, 28 Sep 2001 18:41:36 -0700

Hi All,
           I have a basic doubt regarding contention resolution. The draft 
explains the example with upstream label and suggested label. Suggested 
label is optional. If a node is not able to allocate the suggested label 
then it may override the suggestged label. The actual contention arises when 
it is the last label. Am I right ?

Another case, the contention will also occur when say request for two 
bi-directional LSPs are initiated in opposite directions and both the 
requests include same upstream label. In addition to this, the label set 
contains one label,  same as upstream label (i.e. sender wants to have same 
label in both the directions).

Please clarify.

Regards,
manoj.

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

Delivery-date: Thu, 27 Sep 2001 09:06:33 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: [email-masked]
Subject: Questions on draft-ietf-mpls-bundle-mib-00
Date: Thu, 27 Sep 2001 12:04:27 -0400

I have a few questions on the bundling mib.

1. Is the data-bearing channel table defined in
draft-ietf-mpls-bundle-mib-00
   supposed to represent a Component as defined in
draft-ietf-mpls-bundle-00?

2. If the answer to 1 above is "yes", how can you specify a Component's IP
address
   or Component ID? 

3. Perhaps specifying a Component as defined in draft-ietf-mpls-bundle-00
    requires both a data-bearing channel and a teLink? If this is the case,
what is
    the significance of multiple data-bearing channels under a single
teLink?

Thanks,
steve atkinson

Delivery-date: Tue, 25 Sep 2001 09:29:15 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>
Cc: [email-masked]
Subject: RE: Question: purpose of LMP ChannelActive message (was relations hip of RSVP-TE and LMP)
Date: Tue, 25 Sep 2001 09:07:48 -0700

George,
 Sorry for the delayed response.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Thursday, September 20, 2001 5:52 AM
> To: Jonathan Lang
> Cc: [email-masked]
> Subject: RE: Question: purpose of LMP ChannelActive message (was
> relationship of RSVP-TE and LMP)
> 
> 
> Hello Jonathan,
> 
> Thanks again for the clarification. There's something that still
> troubles me.
> 
> I can see that if there's signalling involved (e.g. RSVP), then the
> signalling  indicates whether monitoring is necessary along the path
> (e.g. with  a couple of bits in the Admin Status object) and the LMP
> ChannelActive message is superfluous.
> 
> If there's no signalling involved, then the LMP ChannelActive message
> could be used to indicate monitoring should take place (e.g. for span
> protection). The trouble is that when monitoring finds that a channel
> has failed and sends a ChannelFail message, the transmit end knows to
> switch over, but without the ChannelFailNack message, the receive end of
> the link doesn't know to switch over.
> 
> Am I missing something here?
One thing we're doing for the next rev of LMP is combining the ChannelFail,
ChannelActive, ChannelDeactive messages into a single ChannelStatus message
(as discussed in LMP-WDM).  With this in place, you could send a
ChannelStatus (fail) message to indicate the failure.

> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: Jonathan Lang [mailto:[email-masked]]
> >Sent: Wednesday, September 19, 2001 1:38 PM
> >To: George Young; [email-masked]
> >Subject: RE: Question: purpose of LMP ChannelActive message (was
> >relationship of RSVP-TE and LMP)
> >
> >
> >George,
> >  see inline.
> >
> >Thanks,
> >Jonathan
> >
> >> -----Original Message-----
> >> From: George Young [mailto:[email-masked]]
> >> Sent: Wednesday, September 19, 2001 8:42 AM
> >> To: Jonathan Lang; [email-masked]
> >> Subject: RE: Question: purpose of LMP ChannelActive message (was
> >> relationship of RSVP-TE and LMP)
> >> 
> >> 
> >> Thanks for the clarification, Jonathan.
> >> 
> >> To see if I understand, the active call and the backup call are
> >> separately established by something like RSVP-TE. These 
> two calls are
> >> established by PATH going from head to tail, RESV going 
> from tail to
> >> head. Then for the active call ONLY, the head sends a ChannelActive
> >> which propagates to the tail, and then the tail sends a 
> ChannelActive
> >> which propagates to the head.
> >> 
> >> When failure is noted by monitoring the active call, the 
> head and the
> >> tail of the call are notified, and each switches over to the backup
> >> call. The head sends a ChannelActive message downstream 
> and the tail
> >> sends a ChannelActive message upstream, and they're each 
> >propagated to
> >> the other end.
> >> 
> >> Right?
> >not quite right.  I think you're confusing the ChannelActive 
> >message with
> >the Administrative Status object in GMPLS.  The ChannelActive 
> >message is
> >used between a pair of nodes to indicate that the data channel 
> >is now active
> >and should be monitored.  This is useful for span level protection or
> >between devices where GMPLS signaling (RSVP) isn't used.
> >
> >> 
> >> Regards,
> >> George.
> >> edgeflow Inc.
> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> phone: +1 613-270-9279 Ext 287
> >> fax: +1 613-270-9268
> >> 
> >> 
> >> >-----Original Message-----
> >> >From: Jonathan Lang [mailto:[email-masked]]
> >> >Sent: Tuesday, September 18, 2001 12:24 PM
> >> >To: George Young; [email-masked]
> >> >Subject: RE: Question: purpose of LMP ChannelActive message (was
> >> >relationship of RSVP-TE and LMP)
> >> >
> >> >
> >> >George,
> >> >  Sorry, I missed this one.  See inline.
> >> >
> >> >-Jonathan
> >> >
> >> >> -----Original Message-----
> >> >> From: George Young [mailto:[email-masked]]
> >> >> Sent: Tuesday, September 18, 2001 6:05 AM
> >> >> To: [email-masked]
> >> >> Subject: Question: purpose of LMP ChannelActive message (was
> >> >> relationship of RSVP-TE and LMP)
> >> >> 
> >> >> 
> >> >> Didn't see any answers to this question, so I'll try to 
> >> rephrase and
> >> >> make it more focused.
> >> >> 
> >> >> What is the purpose of the LMP ChannelActive message?
> >> >The ChannelActive message is used to indicate that the channel 
> >> >status is
> >> >active and should be monitored.
> >> >
> >> >> 
> >> >> I'm assuming a call is set up through an optical cross 
> >> connect (OXC),
> >> >> either in response to control plane signalling (e.g. 
> RSVP-TE) or 
> >> >> management plane input.
> >> >> The OXC has knowledge of which optical links are involved 
> >> >> with the call for failure monitoring purposes.
> >> >> 
> >> >> What additional information would the receipt of a 
> >> >> ChannelActive message convey?
> >> >This is useful when paths are pre-established (e.g., for path 
> >> >protection).
> >> >Although signaling is used to setup the resource reservation, 
> >> >on switchover
> >> >you need a mechanism to trigger monitoring of the data channel.
> >> >
> >> >> 
> >> >> Regards,
> >> >> George.
> >> >> edgeflow Inc.
> >> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> >> phone: +1 613-270-9279 Ext 287
> >> >> fax: +1 613-270-9268
> >> >> 
> >> >> 
> >> >> >-----Original Message-----
> >> >> >From: George Young 
> >> >> >Sent: Friday, September 07, 2001 3:47 PM
> >> >> >To: [email-masked]
> >> >> >Subject: relationship of RSVP-TE and LMP
> >> >> >
> >> >> >
> >> >> >I have two questions about the relationship of RSVP-TE
> >> >> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
> >> >> >(draft-ietf-ccamp-lmp-00.txt).
> >> >> >
> >> >> >First of all, my understanding of the LMP ChannelActive 
> >> >> message is that
> >> >> >it is used to indicate to the downstream (relative to data flow
> >> >> >direction) node that monitoring should be used.
> >> >> >
> >> >> >The scenario I have in mind is an RSVP call setup 
> consisting of a
> >> >> >bidirectional optical path.  Presumably a switching node has 
> >> >> to reserve
> >> >> >data channels and associate them with the optical path when an 
> >> >> >RSVP PATH
> >> >> >message arrives.
> >> >> >
> >> >> >1) My first question is what is the timing of LMP 
> >> >> >ChannelActive messages
> >> >> >relative to RSVP messages.
> >> >> >
> >> >> >Do ChannelActive messages flow downstream (relative to call
> >> >> >establishment direction) more-or-less in phase with PATH 
> >> >> messages, and
> >> >> >upstream (relative to call establishment direction) 
> >> more-or-less in
> >> >> >phase with RESV messages?
> >> >> >
> >> >> >2) My second question is what addtional information 
> >information do
> >> >> >ChannelActive messages provide?
> >> >> >
> >> >> >If a link is to be monitored when associated with an 
> >> active call, it
> >> >> >appears the node already has this information.
> >> >> >
> >> >> >Regards,
> >> >> >George.
> >> >> >edgeflow Inc.
> >> >> >329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> >> >phone: +1 613-270-9279 Ext 287
> >> >> >fax: +1 613-270-9268
> >> >> >
> >> >> >
> >> >> >
> >> >> 
> >> >
> >> 
> >
> 

Delivery-date: Tue, 25 Sep 2001 09:21:08 -0700
From: Jonathan Lang <[email-masked]>
To: "'Bhargava, Nidhi'" <[email-masked]>, 'Fugui Wang' <[email-masked]>, John Drake <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
Date: Tue, 25 Sep 2001 09:06:02 -0700

Nidhi,
  Sorry for the delay in responding.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Bhargava, Nidhi [mailto:[email-masked]]
> Sent: Thursday, September 20, 2001 6:45 AM
> To: Jonathan Lang; 'Fugui Wang'; John Drake; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: [email-masked]'
> Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> 
> 
> Jonathan,
> With reference to answer to question (2), do we wait for the other side 
> so set the control channel down bit in the hello messages before going to 
> DOWN state or do we immediately go to DOWN state without caring about the
> neighbour.
I will add the following to the next rev of the draft:
"The node may stop sending Hello messages after HelloDeadInterval seconds
have passed, or if it receives an LMP message over the same control channel
with the ControlChannelDown flag set." 
> 
> Also I have a question regarding the reconfig event. When the reconfig 
> event is generated, do we always send the config message regardless of 
> neighbours node id. Or we will only send config is our node if is greater
> than neighbours. Do we need to stop the hello protocol before doing the
> renegotiation?
Yes, you can send the config message (regardless of neighbor's node ID) if
you want to reconfig.  You can continue sending the Hello protocol.

> 
> Lastly when the control channel reboots, we are expected to come back to
> the UP state and resume Hello protocol. Shouldn't we be doing a config
> procedure again. Does the node reboot bit in the common header represents
the 
> node reboot or the control channel reboot?
You should do a config procedure again.  The node reboot bit has been
renamed to LMP Restart to indicate that the LMP module has restarted.

> 
> Thanks
> Nidhi
> -------------------------------
> Nidhi Bhargava
> NetPlane Systems Inc.
> A Mindspeed Technologies Company
> Tel:   + 1.781.329.3200 x5353
> Web:   http://www.netplane.com
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Wednesday, September 19, 2001 6:40 PM
> > To: 'Fugui Wang'; John Drake; [email-masked]';
> > [email-masked]'; [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]';
> > [email-masked]'
> > Cc: [email-masked]'
> > Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> > 
> > 
> > Fugui,
> >   See inline.
> > 
> > Thanks,
> > Jonathan
> > 
> > > -----Original Message-----
> > > From: Fugui Wang [mailto:[email-masked]]
> > > Sent: Wednesday, September 19, 2001 8:42 AM
> > > To: Jonathan Lang; Krishna Palla; John Drake; 
> [email-masked]';
> > > [email-masked]'; [email-masked]'; [email-masked]';
> > > [email-masked]'; [email-masked]';
> > > [email-masked]'; [email-masked]'
> > > Cc: [email-masked]'
> > > Subject: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> > > 
> > > 
> > > Hi,
> > > 
> > > During the implementation of the LMP protocol, I have got several
> > > questions regarding the LMP draft. Could you please clarify any of
> > > them?
> > > 
> > > Thanks,
> > > Fugui
> > > 
> > > 1. Control Channel FSM:
> > > 
> > > (1) There are two events which could bring up the control channel,
> > evBringUp_1a,
> > > evBringUp_1b.  Does that mean that in the MIB we need to 
> > have  something
> > like
> > > activeUp and pasvUp in the AdminStatus of control channel table?
> > I don't think this is necessary.
> > 
> > > 
> > > (2) In this version, the GoingDn state is removed. When a 
> > control channel
> > > gets evAdminDown event, it will go to Down state immediately. 
> > > Should it send a Hello or other messages with 
> > ControlChannelDown bit set
> > to the 
> > > neighbor before it goes down? Since the Hello message is sent
> > periodically. If we 
> > > don't send an additional Hello with ControlChannelDown 
> bit set, most
> > probably, the 
> > > control channel would never have a chance to send such a 
> > message. Then the
> > remote 
> > > node will get Hello time out instead of get the event evNbrGoesDn.
> > We will add text to the evAdminDown event indicating that 
> > Hello messages
> > sent before going down should have the ControlChannelDown bit set.
> > 
> > > 
> > > (3) When receiving a ConfigNack, if the Hello Config TLV is 
> > nonegotiable
> > or
> > > it is negotiable but we could not find the values acceptable for 
> > > both side, should we still keep sending Config message? 
> > According to the 
> > > Control Channel FSM, when getting the evConfErr, the 
> control channel
> > should keep in 
> > > ConfSnd state.
> > If the configuration parameters are negotiable, and the 
> > proposed values are
> > acceptable, a new Config message should be transmitted with 
> > these values.
> > If the Nack'd values are non-negotiable, or if the proposed 
> values are
> > unacceptable, you can go into the down state (event 2) or 
> > keep trying with
> > your values (hoping that configuration is changed at the far end).
> > 
> > > 
> > > 2. TE link FSM:
> > In the next version of LMP we are simplifying the TE link 
> > FSM.  The TE Link
> > can really only be in the UP, DOWN, and DEGRADED states.  
> > Link Verification
> > can occur in either the UP or DOWN states, and could be 
> > represented using
> > sub-states.
> > 
> > > 
> > > (1) After verification is done (evVerDone), the FSM goes 
> > from VrfProc to
> > > Summary state. However, if all of the Data Bearing links 
> > failed in the 
> > > verification, should the TE link still enter the Summary 
> > state and send a
> > > LinkSummary message with no TLV? Or should it go from 
> > VrfProc to Down
> > state
> > > directly without sending such a meaningless LinkSummary 
> > message? (This
> > could
> > > happen if the Data Bearing links and TE links have not been 
> > configured in
> > > the remote side yet and the local side has already 
> > configured and start to
> > > verify.)
> > > 
> > > (2) In the Summary state, the node keep sending LinkSummary 
> > message to
> > remote
> > > until it receives LinkSummaryAck or LinkSummaryNack. Should 
> > we have an
> > other
> > > events such as evSummaryTimeout so that we won't keep 
> > trying infinetely if
> > > we couldn't get any response from the remote?
> > > 
> > > (3) There is no event in the FSM indicating what will 
> > happen if the node 
> > > receives BeginVerify, LinkSummary. My understanding is that 
> > the receiver
> > > side is stateless. Is that correct?
> > > 
> > > (4) How to handle BeginVerifyNack? There is no event in the FSM
> > > corresponding to this.
> > > 
> > > 3. BeginVerify Message:
> > > 
> > > The BeginVerify message brings a field VerifyInterval. But my
> > understanding
> > > is that the receiver side should care more about the Verify Dead 
> > > Interval than the Verify Interval since it needs to use the 
> > Verify Dead 
> > > Interval to determine when to send TestStatusFailure back. 
> > (Note that the
> > > reciever side may not be able to get the Verify Dead 
> > Interval from the
> > local TE link 
> > > configuration If the sender side don't know the remote TE 
> > link ID and want
> > to learn
> > > it through verification.)
> > The VerifyDeadInterval is determined at the receive side and 
> > must take into
> > account the VerifyInterval at which the Test messages are sent.
> > 
> 

Delivery-date: Mon, 24 Sep 2001 08:54:36 -0700
Date: Mon, 24 Sep 2001 11:48:47 -0400
To: Irfan Lateef <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: OSPF-GMPLS-EXTN MIB
Cc: [email-masked], [email-masked]

At 12:55 PM 9/21/2001 -0400, Irfan Lateef wrote:
>Tom,
>
>I should have read this draft more closely, but thanks for pointing
>to the tables which links the pieces to together. I does the job well.
>
>However I have a few comments.
>
>1. As mentioned in section.3 of the draft "bundled link is another kind of
>TE link"
>     and the MIB does indeed address other kinds of links( like GMPLS links
>     not necessaryly using a bundling concept). The title of the draft
>deserves a
>     reconsideration which encompasses the a generalized notion. Let me cut
>the story
>     short, consider renaming it "TE GMPLS and Bundled Link Mgmt MIB" or
>something.

         The name was chosen to reflect the draft that it
models objects for. The working group accepted the document
named as it is.

>2. The MIB ideally models the bundling concept and the GMPLS attributes
>seems to
>     be an after thought, I understand the necessity to re-use the existing
>stuff. From a
>    GMPLS point of view, the attributes appear to be scattered around four
>different
>     tables. I am not sure how you may want to do it. But there is need to
>group them to together in someway.

         Please point out where you think there are deficiencies and
how you would like us to resolve them.

>My suggestion is, there can be a conformance
>group "GMPLS link group" similar to linkBundlingGroup which can help is
>identifying how the MIB can be used to model GMPLS links which are not
>ecessaryly bundled.

         I don't understand how a conformance group can
help in this regard. Conformance groups are used to
point out which objects must be supported and which
are optional (and under what circumstances).

>3. Some description about the relationship with OSPF MIB can help.

         Will do.

>4. Although the draft  does point to [GMPLS-OSPF] in sec.3 but a explicit
>sentence in
>    section.2 like "The same objects can also be used to model GMPLS links
>    and their attributes as defined [GMPLS-OSPF]", would great help.

         Okay.

         --Tom

>All these comments are editorial in nature but may help others in future who
>
>are trying to grapple with GMPLS .
>
>Regards,
>Irfan Lateef
>
>Thomas Nadeau wrote:
>
> >                  Take a look at the Link Bundling MIB,
> > specifically the teLinkOspfTeTable. The MIB can be
> > found here:
> >
> > http://search.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt
> >
> >          --Tom
> >
> > >This is with reference to the OSPF extension to GMPLS
> > >  draft-ietf-ccamp-ospf-gmpls-extensions-00.txt.
> > >
> > >  I know OSPF has corresponding MIB, OSPF-MIB (RFC 1850).
> > >  Is there a corresponding MIB for the ospf-gmpls-extn
> > >  which extends OSPF-MIB?
> > >  If the answer is no, How can the NMS find the additional
> > >  attributes of the GMPLS links.
> > >  Did I miss something!
> > >  Appreciate your response.
> > >
> > >  Irfan Lateef
> > >
> > >

Delivery-date: Mon, 24 Sep 2001 03:07:07 -0700
Date: Mon, 24 Sep 2001 15:30:41 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Ltd.
To: [email-masked]
Subject: Explicit Label Control -RSVP-TE ?

Hi,

In ERO the U- bit definition is not clear in 
draft-ietf-mpls-generalized-rsvp-te-04.txt.
Can anybody explain the U-bit set and unset (0 & 1).

Specifically my understanding is that if U-bit is 0 then the label is 
considered as incoming label and the outgoing label must be allocated on 
the outgoing interface and copied into upstream label object and sent 
with the outgoing PATH message.

I cannot understand when U-bit is one. Kindly explain in depth.

TIA,
Ramesh

Delivery-date: Sun, 23 Sep 2001 07:33:49 -0700
To: "Naidu, Venkata" <[email-masked]>
cc: "'Yakov Rekhter'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: GMPS Unnumbered 
Date: Sun, 23 Sep 2001 07:28:31 -0700
From: Yakov Rekhter <[email-masked]>

Venkata,

> Yakov:
> 
> -> >  * MPLS-TE extensions define Interface IP Address TLVs 
> -> >    (Type 3 and 4) as length of 4N. Where N is the number of 
> -> >    local IP addresses for that Interface.
> -> > 
> -> >    But in GMPLS, why can't we configure multiple "unique" 
> -> >    Interface IDs for Unnumbered interfaces? Please allow
> -> >    flexibility with out restricting one ID for Unnumbered Link.
> -> 
> -> What kind of problem(s) would that solve ?
> 
>    
>    If for example, a physical p2p link is sub divided into 
>    multiple "logical" links (such as ATM VP/VC) each has 
>    identifiers but represents same other characteristics 
>    (like bw etc) then there is no point in generating multiple 
>    link TLVs for each of those "logical" interfaces. Considering 
>    OSPF is implemented as per draft-ietf-ospf-ppp-flood-01.txt. 
>    (hope you won't suggest link bundling here)

what would be the problem(s) with using link bundling in this case ?

>    Please see more comments on GMPLS Routing below: 
>  
>    * There is no mention about Interface MTU in 
>      draft-ietf-ccamp-gmpls-routing-00.txt, but I can see the
>      use in draft-ietf-ccamp-ospf-gmpls-extensions-00.txt
>      (as Sub TLV type 10). 
> 
>      More over, "logical TE link" (with no OSPF adjacency) need not 
>      signify "Interface MTU" but "path MTU" suites well(?)

I actually wonder whether it would make more sense to carry MTU
not as a Sub-TLV, but in the Switching Capability specific information 
(for PSC links only). (For one thing, I don't think MTU has any
meaning on non-PSC links).
  
>    * I suggest/request to include "delay" also in GMPLS enhancements.
>      None of the TE extensions (MPLS, DiffServ, GMPLS) considered
>      "link delay" as one of path computation constraint. (could be
>      NP-complete but there are means to compute path and very helpful
>      in Traffic Management/QoS cases for delay sensitive applications)

Did you have a chance to look at the proposal suggested in
draft-lefaucheur-te-metric-igp-00.txt ?

>    * Is that Sub-TLV types 3|4 and 11|12 are mutually exclusive?
>      If not what would be the behavior if OSPF receives all of 
>      above TLVs. (is there any possibility here that we can save 
>      some types/overhead with regards to scalability)

I guess in principle the same link could be both numbered and
unnumbered (why would one do this in practice is a completely
different question). So, at least in principle one could argue that 
3|4 and 11|12 may not be mutually exclusive.

>      
>    * Minor: there is no mention about which Sub-TLVs are optional
>      and which are mandatory. And any restriction about processing
>      the (un)recognized TLVs?

This draft just follows the approach of the "basic" MPLS TE routing
extensions.

Yakov.

Delivery-date: Fri, 21 Sep 2001 09:54:05 -0700
Date: Fri, 21 Sep 2001 12:55:19 -0400
From: Irfan Lateef <[email-masked]>
Organization: Village Networks Inc
To: Thomas Nadeau <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: OSPF-GMPLS-EXTN MIB

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

Tom,

I should have read this draft more closely, but thanks for pointing
to the tables which links the pieces to together. I does the job well.

However I have a few comments.

1. As mentioned in section.3 of the draft "bundled link is another kind of
TE link"
    and the MIB does indeed address other kinds of links( like GMPLS links
    not necessaryly using a bundling concept). The title of the draft
deserves a
    reconsideration which encompasses the a generalized notion. Let me cut
the story
    short, consider renaming it "TE GMPLS and Bundled Link Mgmt MIB" or
something.

2. The MIB ideally models the bundling concept and the GMPLS attributes
seems to
    be an after thought, I understand the necessity to re-use the existing
stuff. From a
   GMPLS point of view, the attributes appear to be scattered around four
different
    tables. I am not sure how you may want to do it. But there is need to
group them
    to together in someway. My suggestion is, there can be a conformance
group
    "GMPLS link group" similar to linkBundlingGroup which can help is
identifying
    how the MIB can be used to model GMPLS links which are not necessaryly
bundled.

3. Some description about the relationship with OSPF MIB can help.

4. Although the draft  does point to [GMPLS-OSPF] in sec.3 but a explicit
sentence in
   section.2 like "The same objects can also be used to model GMPLS links
   and their attributes as defined [GMPLS-OSPF]", would great help.

All these comments are editorial in nature but may help others in future who

are trying to grapple with GMPLS .

Regards,
Irfan Lateef

Thomas Nadeau wrote:

>                  Take a look at the Link Bundling MIB,
> specifically the teLinkOspfTeTable. The MIB can be
> found here:
>
> http://search.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt
>
>          --Tom
>
> >This is with reference to the OSPF extension to GMPLS
> >  draft-ietf-ccamp-ospf-gmpls-extensions-00.txt.
> >
> >  I know OSPF has corresponding MIB, OSPF-MIB (RFC 1850).
> >  Is there a corresponding MIB for the ospf-gmpls-extn
> >  which extends OSPF-MIB?
> >  If the answer is no, How can the NMS find the additional
> >  attributes of the GMPLS links.
> >  Did I miss something!
> >  Appreciate your response.
> >
> >  Irfan Lateef
> >
> >

--------------F826DB3D2DA0C2D123E0E536
Content-Type: text/x-vcard; charset=us-ascii;
 name="ilateef.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Irfan Lateef
Content-Disposition: attachment;
 filename="ilateef.vcf"

begin:vcard 
n:Lateef;Irfan
tel;fax:732-460-5998
tel;work:732-460-7760
x-mozilla-html:FALSE
url:www.villagenetworks.com
org:Village Networks Inc;Systems Engineering
adr:;;246, Industrial Way;Eatontown;New Jersey;07724;USA
version:2.1
email;internet:[email-masked]
title:Senior Systems Engineer, 
fn:Irfan
end:vcard

--------------F826DB3D2DA0C2D123E0E536--

Delivery-date: Fri, 21 Sep 2001 09:14:13 -0700
Date: Fri, 21 Sep 2001 09:11:18 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Irfan Lateef <[email-masked]>
CC: [email-masked]
Subject: Re: OSPF-GMPLS-EXTN MIB

Please refer to "draft-ietf-mpls-bundle-mib-00.txt".

- sudheer

Irfan Lateef wrote:

> Hi,
> This is with reference to the OSPF extension to GMPLS
>  draft-ietf-ccamp-ospf-gmpls-extensions-00.txt.
>
>  I know OSPF has corresponding MIB, OSPF-MIB (RFC 1850).
>  Is there a corresponding MIB for the ospf-gmpls-extn
>  which extends OSPF-MIB?
>  If the answer is no, How can the NMS find the additional
>  attributes of the GMPLS links.
>  Did I miss something!
>  Appreciate your response.
>
>  Irfan Lateef

Delivery-date: Fri, 21 Sep 2001 07:12:26 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: GMPS Unnumbered 
Date: Fri, 21 Sep 2001 09:46:55 -0400

Yakov:

-> >  * MPLS-TE extensions define Interface IP Address TLVs 
-> >    (Type 3 and 4) as length of 4N. Where N is the number of 
-> >    local IP addresses for that Interface.
-> > 
-> >    But in GMPLS, why can't we configure multiple "unique" 
-> >    Interface IDs for Unnumbered interfaces? Please allow
-> >    flexibility with out restricting one ID for Unnumbered Link.
-> 
-> What kind of problem(s) would that solve ?

   If for example, a physical p2p link is sub divided into 
   multiple "logical" links (such as ATM VP/VC) each has 
   identifiers but represents same other characteristics 
   (like bw etc) then there is no point in generating multiple 
   link TLVs for each of those "logical" interfaces. Considering 
   OSPF is implemented as per draft-ietf-ospf-ppp-flood-01.txt. 
   (hope you won't suggest link bundling here)

   Please see more comments on GMPLS Routing below: 
 
   * There is no mention about Interface MTU in 
     draft-ietf-ccamp-gmpls-routing-00.txt, but I can see the
     use in draft-ietf-ccamp-ospf-gmpls-extensions-00.txt
     (as Sub TLV type 10). 

     More over, "logical TE link" (with no OSPF adjacency) need not 
     signify "Interface MTU" but "path MTU" suites well(?)

   * I suggest/request to include "delay" also in GMPLS enhancements.
     None of the TE extensions (MPLS, DiffServ, GMPLS) considered
     "link delay" as one of path computation constraint. (could be
     NP-complete but there are means to compute path and very helpful
     in Traffic Management/QoS cases for delay sensitive applications)

   * Is that Sub-TLV types 3|4 and 11|12 are mutually exclusive?
     If not what would be the behavior if OSPF receives all of 
     above TLVs. (is there any possibility here that we can save 
     some types/overhead with regards to scalability)
     
   * Minor: there is no mention about which Sub-TLVs are optional
     and which are mandatory. And any restriction about processing
     the (un)recognized TLVs?

  I have few more comments with regards to Link Protection and SRLG.
  Thanks!

--Venkata Naidu

Delivery-date: Fri, 21 Sep 2001 07:07:33 -0700
Date: Fri, 21 Sep 2001 10:07:12 -0400
To: Irfan Lateef <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: OSPF-GMPLS-EXTN MIB
Cc: [email-masked]

                 Take a look at the Link Bundling MIB,
specifically the teLinkOspfTeTable. The MIB can be
found here:

http://search.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt

         --Tom

>This is with reference to the OSPF extension to GMPLS
>  draft-ietf-ccamp-ospf-gmpls-extensions-00.txt.
>
>  I know OSPF has corresponding MIB, OSPF-MIB (RFC 1850).
>  Is there a corresponding MIB for the ospf-gmpls-extn
>  which extends OSPF-MIB?
>  If the answer is no, How can the NMS find the additional
>  attributes of the GMPLS links.
>  Did I miss something!
>  Appreciate your response.
>
>  Irfan Lateef
>
>

Delivery-date: Fri, 21 Sep 2001 06:57:37 -0700
Date: Fri, 21 Sep 2001 09:56:45 -0400
From: Irfan Lateef <[email-masked]>
Organization: Village Networks Inc
To: [email-masked]
Subject: OSPF-GMPLS-EXTN MIB

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

Hi,
This is with reference to the OSPF extension to GMPLS
 draft-ietf-ccamp-ospf-gmpls-extensions-00.txt.

 I know OSPF has corresponding MIB, OSPF-MIB (RFC 1850).
 Is there a corresponding MIB for the ospf-gmpls-extn
 which extends OSPF-MIB?
 If the answer is no, How can the NMS find the additional
 attributes of the GMPLS links.
 Did I miss something!
 Appreciate your response.

 Irfan Lateef

--------------649B04FCE8EFC7D545737C64
Content-Type: text/x-vcard; charset=us-ascii;
 name="ilateef.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Irfan Lateef
Content-Disposition: attachment;
 filename="ilateef.vcf"

begin:vcard 
n:Lateef;Irfan
tel;fax:732-460-5998
tel;work:732-460-7760
x-mozilla-html:FALSE
url:www.villagenetworks.com
org:Village Networks Inc;Systems Engineering
adr:;;246, Industrial Way;Eatontown;New Jersey;07724;USA
version:2.1
email;internet:[email-masked]
title:Senior Systems Engineer, 
fn:Irfan
end:vcard

--------------649B04FCE8EFC7D545737C64--

Delivery-date: Thu, 20 Sep 2001 11:04:26 -0700
To: "Naidu, Venkata" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: GMPS Unnumbered 
Date: Thu, 20 Sep 2001 11:02:39 -0700
From: Yakov Rekhter <[email-masked]>

Venkata,

> All GMPLS-Unnumbered:
> 
>    I have few comments on draft-ietf-ccamp-gmpls-routing-00.txt
>    (applicable to draft-ietf-ccamp-ospf-gmpls-extensions-00.txt)
> 
>  * MPLS-TE extensions define Interface IP Address TLVs 
>    (Type 3 and 4) as length of 4N. Where N is the number of 
>    local IP addresses for that Interface.
> 
>    But in GMPLS, why can't we configure multiple "unique" 
>    Interface IDs for Unnumbered interfaces? Please allow
>    flexibility with out restricting one ID for Unnumbered Link.

What kind of problem(s) would that solve ?

>    There is no scarcity for local significant integers 
>    (unlike IP address) ;-)
> 
>  * It would be helpful, if you give more information about "why"
>    this outgoing unnumbered link ID is chosen as "unique" in the 
>    scope of LSR.
> 
>    This is because, IP (Classical) has Unnumbered links defined
>    in RFC 1812 Section 2.2.7 - which suggests to use "Router ID"
>    (MAY be one of the Routers IP addresses) as Unnumbered Link ID. 
>    So in IP context this is not a unique ID. 
> 
>    My question is, can we use the same IP configured unnumbered
>    link address for GMPLS purpose?

unnumbered link ID has to be unique in the scope of an LSR because
the LSR needs to identify a particular link (for the purpose of resource
and label allocation), and a pair of LSRs may have multiple links
between then.

Yakov.

Delivery-date: Thu, 20 Sep 2001 10:02:41 -0700
From: "Kullberg, Alan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: GMPLS RSVP Nodal Fault recovery
Date: Thu, 20 Sep 2001 12:57:31 -0400

I think I've found a problem with the nodal fault recovery mechanism
in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5.

If the node that fails is the ingress node (i.e., an LER), then the LSP
won't recover since there is no upstream neighbor from which this
restarting LER will receive a PATH message.  Therefore, the LER
won't send a PATH message to its downstream neighbor, and the
LSP recovery fails.

In other words, recovery only seems to work if an LSR or an Egress
LER experiences nodal failure.

Perhaps this could be fixed by having neighbors of the restarting
node send a RESV for any Resv state held?

Alan

Delivery-date: Thu, 20 Sep 2001 06:47:08 -0700
From: "Bhargava, Nidhi" <[email-masked]>
To: 'Jonathan Lang' <[email-masked]>, 'Fugui Wang' <[email-masked]>, John Drake <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
Date: Thu, 20 Sep 2001 09:44:47 -0400

Jonathan,
With reference to answer to question (2), do we wait for the other side 
so set the control channel down bit in the hello messages before going to 
DOWN state or do we immediately go to DOWN state without caring about the
neighbour.

Also I have a question regarding the reconfig event. When the reconfig 
event is generated, do we always send the config message regardless of 
neighbours node id. Or we will only send config is our node if is greater
than neighbours. Do we need to stop the hello protocol before doing the
renegotiation?

Lastly when the control channel reboots, we are expected to come back to
the UP state and resume Hello protocol. Shouldn't we be doing a config
procedure again.
Does the node reboot bit in the common header represents the node reboot or
the
control channel reboot?

Thanks
Nidhi
-------------------------------
Nidhi Bhargava
NetPlane Systems Inc.
A Mindspeed Technologies Company
Tel:   + 1.781.329.3200 x5353
Web:   http://www.netplane.com

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 6:40 PM
> To: 'Fugui Wang'; John Drake; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: [email-masked]'
> Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> 
> 
> Fugui,
>   See inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Fugui Wang [mailto:[email-masked]]
> > Sent: Wednesday, September 19, 2001 8:42 AM
> > To: Jonathan Lang; Krishna Palla; John Drake; [email-masked]';
> > [email-masked]'; [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]';
> > [email-masked]'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> > 
> > 
> > Hi,
> > 
> > During the implementation of the LMP protocol, I have got several
> > questions regarding the LMP draft. Could you please clarify any of
> > them?
> > 
> > Thanks,
> > Fugui
> > 
> > 1. Control Channel FSM:
> > 
> > (1) There are two events which could bring up the control channel,
> evBringUp_1a,
> > evBringUp_1b.  Does that mean that in the MIB we need to 
> have  something
> like
> > activeUp and pasvUp in the AdminStatus of control channel table?
> I don't think this is necessary.
> 
> > 
> > (2) In this version, the GoingDn state is removed. When a 
> control channel
> > gets evAdminDown event, it will go to Down state immediately. 
> > Should it send a Hello or other messages with 
> ControlChannelDown bit set
> to the 
> > neighbor before it goes down? Since the Hello message is sent
> periodically. If we 
> > don't send an additional Hello with ControlChannelDown bit set, most
> probably, the 
> > control channel would never have a chance to send such a 
> message. Then the
> remote 
> > node will get Hello time out instead of get the event evNbrGoesDn.
> We will add text to the evAdminDown event indicating that 
> Hello messages
> sent before going down should have the ControlChannelDown bit set.
> 
> > 
> > (3) When receiving a ConfigNack, if the Hello Config TLV is 
> nonegotiable
> or
> > it is negotiable but we could not find the values acceptable for 
> > both side, should we still keep sending Config message? 
> According to the 
> > Control Channel FSM, when getting the evConfErr, the control channel
> should keep in 
> > ConfSnd state.
> If the configuration parameters are negotiable, and the 
> proposed values are
> acceptable, a new Config message should be transmitted with 
> these values.
> If the Nack'd values are non-negotiable, or if the proposed values are
> unacceptable, you can go into the down state (event 2) or 
> keep trying with
> your values (hoping that configuration is changed at the far end).
> 
> > 
> > 2. TE link FSM:
> In the next version of LMP we are simplifying the TE link 
> FSM.  The TE Link
> can really only be in the UP, DOWN, and DEGRADED states.  
> Link Verification
> can occur in either the UP or DOWN states, and could be 
> represented using
> sub-states.
> 
> > 
> > (1) After verification is done (evVerDone), the FSM goes 
> from VrfProc to
> > Summary state. However, if all of the Data Bearing links 
> failed in the 
> > verification, should the TE link still enter the Summary 
> state and send a
> > LinkSummary message with no TLV? Or should it go from 
> VrfProc to Down
> state
> > directly without sending such a meaningless LinkSummary 
> message? (This
> could
> > happen if the Data Bearing links and TE links have not been 
> configured in
> > the remote side yet and the local side has already 
> configured and start to
> > verify.)
> > 
> > (2) In the Summary state, the node keep sending LinkSummary 
> message to
> remote
> > until it receives LinkSummaryAck or LinkSummaryNack. Should 
> we have an
> other
> > events such as evSummaryTimeout so that we won't keep 
> trying infinetely if
> > we couldn't get any response from the remote?
> > 
> > (3) There is no event in the FSM indicating what will 
> happen if the node 
> > receives BeginVerify, LinkSummary. My understanding is that 
> the receiver
> > side is stateless. Is that correct?
> > 
> > (4) How to handle BeginVerifyNack? There is no event in the FSM
> > corresponding to this.
> > 
> > 3. BeginVerify Message:
> > 
> > The BeginVerify message brings a field VerifyInterval. But my
> understanding
> > is that the receiver side should care more about the Verify Dead 
> > Interval than the Verify Interval since it needs to use the 
> Verify Dead 
> > Interval to determine when to send TestStatusFailure back. 
> (Note that the
> > reciever side may not be able to get the Verify Dead 
> Interval from the
> local TE link 
> > configuration If the sender side don't know the remote TE 
> link ID and want
> to learn
> > it through verification.)
> The VerifyDeadInterval is determined at the receive side and 
> must take into
> account the VerifyInterval at which the Test messages are sent.
> 

Delivery-date: Thu, 20 Sep 2001 05:58:36 -0700
content-class: urn:content-classes:message
Subject: RE: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP)
Date:  Thu, 20 Sep 2001 08:51:53 -0400
From: "George Young" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

Hello Jonathan,

Thanks again for the clarification. There's something that still
troubles me.

I can see that if there's signalling involved (e.g. RSVP), then the
signalling  indicates whether monitoring is necessary along the path
(e.g. with  a couple of bits in the Admin Status object) and the LMP
ChannelActive message is superfluous.

If there's no signalling involved, then the LMP ChannelActive message
could be used to indicate monitoring should take place (e.g. for span
protection). The trouble is that when monitoring finds that a channel
has failed and sends a ChannelFail message, the transmit end knows to
switch over, but without the ChannelFailNack message, the receive end of
the link doesn't know to switch over.

Am I missing something here?

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: Jonathan Lang [mailto:[email-masked]]
>Sent: Wednesday, September 19, 2001 1:38 PM
>To: George Young; [email-masked]
>Subject: RE: Question: purpose of LMP ChannelActive message (was
>relationship of RSVP-TE and LMP)
>
>
>George,
>  see inline.
>
>Thanks,
>Jonathan
>
>> -----Original Message-----
>> From: George Young [mailto:[email-masked]]
>> Sent: Wednesday, September 19, 2001 8:42 AM
>> To: Jonathan Lang; [email-masked]
>> Subject: RE: Question: purpose of LMP ChannelActive message (was
>> relationship of RSVP-TE and LMP)
>>=20
>>=20
>> Thanks for the clarification, Jonathan.
>>=20
>> To see if I understand, the active call and the backup call are
>> separately established by something like RSVP-TE. These two calls are
>> established by PATH going from head to tail, RESV going from tail to
>> head. Then for the active call ONLY, the head sends a ChannelActive
>> which propagates to the tail, and then the tail sends a ChannelActive
>> which propagates to the head.
>>=20
>> When failure is noted by monitoring the active call, the head and the
>> tail of the call are notified, and each switches over to the backup
>> call. The head sends a ChannelActive message downstream and the tail
>> sends a ChannelActive message upstream, and they're each=20
>propagated to
>> the other end.
>>=20
>> Right?
>not quite right.  I think you're confusing the ChannelActive=20
>message with
>the Administrative Status object in GMPLS.  The ChannelActive=20
>message is
>used between a pair of nodes to indicate that the data channel=20
>is now active
>and should be monitored.  This is useful for span level protection or
>between devices where GMPLS signaling (RSVP) isn't used.
>
>>=20
>> Regards,
>> George.
>> edgeflow Inc.
>> 329 March Rd., Kanata, ON, Canada, K2K 2E1
>> phone: +1 613-270-9279 Ext 287
>> fax: +1 613-270-9268
>>=20
>>=20
>> >-----Original Message-----
>> >From: Jonathan Lang [mailto:[email-masked]]
>> >Sent: Tuesday, September 18, 2001 12:24 PM
>> >To: George Young; [email-masked]
>> >Subject: RE: Question: purpose of LMP ChannelActive message (was
>> >relationship of RSVP-TE and LMP)
>> >
>> >
>> >George,
>> >  Sorry, I missed this one.  See inline.
>> >
>> >-Jonathan
>> >
>> >> -----Original Message-----
>> >> From: George Young [mailto:[email-masked]]
>> >> Sent: Tuesday, September 18, 2001 6:05 AM
>> >> To: [email-masked]
>> >> Subject: Question: purpose of LMP ChannelActive message (was
>> >> relationship of RSVP-TE and LMP)
>> >>=20
>> >>=20
>> >> Didn't see any answers to this question, so I'll try to=20
>> rephrase and
>> >> make it more focused.
>> >>=20
>> >> What is the purpose of the LMP ChannelActive message?
>> >The ChannelActive message is used to indicate that the channel=20
>> >status is
>> >active and should be monitored.
>> >
>> >>=20
>> >> I'm assuming a call is set up through an optical cross=20
>> connect (OXC),
>> >> either in response to control plane signalling (e.g. RSVP-TE) or=20
>> >> management plane input.
>> >> The OXC has knowledge of which optical links are involved=20
>> >> with the call for failure monitoring purposes.
>> >>=20
>> >> What additional information would the receipt of a=20
>> >> ChannelActive message convey?
>> >This is useful when paths are pre-established (e.g., for path=20
>> >protection).
>> >Although signaling is used to setup the resource reservation,=20
>> >on switchover
>> >you need a mechanism to trigger monitoring of the data channel.
>> >
>> >>=20
>> >> Regards,
>> >> George.
>> >> edgeflow Inc.
>> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
>> >> phone: +1 613-270-9279 Ext 287
>> >> fax: +1 613-270-9268
>> >>=20
>> >>=20
>> >> >-----Original Message-----
>> >> >From: George Young=20
>> >> >Sent: Friday, September 07, 2001 3:47 PM
>> >> >To: [email-masked]
>> >> >Subject: relationship of RSVP-TE and LMP
>> >> >
>> >> >
>> >> >I have two questions about the relationship of RSVP-TE
>> >> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
>> >> >(draft-ietf-ccamp-lmp-00.txt).
>> >> >
>> >> >First of all, my understanding of the LMP ChannelActive=20
>> >> message is that
>> >> >it is used to indicate to the downstream (relative to data flow
>> >> >direction) node that monitoring should be used.
>> >> >
>> >> >The scenario I have in mind is an RSVP call setup consisting of a
>> >> >bidirectional optical path.  Presumably a switching node has=20
>> >> to reserve
>> >> >data channels and associate them with the optical path when an=20
>> >> >RSVP PATH
>> >> >message arrives.
>> >> >
>> >> >1) My first question is what is the timing of LMP=20
>> >> >ChannelActive messages
>> >> >relative to RSVP messages.
>> >> >
>> >> >Do ChannelActive messages flow downstream (relative to call
>> >> >establishment direction) more-or-less in phase with PATH=20
>> >> messages, and
>> >> >upstream (relative to call establishment direction)=20
>> more-or-less in
>> >> >phase with RESV messages?
>> >> >
>> >> >2) My second question is what addtional information=20
>information do
>> >> >ChannelActive messages provide?
>> >> >
>> >> >If a link is to be monitored when associated with an=20
>> active call, it
>> >> >appears the node already has this information.
>> >> >
>> >> >Regards,
>> >> >George.
>> >> >edgeflow Inc.
>> >> >329 March Rd., Kanata, ON, Canada, K2K 2E1
>> >> >phone: +1 613-270-9279 Ext 287
>> >> >fax: +1 613-270-9268
>> >> >
>> >> >
>> >> >
>> >>=20
>> >
>>=20
>

Delivery-date: Wed, 19 Sep 2001 15:50:13 -0700
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang' <[email-masked]>, John Drake <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
Date: Wed, 19 Sep 2001 15:40:03 -0700

Fugui,
  See inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 8:42 AM
> To: Jonathan Lang; Krishna Palla; John Drake; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> 
> 
> Hi,
> 
> During the implementation of the LMP protocol, I have got several
> questions regarding the LMP draft. Could you please clarify any of
> them?
> 
> Thanks,
> Fugui
> 
> 1. Control Channel FSM:
> 
> (1) There are two events which could bring up the control channel,
evBringUp_1a,
> evBringUp_1b.  Does that mean that in the MIB we need to have  something
like
> activeUp and pasvUp in the AdminStatus of control channel table?
I don't think this is necessary.

> 
> (2) In this version, the GoingDn state is removed. When a control channel
> gets evAdminDown event, it will go to Down state immediately. 
> Should it send a Hello or other messages with ControlChannelDown bit set
to the 
> neighbor before it goes down? Since the Hello message is sent
periodically. If we 
> don't send an additional Hello with ControlChannelDown bit set, most
probably, the 
> control channel would never have a chance to send such a message. Then the
remote 
> node will get Hello time out instead of get the event evNbrGoesDn.
We will add text to the evAdminDown event indicating that Hello messages
sent before going down should have the ControlChannelDown bit set.

> 
> (3) When receiving a ConfigNack, if the Hello Config TLV is nonegotiable
or
> it is negotiable but we could not find the values acceptable for 
> both side, should we still keep sending Config message? According to the 
> Control Channel FSM, when getting the evConfErr, the control channel
should keep in 
> ConfSnd state.
If the configuration parameters are negotiable, and the proposed values are
acceptable, a new Config message should be transmitted with these values.
If the Nack'd values are non-negotiable, or if the proposed values are
unacceptable, you can go into the down state (event 2) or keep trying with
your values (hoping that configuration is changed at the far end).

> 
> 2. TE link FSM:
In the next version of LMP we are simplifying the TE link FSM.  The TE Link
can really only be in the UP, DOWN, and DEGRADED states.  Link Verification
can occur in either the UP or DOWN states, and could be represented using
sub-states.

> 
> (1) After verification is done (evVerDone), the FSM goes from VrfProc to
> Summary state. However, if all of the Data Bearing links failed in the 
> verification, should the TE link still enter the Summary state and send a
> LinkSummary message with no TLV? Or should it go from VrfProc to Down
state
> directly without sending such a meaningless LinkSummary message? (This
could
> happen if the Data Bearing links and TE links have not been configured in
> the remote side yet and the local side has already configured and start to
> verify.)
> 
> (2) In the Summary state, the node keep sending LinkSummary message to
remote
> until it receives LinkSummaryAck or LinkSummaryNack. Should we have an
other
> events such as evSummaryTimeout so that we won't keep trying infinetely if
> we couldn't get any response from the remote?
> 
> (3) There is no event in the FSM indicating what will happen if the node 
> receives BeginVerify, LinkSummary. My understanding is that the receiver
> side is stateless. Is that correct?
> 
> (4) How to handle BeginVerifyNack? There is no event in the FSM
> corresponding to this.
> 
> 3. BeginVerify Message:
> 
> The BeginVerify message brings a field VerifyInterval. But my
understanding
> is that the receiver side should care more about the Verify Dead 
> Interval than the Verify Interval since it needs to use the Verify Dead 
> Interval to determine when to send TestStatusFailure back. (Note that the
> reciever side may not be able to get the Verify Dead Interval from the
local TE link 
> configuration If the sender side don't know the remote TE link ID and want
to learn
> it through verification.)
The VerifyDeadInterval is determined at the receive side and must take into
account the VerifyInterval at which the Test messages are sent.

Delivery-date: Wed, 19 Sep 2001 11:25:12 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: GMPS Unnumbered
Date: Wed, 19 Sep 2001 14:21:11 -0400

All GMPLS-Unnumbered:

   I have few comments on draft-ietf-ccamp-gmpls-routing-00.txt
   (applicable to draft-ietf-ccamp-ospf-gmpls-extensions-00.txt)

 * MPLS-TE extensions define Interface IP Address TLVs 
   (Type 3 and 4) as length of 4N. Where N is the number of 
   local IP addresses for that Interface.

   But in GMPLS, why can't we configure multiple "unique" 
   Interface IDs for Unnumbered interfaces? Please allow
   flexibility with out restricting one ID for Unnumbered Link.
   There is no scarcity for local significant integers 
   (unlike IP address) ;-)

 * It would be helpful, if you give more information about "why"
   this outgoing unnumbered link ID is chosen as "unique" in the 
   scope of LSR.

   This is because, IP (Classical) has Unnumbered links defined
   in RFC 1812 Section 2.2.7 - which suggests to use "Router ID"
   (MAY be one of the Routers IP addresses) as Unnumbered Link ID. 
   So in IP context this is not a unique ID. 

   My question is, can we use the same IP configured unnumbered
   link address for GMPLS purpose?

 * Finally, (just for clarity) - In Routing perspective, 
   Unnumbered Links are considered as part of GMPLS drafts.
   But I didn't understand why there are separate drafts 
      draft-ietf-mpls-rsvp-unnum-02.txt and 
      draft-ietf-mpls-crldp-unnum-02.txt
   in signaling perspective (more over in MPLS-WG instead of CCAMP)

   I think they should goto respective gmpls-rsvp and gmpls-crldp!

Thanks!
--Venkata Naidu

Delivery-date: Wed, 19 Sep 2001 10:44:56 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, [email-masked]
Subject: RE: Question: purpose of LMP ChannelActive message (was relations hip of RSVP-TE and LMP)
Date: Wed, 19 Sep 2001 10:38:19 -0700

George,
  see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 8:42 AM
> To: Jonathan Lang; [email-masked]
> Subject: RE: Question: purpose of LMP ChannelActive message (was
> relationship of RSVP-TE and LMP)
> 
> 
> Thanks for the clarification, Jonathan.
> 
> To see if I understand, the active call and the backup call are
> separately established by something like RSVP-TE. These two calls are
> established by PATH going from head to tail, RESV going from tail to
> head. Then for the active call ONLY, the head sends a ChannelActive
> which propagates to the tail, and then the tail sends a ChannelActive
> which propagates to the head.
> 
> When failure is noted by monitoring the active call, the head and the
> tail of the call are notified, and each switches over to the backup
> call. The head sends a ChannelActive message downstream and the tail
> sends a ChannelActive message upstream, and they're each propagated to
> the other end.
> 
> Right?
not quite right.  I think you're confusing the ChannelActive message with
the Administrative Status object in GMPLS.  The ChannelActive message is
used between a pair of nodes to indicate that the data channel is now active
and should be monitored.  This is useful for span level protection or
between devices where GMPLS signaling (RSVP) isn't used.

> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: Jonathan Lang [mailto:[email-masked]]
> >Sent: Tuesday, September 18, 2001 12:24 PM
> >To: George Young; [email-masked]
> >Subject: RE: Question: purpose of LMP ChannelActive message (was
> >relationship of RSVP-TE and LMP)
> >
> >
> >George,
> >  Sorry, I missed this one.  See inline.
> >
> >-Jonathan
> >
> >> -----Original Message-----
> >> From: George Young [mailto:[email-masked]]
> >> Sent: Tuesday, September 18, 2001 6:05 AM
> >> To: [email-masked]
> >> Subject: Question: purpose of LMP ChannelActive message (was
> >> relationship of RSVP-TE and LMP)
> >> 
> >> 
> >> Didn't see any answers to this question, so I'll try to 
> rephrase and
> >> make it more focused.
> >> 
> >> What is the purpose of the LMP ChannelActive message?
> >The ChannelActive message is used to indicate that the channel 
> >status is
> >active and should be monitored.
> >
> >> 
> >> I'm assuming a call is set up through an optical cross 
> connect (OXC),
> >> either in response to control plane signalling (e.g. RSVP-TE) or 
> >> management plane input.
> >> The OXC has knowledge of which optical links are involved 
> >> with the call for failure monitoring purposes.
> >> 
> >> What additional information would the receipt of a 
> >> ChannelActive message convey?
> >This is useful when paths are pre-established (e.g., for path 
> >protection).
> >Although signaling is used to setup the resource reservation, 
> >on switchover
> >you need a mechanism to trigger monitoring of the data channel.
> >
> >> 
> >> Regards,
> >> George.
> >> edgeflow Inc.
> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> phone: +1 613-270-9279 Ext 287
> >> fax: +1 613-270-9268
> >> 
> >> 
> >> >-----Original Message-----
> >> >From: George Young 
> >> >Sent: Friday, September 07, 2001 3:47 PM
> >> >To: [email-masked]
> >> >Subject: relationship of RSVP-TE and LMP
> >> >
> >> >
> >> >I have two questions about the relationship of RSVP-TE
> >> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
> >> >(draft-ietf-ccamp-lmp-00.txt).
> >> >
> >> >First of all, my understanding of the LMP ChannelActive 
> >> message is that
> >> >it is used to indicate to the downstream (relative to data flow
> >> >direction) node that monitoring should be used.
> >> >
> >> >The scenario I have in mind is an RSVP call setup consisting of a
> >> >bidirectional optical path.  Presumably a switching node has 
> >> to reserve
> >> >data channels and associate them with the optical path when an 
> >> >RSVP PATH
> >> >message arrives.
> >> >
> >> >1) My first question is what is the timing of LMP 
> >> >ChannelActive messages
> >> >relative to RSVP messages.
> >> >
> >> >Do ChannelActive messages flow downstream (relative to call
> >> >establishment direction) more-or-less in phase with PATH 
> >> messages, and
> >> >upstream (relative to call establishment direction) 
> more-or-less in
> >> >phase with RESV messages?
> >> >
> >> >2) My second question is what addtional information information do
> >> >ChannelActive messages provide?
> >> >
> >> >If a link is to be monitored when associated with an 
> active call, it
> >> >appears the node already has this information.
> >> >
> >> >Regards,
> >> >George.
> >> >edgeflow Inc.
> >> >329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> >phone: +1 613-270-9279 Ext 287
> >> >fax: +1 613-270-9268
> >> >
> >> >
> >> >
> >> 
> >
> 

Delivery-date: Wed, 19 Sep 2001 08:52:19 -0700
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
Date: Wed, 19 Sep 2001 11:41:46 -0400

Hi,

During the implementation of the LMP protocol, I have got several
questions regarding the LMP draft. Could you please clarify any of
them?

Thanks,
Fugui

1. Control Channel FSM:

(1) There are two events which could bring up the control channel,
evBringUp_1a,
evBringUp_1b.  Does that mean that in the MIB we need to have something like
activeUp and pasvUp in the AdminStatus of control channel table?

(2) In this version, the GoingDn state is removed. When a control channel
gets
evAdminDown event, it will go to Down state immediately. Should it send a
Hello
or other messages with ControlChannelDown bit set to the neighbor before it
goes
down? Since the Hello message is sent periodically. If we don't send an
additional
Hello with ControlChannelDown bit set, most probably, the control channel
would
never have a chance to send such a message. Then the remote node will get
Hello
time out instead of get the event evNbrGoesDn.

(3) When receiving a ConfigNack, if the Hello Config TLV is nonegotiable or
it
is negotiable but we could not find the values acceptable for both side,
should
we still keep sending Config message? According to the Control Channel FSM,
when
getting the evConfErr, the control channel should keep in ConfSnd state.

2. TE link FSM:

(1) After verification is done (evVerDone), the FSM goes from VrfProc to
Summary state. However, if all of the Data Bearing links failed in the 
verification, should the TE link still enter the Summary state and send a
LinkSummary message with no TLV? Or should it go from VrfProc to Down state
directly without sending such a meaningless LinkSummary message? (This could
happen if the Data Bearing links and TE links have not been configured in
the remote side yet and the local side has already configured and start to
verify.)

(2) In the Summary state, the node keep sending LinkSummary message to
remote
until it receives LinkSummaryAck or LinkSummaryNack. Should we have an other
events such as evSummaryTimeout so that we won't keep trying infinetely if
we couldn't get any response from the remote?

(3) There is no event in the FSM indicating what will happen if the node 
receives BeginVerify, LinkSummary. My understanding is that the receiver
side is stateless. Is that correct?

(4) How to handle BeginVerifyNack? There is no event in the FSM
corresponding
to this.

3. BeginVerify Message:

The BeginVerify message brings a field VerifyInterval. But my understanding
is
that the receiver side should care more about the Verify Dead Interval than
the
Verify Interval since it needs to use the Verify Dead Interval to determine
when
to send TestStatusFailure back. (Note that the reciever side may not be able
to
get the Verify Dead Interval from the local TE link configuration If the
sender
side don't know the remote TE link ID and want to learn it through
verification.)

Delivery-date: Wed, 19 Sep 2001 08:52:12 -0700
content-class: urn:content-classes:message
Subject: RE: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP)
Date:  Wed, 19 Sep 2001 11:41:30 -0400
From: "George Young" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>, <[email-masked]>

Thanks for the clarification, Jonathan.

To see if I understand, the active call and the backup call are
separately established by something like RSVP-TE. These two calls are
established by PATH going from head to tail, RESV going from tail to
head. Then for the active call ONLY, the head sends a ChannelActive
which propagates to the tail, and then the tail sends a ChannelActive
which propagates to the head.

When failure is noted by monitoring the active call, the head and the
tail of the call are notified, and each switches over to the backup
call. The head sends a ChannelActive message downstream and the tail
sends a ChannelActive message upstream, and they're each propagated to
the other end.

Right?

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: Jonathan Lang [mailto:[email-masked]]
>Sent: Tuesday, September 18, 2001 12:24 PM
>To: George Young; [email-masked]
>Subject: RE: Question: purpose of LMP ChannelActive message (was
>relationship of RSVP-TE and LMP)
>
>
>George,
>  Sorry, I missed this one.  See inline.
>
>-Jonathan
>
>> -----Original Message-----
>> From: George Young [mailto:[email-masked]]
>> Sent: Tuesday, September 18, 2001 6:05 AM
>> To: [email-masked]
>> Subject: Question: purpose of LMP ChannelActive message (was
>> relationship of RSVP-TE and LMP)
>>=20
>>=20
>> Didn't see any answers to this question, so I'll try to rephrase and
>> make it more focused.
>>=20
>> What is the purpose of the LMP ChannelActive message?
>The ChannelActive message is used to indicate that the channel=20
>status is
>active and should be monitored.
>
>>=20
>> I'm assuming a call is set up through an optical cross connect (OXC),
>> either in response to control plane signalling (e.g. RSVP-TE) or=20
>> management plane input.
>> The OXC has knowledge of which optical links are involved=20
>> with the call for failure monitoring purposes.
>>=20
>> What additional information would the receipt of a=20
>> ChannelActive message convey?
>This is useful when paths are pre-established (e.g., for path=20
>protection).
>Although signaling is used to setup the resource reservation,=20
>on switchover
>you need a mechanism to trigger monitoring of the data channel.
>
>>=20
>> Regards,
>> George.
>> edgeflow Inc.
>> 329 March Rd., Kanata, ON, Canada, K2K 2E1
>> phone: +1 613-270-9279 Ext 287
>> fax: +1 613-270-9268
>>=20
>>=20
>> >-----Original Message-----
>> >From: George Young=20
>> >Sent: Friday, September 07, 2001 3:47 PM
>> >To: [email-masked]
>> >Subject: relationship of RSVP-TE and LMP
>> >
>> >
>> >I have two questions about the relationship of RSVP-TE
>> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
>> >(draft-ietf-ccamp-lmp-00.txt).
>> >
>> >First of all, my understanding of the LMP ChannelActive=20
>> message is that
>> >it is used to indicate to the downstream (relative to data flow
>> >direction) node that monitoring should be used.
>> >
>> >The scenario I have in mind is an RSVP call setup consisting of a
>> >bidirectional optical path.  Presumably a switching node has=20
>> to reserve
>> >data channels and associate them with the optical path when an=20
>> >RSVP PATH
>> >message arrives.
>> >
>> >1) My first question is what is the timing of LMP=20
>> >ChannelActive messages
>> >relative to RSVP messages.
>> >
>> >Do ChannelActive messages flow downstream (relative to call
>> >establishment direction) more-or-less in phase with PATH=20
>> messages, and
>> >upstream (relative to call establishment direction) more-or-less in
>> >phase with RESV messages?
>> >
>> >2) My second question is what addtional information information do
>> >ChannelActive messages provide?
>> >
>> >If a link is to be monitored when associated with an active call, it
>> >appears the node already has this information.
>> >
>> >Regards,
>> >George.
>> >edgeflow Inc.
>> >329 March Rd., Kanata, ON, Canada, K2K 2E1
>> >phone: +1 613-270-9279 Ext 287
>> >fax: +1 613-270-9268
>> >
>> >
>> >
>>=20
>

Delivery-date: Tue, 18 Sep 2001 09:32:51 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, [email-masked]
Subject: RE: Question: purpose of LMP ChannelActive message (was relations hip of RSVP-TE and LMP)
Date: Tue, 18 Sep 2001 09:23:51 -0700

George,
  Sorry, I missed this one.  See inline.

-Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 6:05 AM
> To: [email-masked]
> Subject: Question: purpose of LMP ChannelActive message (was
> relationship of RSVP-TE and LMP)
> 
> 
> Didn't see any answers to this question, so I'll try to rephrase and
> make it more focused.
> 
> What is the purpose of the LMP ChannelActive message?
The ChannelActive message is used to indicate that the channel status is
active and should be monitored.

> 
> I'm assuming a call is set up through an optical cross connect (OXC),
> either in response to control plane signalling (e.g. RSVP-TE) or 
> management plane input.
> The OXC has knowledge of which optical links are involved 
> with the call for failure monitoring purposes.
> 
> What additional information would the receipt of a 
> ChannelActive message convey?
This is useful when paths are pre-established (e.g., for path protection).
Although signaling is used to setup the resource reservation, on switchover
you need a mechanism to trigger monitoring of the data channel.

> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: George Young 
> >Sent: Friday, September 07, 2001 3:47 PM
> >To: [email-masked]
> >Subject: relationship of RSVP-TE and LMP
> >
> >
> >I have two questions about the relationship of RSVP-TE
> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
> >(draft-ietf-ccamp-lmp-00.txt).
> >
> >First of all, my understanding of the LMP ChannelActive 
> message is that
> >it is used to indicate to the downstream (relative to data flow
> >direction) node that monitoring should be used.
> >
> >The scenario I have in mind is an RSVP call setup consisting of a
> >bidirectional optical path.  Presumably a switching node has 
> to reserve
> >data channels and associate them with the optical path when an 
> >RSVP PATH
> >message arrives.
> >
> >1) My first question is what is the timing of LMP 
> >ChannelActive messages
> >relative to RSVP messages.
> >
> >Do ChannelActive messages flow downstream (relative to call
> >establishment direction) more-or-less in phase with PATH 
> messages, and
> >upstream (relative to call establishment direction) more-or-less in
> >phase with RESV messages?
> >
> >2) My second question is what addtional information information do
> >ChannelActive messages provide?
> >
> >If a link is to be monitored when associated with an active call, it
> >appears the node already has this information.
> >
> >Regards,
> >George.
> >edgeflow Inc.
> >329 March Rd., Kanata, ON, Canada, K2K 2E1
> >phone: +1 613-270-9279 Ext 287
> >fax: +1 613-270-9268
> >
> >
> >
> 

Delivery-date: Tue, 18 Sep 2001 06:09:26 -0700
content-class: urn:content-classes:message
Subject: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP)
Date:  Tue, 18 Sep 2001 09:05:25 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

Didn't see any answers to this question, so I'll try to rephrase and
make it
more focused.

What is the purpose of the LMP ChannelActive message?

I'm assuming a call is set up through an optical cross connect (OXC),
either in
response to control plane signalling (e.g. RSVP-TE) or management plane
input.
The OXC has knowledge of which optical links are involved with the call
for
failure monitoring purposes.

What additional information would the receipt of a ChannelActive message
convey?

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: George Young=20
>Sent: Friday, September 07, 2001 3:47 PM
>To: [email-masked]
>Subject: relationship of RSVP-TE and LMP
>
>
>I have two questions about the relationship of RSVP-TE
>(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
>(draft-ietf-ccamp-lmp-00.txt).
>
>First of all, my understanding of the LMP ChannelActive message is that
>it is used to indicate to the downstream (relative to data flow
>direction) node that monitoring should be used.
>
>The scenario I have in mind is an RSVP call setup consisting of a
>bidirectional optical path.  Presumably a switching node has to reserve
>data channels and associate them with the optical path when an=20
>RSVP PATH
>message arrives.
>
>1) My first question is what is the timing of LMP=20
>ChannelActive messages
>relative to RSVP messages.
>
>Do ChannelActive messages flow downstream (relative to call
>establishment direction) more-or-less in phase with PATH messages, and
>upstream (relative to call establishment direction) more-or-less in
>phase with RESV messages?
>
>2) My second question is what addtional information information do
>ChannelActive messages provide?
>
>If a link is to be monitored when associated with an active call, it
>appears the node already has this information.
>
>Regards,
>George.
>edgeflow Inc.
>329 March Rd., Kanata, ON, Canada, K2K 2E1
>phone: +1 613-270-9279 Ext 287
>fax: +1 613-270-9268
>
>
>

Delivery-date: Mon, 17 Sep 2001 16:17:19 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt
Date: Tue, 26 Jun 2001 07:02:32 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: New TE LSAs to extend OSPF for Traffic Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-00.txt
	Pages		: 36
	Date		: 25-Jun-01
	
OSPF is a well established link state routing protocol used for 
topology discovery and computing forwarding table based on
shortest-Path criteria. Traffic Engineering extensions (OSPF-TE)
will use criteria different from shortest-path so as to route
traffic around congestion paths and meet varying Service Level
agreements.

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt

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

Delivery-date: Mon, 17 Sep 2001 16:17:16 -0700
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-01.txt
Date: Fri, 06 Jul 2001 06:50:43 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Routing Extensions for MPLS Signaling
	Author(s)	: A. Iwata, N. Fujita, G. Ash, A. Farrel
	Filename	: draft-iwata-mpls-crankback-01.txt
	Pages		: 30
	Date		: 05-Jul-01
	
This draft proposes crankback routing extensions for CR-LDP signaling
and for RSVP-TE signaling. Recently, several routing protocol
extensions for advertising resource information in addition to
topology information have been proposed for use in distributed
constraint-based routing. In such a distributed routing environment,
however, the information used to compute a constraint-based path may
be out of date. This means that LSP setup requests may be blocked by
links or nodes without sufficient resources. This draft specifies
crankback routing extensions for CR-LDP and RSVP-TE so that the label
request can be retried on an alternate path that detours around the
blocked link or node upon a setup failure. Furthermore, the crankback
routing schemes can also be applied to LSP restoration by indicating
the location of the failure link or node. This would significantly
improve the successful recovery ratio for failed LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-crankback-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-d

Delivery-date: Thu, 13 Sep 2001 13:14:09 -0700
From: Abhimanyu Das <[email-masked]>
To: 'Edward Harrison' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 13 Sep 2001 13:11:55 -0700

Hi,
 I agree with Ed that it does make sense to keep both the
COMPONENT_IF_UPSTREAM and COMPONENT_IF_DOWNSTREAM objects..since in bundled
links, one should allow for the flexibility of using different interfaces
for upstream and downstream LSPs.
In fact, it seems bundling is the only case where you can allow for this
flexibility of choosing different interfaces for upstream and downstream
LSPs because you have a choice of selecting a transmitter on one link and a
receiver on another link within the same bundle. In  non-bundled
cases(numbered or unnumbered), the link receiver and transmitter is combined
within a single interface..so one seems  forced in practice to use the same
interface for both upstream and downstream directions.

Abhimanyu

> -----Original Message-----
> From: Edward Harrison [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 2:56 AM
> To: 'Yakov Rekhter'
> Cc: Nic Larkin; [email-masked]'
> Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
> 
> 
> Yakov,
> 
> Can you clarify whether you are proposing removing the 
> COMPONENT_IF_UPSTREAM
> TLV from the INTERFACE_ID hop object (or were you just saying 
> that Steve
> needn't use it if he doesn't want to)?
> 
> As far as I can see, there is no restriction in LMP, for example, that
> requires data links to be grouped into upstream and 
> downstream pairs.  The
> ability to signal separate upstream and downstream links, 
> therefore seems to
> be potentially useful.
> 
> Thanks,
> 
> Ed Harrison
> 
> -----------------
> Edward Harrison  mailto:[email-masked]
> Network Convergence Group
> Data Connection Ltd.
> http://www.dataconnection.com/
> Tel: +44 20 8366 1177  Fax: +44 20 8363 1468
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: 12 September 2001 20:56
> To: Atkinson, Stephen
> Cc: [email-masked]'
> Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
> 
> 
> Stephen,
> 
> > I didn't get any comments on this. Would anyone care to 
> > respond?
> 
> Sorry for the delay... comments below....
> 
> > Thanks,
> > steve atkinson
> > 
> > >  -----Original Message-----
> > > From: 	Atkinson, Stephen  
> > > Sent:	Monday, September 10, 2001 4:11 PM
> > > To:	[email-masked]
> > > Subject:	Questions on draft-ietf-mpls-bundle-00
> > > 
> > > I've been reading the draft-ietf-mpls-bundle-00 spec and have 
> > > a couple questions.
> > > 
> > > Basically I'm trying to focus on why signaling unnumbered 
> > > components using
> > > Explicit Indication by Interface ID is different from all 
> > > other cases. This being the
> > > only case which specifies an interface (component) for each 
> > > direction of a bi-directional LSP.
> 
> My suggestion would be to make signaling unnumbered components
> using Explicit Indication by Interface ID the same as all other
> cases. That is, when signaling unnumbered components using
> Explicit Indication the signaling would carry just *one*
> Interface ID, and this Interface ID would identify the component
> link that should be used in *both* directions.
> 
> Yakov.
> 

Delivery-date: Thu, 13 Sep 2001 09:40:19 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Edward Harrison' <[email-masked]>
Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 13 Sep 2001 12:39:05 -0400

Hi Ed,

I agree, comments below.

Regards,
steve atkinson

> -----Original Message-----
> From: Edward Harrison [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 11:06 AM
> To: 'Yakov Rekhter'
> Cc: Nic Larkin; [email-masked]'
> Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
> 
> 
> Yakov,
> 
> > > Can you clarify whether you are proposing removing the
> COMPONENT_IF_UPSTREAM
> > > TLV from the INTERFACE_ID hop object (or were you just 
> saying that Steve
> > > needn't use it if he doesn't want to)?
> > 
> > I am proposing to remove the COMPONENT_IF_UPSTREAM.
> 
> In this case, am I right in thinking it makes sense to remove
> COMPONENT_IF_DOWNSTREAM too, and signal the (single) 
> component interface
> identifier, in the IPv4, IPv6 or IF_INDEX TLV?

This is how I felt it should work. I don't see any additional
value in COMPONENT_IF_DOWNSTREAM that can't be handled by
the IF_INDEX TLV. Both carry the same information, the
unnumbered interface identifier.

> 
> We'd be interested to hear if anyone on the mailing list 
> finds this approach
> overly restrictive.
> 
> Ed.
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: 13 September 2001 14:58
> To: Edward Harrison
> Cc: 'Yakov Rekhter'; Nic Larkin; [email-masked]'
> Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
> 
> 
> Ed,
> 
> > Can you clarify whether you are proposing removing the
> COMPONENT_IF_UPSTREAM
> > TLV from the INTERFACE_ID hop object (or were you just 
> saying that Steve
> > needn't use it if he doesn't want to)?
> 
> I am proposing to remove the COMPONENT_IF_UPSTREAM.
> 
> Yakov.
> 

Delivery-date: Thu, 13 Sep 2001 08:10:21 -0700
From: Edward Harrison <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>
Cc: Nic Larkin <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 13 Sep 2001 16:06:19 +0100
Deferred-Delivery: Thu, 13 Sep 2001 16:08:00 +0100

Yakov,

> > Can you clarify whether you are proposing removing the
COMPONENT_IF_UPSTREAM
> > TLV from the INTERFACE_ID hop object (or were you just saying that Steve
> > needn't use it if he doesn't want to)?
> 
> I am proposing to remove the COMPONENT_IF_UPSTREAM.

In this case, am I right in thinking it makes sense to remove
COMPONENT_IF_DOWNSTREAM too, and signal the (single) component interface
identifier, in the IPv4, IPv6 or IF_INDEX TLV?

We'd be interested to hear if anyone on the mailing list finds this approach
overly restrictive.

Ed.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: 13 September 2001 14:58
To: Edward Harrison
Cc: 'Yakov Rekhter'; Nic Larkin; [email-masked]'
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 

Ed,

> Can you clarify whether you are proposing removing the
COMPONENT_IF_UPSTREAM
> TLV from the INTERFACE_ID hop object (or were you just saying that Steve
> needn't use it if he doesn't want to)?

I am proposing to remove the COMPONENT_IF_UPSTREAM.

Yakov.

Delivery-date: Thu, 13 Sep 2001 07:00:39 -0700
To: Edward Harrison <[email-masked]>
cc: "'Yakov Rekhter'" <[email-masked]>, Nic Larkin <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 13 Sep 2001 06:58:28 -0700
From: Yakov Rekhter <[email-masked]>

Ed,

> Can you clarify whether you are proposing removing the COMPONENT_IF_UPSTREAM
> TLV from the INTERFACE_ID hop object (or were you just saying that Steve
> needn't use it if he doesn't want to)?

I am proposing to remove the COMPONENT_IF_UPSTREAM.

Yakov.

Delivery-date: Thu, 13 Sep 2001 02:59:09 -0700
From: Edward Harrison <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>
Cc: Nic Larkin <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 13 Sep 2001 10:55:41 +0100
Deferred-Delivery: Thu, 13 Sep 2001 10:57:00 +0100

Yakov,

Can you clarify whether you are proposing removing the COMPONENT_IF_UPSTREAM
TLV from the INTERFACE_ID hop object (or were you just saying that Steve
needn't use it if he doesn't want to)?

As far as I can see, there is no restriction in LMP, for example, that
requires data links to be grouped into upstream and downstream pairs.  The
ability to signal separate upstream and downstream links, therefore seems to
be potentially useful.

Thanks,

Ed Harrison

-----------------
Edward Harrison  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: 12 September 2001 20:56
To: Atkinson, Stephen
Cc: [email-masked]'
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 

Stephen,

> I didn't get any comments on this. Would anyone care to 
> respond?

Sorry for the delay... comments below....

> Thanks,
> steve atkinson
> 
> >  -----Original Message-----
> > From: 	Atkinson, Stephen  
> > Sent:	Monday, September 10, 2001 4:11 PM
> > To:	[email-masked]
> > Subject:	Questions on draft-ietf-mpls-bundle-00
> > 
> > I've been reading the draft-ietf-mpls-bundle-00 spec and have 
> > a couple questions.
> > 
> > Basically I'm trying to focus on why signaling unnumbered 
> > components using
> > Explicit Indication by Interface ID is different from all 
> > other cases. This being the
> > only case which specifies an interface (component) for each 
> > direction of a bi-directional LSP.

My suggestion would be to make signaling unnumbered components
using Explicit Indication by Interface ID the same as all other
cases. That is, when signaling unnumbered components using
Explicit Indication the signaling would carry just *one*
Interface ID, and this Interface ID would identify the component
link that should be used in *both* directions.

Yakov.

Delivery-date: Wed, 12 Sep 2001 13:01:28 -0700
To: "Atkinson, Stephen" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Wed, 12 Sep 2001 12:56:00 -0700
From: Yakov Rekhter <[email-masked]>

Stephen,

> I didn't get any comments on this. Would anyone care to 
> respond?

Sorry for the delay... comments below....

> Thanks,
> steve atkinson
> 
> >  -----Original Message-----
> > From: 	Atkinson, Stephen  
> > Sent:	Monday, September 10, 2001 4:11 PM
> > To:	[email-masked]
> > Subject:	Questions on draft-ietf-mpls-bundle-00
> > 
> > I've been reading the draft-ietf-mpls-bundle-00 spec and have 
> > a couple questions.
> > 
> > Basically I'm trying to focus on why signaling unnumbered 
> > components using
> > Explicit Indication by Interface ID is different from all 
> > other cases. This being the
> > only case which specifies an interface (component) for each 
> > direction of a bi-directional LSP.

My suggestion would be to make signaling unnumbered components
using Explicit Indication by Interface ID the same as all other
cases. That is, when signaling unnumbered components using
Explicit Indication the signaling would carry just *one*
Interface ID, and this Interface ID would identify the component
link that should be used in *both* directions.

Yakov.

Delivery-date: Wed, 12 Sep 2001 12:22:56 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Questions on draft-ietf-mpls-bundle-00
Date: Wed, 12 Sep 2001 15:17:15 -0400

I didn't get any comments on this. Would anyone care to 
respond?

Thanks,
steve atkinson

>  -----Original Message-----
> From: 	Atkinson, Stephen  
> Sent:	Monday, September 10, 2001 4:11 PM
> To:	[email-masked]
> Subject:	Questions on draft-ietf-mpls-bundle-00
> 
> I've been reading the draft-ietf-mpls-bundle-00 spec and have 
> a couple questions.
> 
> Basically I'm trying to focus on why signaling unnumbered 
> components using
> Explicit Indication by Interface ID is different from all 
> other cases. This being the
> only case which specifies an interface (component) for each 
> direction of a
> bi-directional LSP.
> 
> Bundling section 3.3.2 (Explicit Indication) requires that 
> the upstream node specify
> the component interface to use in each direction when setting 
> up bi-directional
> LSPs using unnumbered components.
> 
> Bundling section 3.3.1 (Implicit Indication) doesn't have 
> this requirement. Apparently
> when signaling using "Implicit Indication" (for a 
> bi-directional LSP) the reverse direction
> can be inferred. Is this true? If so is this behavior 
> specified anywhere?
> 
> Also, when signaling a bi-directional LSP using numbered 
> components the
> reverse direction component can apparently be inferred using 
> Implicit Indication or 
> Explicit Indication by Interface ID. Is this true? 
> 
> Assuming the statements above are correct. Why must a 
> bi-directional LSP being setup using
> Explicit Indication and unnumbered components, specify a 
> component for each direction, while
> each of the following only requires specifying a single 
> component (or interface)?
> 
>    - unnumbered component signaled implicitly
>    - numbered component signaled implicitly
>    - numbered component signaled explicitly
>    - unnumbered interface (not bundling) signaled implicitly 
> or explicitly
>    - numbered interface (not bundling) signaled implicitly or 
> explicitly
> 
> 
> Thanks,
> steve atkinson
> 
> 
> 

Delivery-date: Mon, 10 Sep 2001 18:40:20 -0700
To: =?iso-2022-jp?B?VG9tb2hpa28bJEIhIRsoQllBR1lV?= <[email-masked]>
cc: [email-masked]
Subject: Re: Q about draft-ccamp-gmpls-routing-00 and ospf-gmpls-extensions-00 
Date: Mon, 10 Sep 2001 18:39:00 -0700
From: Yakov Rekhter <[email-masked]>

Yagyu,

> I have a question about draft-ietf-ccamp-gmpls-routing-00 and 
> draft-ietf-ccamp-ospf-gmpls-extensions-00.
> 
> In 6.4.4 of routing draft, when Switching capability is LSC,
> 
>    The additional information includes Reservable Bandwidth per
>    priority, which specifies the bandwidth of an LSP that could be
>    supported by the interface at a given priority number.
> 
> However, In 5.6 of ospf-extensions darft,
> 
>    When the Switching Capability field is LSC, there is no specific
>    information.
> 
> There is a confilct, which is true?

In the case of LSC the Reservable Bandwidth per priority is
encoded in Max LSP of the Interface Switching Capability
Descriptor.

Yakov.

Delivery-date: Mon, 10 Sep 2001 18:18:11 -0700
Reply-To: =?iso-2022-jp?B?VG9tb2hpa28bJEIhIRsoQllBR1lV?= <[email-masked]>
From: =?iso-2022-jp?B?VG9tb2hpa28bJEIhIRsoQllBR1lV?= <[email-masked]>
To: <[email-masked]>
Subject: Q about draft-ccamp-gmpls-routing-00 and ospf-gmpls-extensions-00
Date: Tue, 11 Sep 2001 10:15:33 +0900

I have a question about draft-ietf-ccamp-gmpls-routing-00 and 
draft-ietf-ccamp-ospf-gmpls-extensions-00.

In 6.4.4 of routing draft, when Switching capability is LSC,

   The additional information includes Reservable Bandwidth per
   priority, which specifies the bandwidth of an LSP that could be
   supported by the interface at a given priority number.

However, In 5.6 of ospf-extensions darft,

   When the Switching Capability field is LSC, there is no specific
   information.

There is a confilct, which is true?
In my personal opinion, I prefer ospf-extensions draft's method.

Thanks.

Yagyu@NEC Corporaiton

Delivery-date: Mon, 10 Sep 2001 13:13:05 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: [email-masked]
Subject: Questions on draft-ietf-mpls-bundle-00
Date: Mon, 10 Sep 2001 16:10:47 -0400

I've been reading the draft-ietf-mpls-bundle-00 spec and have a couple
questions.

Basically I'm trying to focus on why signaling unnumbered components using
Explicit Indication by Interface ID is different from all other cases. This
being the
only case which specifies an interface (component) for each direction of a
bi-directional LSP.

Bundling section 3.3.2 (Explicit Indication) requires that the upstream node
specify
the component interface to use in each direction when setting up
bi-directional
LSPs using unnumbered components.

Bundling section 3.3.1 (Implicit Indication) doesn't have this requirement.
Apparently
when signaling using "Implicit Indication" (for a bi-directional LSP) the
reverse direction
can be inferred. Is this true? If so is this behavior specified anywhere?

Also, when signaling a bi-directional LSP using numbered components the
reverse direction component can apparently be inferred using Implicit
Indication or 
Explicit Indication by Interface ID. Is this true? 

Assuming the statements above are correct. Why must a bi-directional LSP
being setup using
Explicit Indication and unnumbered components, specify a component for each
direction, while
each of the following only requires specifying a single component (or
interface)?

   - unnumbered component signaled implicitly
   - numbered component signaled implicitly
   - numbered component signaled explicitly
   - unnumbered interface (not bundling) signaled implicitly or explicitly
   - numbered interface (not bundling) signaled implicitly or explicitly

Thanks,
steve atkinson

Delivery-date: Mon, 10 Sep 2001 10:55:53 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: [email-masked]
Subject: RE: relationship of ChannelFail and Data Link FSM
Date: Mon, 10 Sep 2001 10:50:32 -0700

George,
  Yes.

thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 10:52 AM
> To: Jonathan Lang
> Cc: [email-masked]
> Subject: RE: relationship of ChannelFail and Data Link FSM
> 
> 
> Hello Jonathan,
> 
> Thanks for the clarification.
> 
> Does this mean there should be a transition in the Active 
> Data Link FSM
> Description from Up/Alloc to Down, triggered by a 'failure localized'
> event?
> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: Jonathan Lang [mailto:[email-masked]]
> >Sent: Monday, September 10, 2001 1:13 PM
> >To: George Young; [email-masked]
> >Subject: RE: relationship of ChannelFail and Data Link FSM
> >
> >
> >George,
> >  The upstream node should put the data link into the Down 
> state.  The
> >downstream node remains in the Up/Alloc state since it doesn't 
> >know if the
> >failure is with this particular link or if it is further 
> upstream.  The
> >reason to remain in up/alloc is that it may see restored 
> >traffic over the
> >link if the failure is repaired upstream.
> >
> >Thanks,
> >Jonathan
> >
> >> -----Original Message-----
> >> From: George Young [mailto:[email-masked]]
> >> Sent: Friday, September 07, 2001 10:13 AM
> >> To: [email-masked]
> >> Subject: relationship of ChannelFail and Data Link FSM
> >> 
> >> 
> >> Regarding ID draft-ietf-ccamp-lmp-00.txt, I have a 
> question about the
> >> ChannelFail message and the Data Link FSM. 
> >> 
> >> Firstly, my understanding is that when channel monitoring detects a
> >> failure, an LMP ChannelFail message is sent upstream, 
> relative to the
> >> direction of transmission. A node which receives this message 
> >> and knows
> >> via monitoring that its upstream link is ok has localized 
> >the failure.
> >> 
> >> My question is does this cause any state change in the 
> Data Link FSM,
> >> and if so, does it occur only in the node which localizes 
> >the failure,
> >> or all nodes which are aware of the failure. The current 
> FSM does not
> >> seem to address this.
> >> 
> >> Regards,
> >> George.
> >> edgeflow Inc.
> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> phone: +1 613-270-9279 Ext 287
> >> fax: +1 613-270-9268
> >> 
> >> 
> >
> 

Delivery-date: Mon, 10 Sep 2001 10:54:28 -0700
content-class: urn:content-classes:message
Subject: RE: relationship of ChannelFail and Data Link FSM
Date:  Mon, 10 Sep 2001 13:51:35 -0400
From: "George Young" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

Hello Jonathan,

Thanks for the clarification.

Does this mean there should be a transition in the Active Data Link FSM
Description from Up/Alloc to Down, triggered by a 'failure localized'
event?

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: Jonathan Lang [mailto:[email-masked]]
>Sent: Monday, September 10, 2001 1:13 PM
>To: George Young; [email-masked]
>Subject: RE: relationship of ChannelFail and Data Link FSM
>
>
>George,
>  The upstream node should put the data link into the Down state.  The
>downstream node remains in the Up/Alloc state since it doesn't=20
>know if the
>failure is with this particular link or if it is further upstream.  The
>reason to remain in up/alloc is that it may see restored=20
>traffic over the
>link if the failure is repaired upstream.
>
>Thanks,
>Jonathan
>
>> -----Original Message-----
>> From: George Young [mailto:[email-masked]]
>> Sent: Friday, September 07, 2001 10:13 AM
>> To: [email-masked]
>> Subject: relationship of ChannelFail and Data Link FSM
>>=20
>>=20
>> Regarding ID draft-ietf-ccamp-lmp-00.txt, I have a question about the
>> ChannelFail message and the Data Link FSM.=20
>>=20
>> Firstly, my understanding is that when channel monitoring detects a
>> failure, an LMP ChannelFail message is sent upstream, relative to the
>> direction of transmission. A node which receives this message=20
>> and knows
>> via monitoring that its upstream link is ok has localized=20
>the failure.
>>=20
>> My question is does this cause any state change in the Data Link FSM,
>> and if so, does it occur only in the node which localizes=20
>the failure,
>> or all nodes which are aware of the failure. The current FSM does not
>> seem to address this.
>>=20
>> Regards,
>> George.
>> edgeflow Inc.
>> 329 March Rd., Kanata, ON, Canada, K2K 2E1
>> phone: +1 613-270-9279 Ext 287
>> fax: +1 613-270-9268
>>=20
>>=20
>

Delivery-date: Mon, 10 Sep 2001 10:20:32 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, [email-masked]
Subject: RE: relationship of ChannelFail and Data Link FSM
Date: Mon, 10 Sep 2001 10:13:00 -0700

George,
  The upstream node should put the data link into the Down state.  The
downstream node remains in the Up/Alloc state since it doesn't know if the
failure is with this particular link or if it is further upstream.  The
reason to remain in up/alloc is that it may see restored traffic over the
link if the failure is repaired upstream.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 10:13 AM
> To: [email-masked]
> Subject: relationship of ChannelFail and Data Link FSM
> 
> 
> Regarding ID draft-ietf-ccamp-lmp-00.txt, I have a question about the
> ChannelFail message and the Data Link FSM. 
> 
> Firstly, my understanding is that when channel monitoring detects a
> failure, an LMP ChannelFail message is sent upstream, relative to the
> direction of transmission. A node which receives this message 
> and knows
> via monitoring that its upstream link is ok has localized the failure.
> 
> My question is does this cause any state change in the Data Link FSM,
> and if so, does it occur only in the node which localizes the failure,
> or all nodes which are aware of the failure. The current FSM does not
> seem to address this.
> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 

Delivery-date: Fri, 07 Sep 2001 12:51:37 -0700
content-class: urn:content-classes:message
Subject: relationship of RSVP-TE and LMP
Date:  Fri, 7 Sep 2001 15:47:28 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

I have two questions about the relationship of RSVP-TE
(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
(draft-ietf-ccamp-lmp-00.txt).

First of all, my understanding of the LMP ChannelActive message is that
it is used to indicate to the downstream (relative to data flow
direction) node that monitoring should be used.

The scenario I have in mind is an RSVP call setup consisting of a
bidirectional optical path.  Presumably a switching node has to reserve
data channels and associate them with the optical path when an RSVP PATH
message arrives.

1) My first question is what is the timing of LMP ChannelActive messages
relative to RSVP messages.

Do ChannelActive messages flow downstream (relative to call
establishment direction) more-or-less in phase with PATH messages, and
upstream (relative to call establishment direction) more-or-less in
phase with RESV messages?

2) My second question is what addtional information information do
ChannelActive messages provide?

If a link is to be monitored when associated with an active call, it
appears the node already has this information.

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Fri, 07 Sep 2001 10:17:36 -0700
content-class: urn:content-classes:message
Subject: relationship of ChannelFail and Data Link FSM
Date:  Fri, 7 Sep 2001 13:12:32 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

Regarding ID draft-ietf-ccamp-lmp-00.txt, I have a question about the
ChannelFail message and the Data Link FSM.=20

Firstly, my understanding is that when channel monitoring detects a
failure, an LMP ChannelFail message is sent upstream, relative to the
direction of transmission. A node which receives this message and knows
via monitoring that its upstream link is ok has localized the failure.

My question is does this cause any state change in the Data Link FSM,
and if so, does it occur only in the node which localizes the failure,
or all nodes which are aware of the failure. The current FSM does not
seem to address this.

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Thu, 06 Sep 2001 03:49:42 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-00.txt
Date: Thu, 06 Sep 2001 06:44:45 -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-00.txt
	Pages		: 20
	Date		: 05-Sep-01
	
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-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-routing-00.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 06 Sep 2001 03:49:36 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-00.txt
Date: Thu, 06 Sep 2001 06:44:40 -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-00.txt
	Pages		: 9
	Date		: 05-Sep-01
	
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].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-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-ospf-gmpls-extensions-00.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 05 Sep 2001 09:08:20 -0700
Date: Wed, 05 Sep 2001 12:02:04 -0400
From: Guangzhi Li <[email-masked]>
To: Hang Liu <[email-masked]>
Cc: Fong Liaw <[email-masked]>, Eric Gray <[email-masked]>, John Drake <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Hang:

Yah. I see the point. As long as this clarification is addressed, the rule (2)
may not be needed since setup priority has to be greater than the holding
priority to preempt an established LSP.

One question: assume LSP A with Path message from node 1 and node 2 and LSP B
with Resv message from node 2 to node 1. Node 1 has cross-conneced for LSP A and
node 2 has cross-connected for LSP B. The setup prority is equal to the holding
priority for both LSP A and LSP B. It is easy to resolve the contention on node
2. How about node 1? LSP A has been setup on node 1 but LSP B has not. Resv
message is required to use the setup priority to preempt other established
LSPs.

What is the harm to put a rule without confliction with previous definitions.
Otherwise, other clarifications are required.

Regards,

Guangzhi

Hang Liu wrote:

> I think that Fong's points are valid. We can assume that "RESV" message
> means that the LSP has been set up (at least within the downstream node).
> There are the holding priority associated with it. The PATH message for the
> other LSP can win the contentinon only if its set-up priority > the holding
> priority of another LSP.
>
> Hang
>
> -----Original Message-----
> From: Guangzhi Li [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 9:22 AM
> To: Fong Liaw
> Cc: Eric Gray; John Drake; [email-masked]; [email-masked]
> Subject: Re: Question on GMPLS contentions resolution
>
> Fong:
>
> Would you please explain more why (2) is not needed if (1) is changed ?
> IF (holding priority == setup priority), how to resolve it ?
>
> By the way, how to interperate holding priority and setup priority should be
> explained when they are defined.
>
> (3) is an extension of current GMPLS specification. Current GMPLS clearly
> says that
> this rule deals with two bi-directional LSPs.
>
> Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > GMPLS includes SESSION_ATTRIBUTE object,
> > but the current text on contention resolution
> > does not take it into account. So I think adding
> > (1) as clarification is needed, however, I would
> > change (1) to
> >
> > "(1) Based on the LSPs' hold and setup priority."
> >
> > I might remove (2) if it is understood that
> > receiving a Resv means hold priority should be
> > used in (1).
> >
> > We already have (3), so that is fine.
> >
> > -Fong
> >
> > --- Guangzhi Li <[email-masked]> wrote:
> > > Hi, all:
> > >
> > > I posted the contention resolution question 10 days
> > > ago. After some fruitful
> > > discussions with John Drake, Eric Gray, Fong Liaw,
> > > Hang Liu, I propose the
> > > following three rules to resolve any contention in
> > > GMPLS although there is no
> > > signaling correctness issue. The following rules
> > > should applied in sequence to
> > > both bi-directional and uni-directional LSPs:
> > >
> > > (1) Higher priority LSP wins lower priority LSP.
> > > (2) LSP with Reply (Resv in RSVP) message wins LSP
> > > with Request
> > > (Path in RSVP) message.
> > > (3) LSP with the higher node ID assigning the label
> > > wins the contention
> > > if race conditions happen between two LSPs with
> > > Request messages.
> > >
> > > Since race conditions won't happen between two LSPs
> > > with Reply messages,
> > > the above three rules solve all possible contention
> > > scenarios.
> > >
> > > Proposed modification of the GMPLS functional
> > > specification, text from
> > > section 4.2:
> > >
> >
> ---------------------------------------------------------------------------
> > >
> > > By allowing bi-directional LSP setup and suggested
> > > label in the GMPLS
> > > framework,  contention for labels may occur between
> > > two bidirectional
> > > LSP setup requests, or between an uni-directional
> > > and a bi-directional
> > > LSP, traveling in opposite directions.  This
> > > contention occurs when both sides
> > > allocate the same resources (labels) at effectively
> > > the same time. If there is no
> > > restriction on the labels that can be used for
> > > bidirectional LSPs and if
> > > there are alternate resources, downstream label
> > > assignment will apply
> > > and there is no contention. However, if there is a
> > > restriction on the
> > > labels that can be used for the bidirectional LSPs
> > > (for example, if they
> > > must be physically coupled on a single I/O card), or
> > > if there are no
> > > more resources available, then the contention must
> > > be resolved by other
> > > means. Although contention resolution is not a
> > > mandatory requirement for
> > > signaling correctness, contention resolution is
> > > strongly recommended
> > > for performance optimization. To resolve contention,
> > > the following three rules
> > > SHOULD be applied in sequence:
> > > (1) A higher priority LSP wins over a lower priority
> > > LSP.
> > > (2) LSP with a Reply message wins over a LSP with a
> > > Request
> > > message.
> > > (3) LSP with higher node ID assigning the label wins
> > > the contention if
> > > race conditions happen between two LSPs with Request
> > > messages.
> > > ........
> > >
> > > The rest of the text from this section should be
> > > updated accordingly.
> > >
> > > Thanks,
> > >
> > > Guangzhi
> > >
> > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > > During GMPLS last call, I posted the same question
> > > on the mailing list
> > > > without response. Please somebody spend a little
> > > time and check with the
> > > > following example? Something seems not clear when
> > > the current GMPLS
> > > > contention resution schemes are applied on a
> > > framework with both
> > > > bi-directional and uni-directional LSPs. Your
> > > clarification is very much
> > > > appreciated.
> > > >
> > > > Sincerely,
> > > >
> > > > Guangzhi
> > > >
> > > >
> > >
> >
> ----------------------------------------------------------------------------
> ---
> > > >
> > > > The issue arises because contention is resolved
> > > between bi-directional
> > > > LSPs by the node with the higher node index while
> > > for uni-directional
> > > > LSPs, contention is resolved by the downstream
> > > node. Consider the
> > > > following example of two nodes with paired,
> > > bi-directional interfaces
> > > > (i.e., a transmitter/receiver pair of ports).
> > > Node 1 with ID=100 and
> > > > node 2 with ID = 50.  Node 1 uses label 1 for the
> > > transmitter port and
> > > > label 2 for the receiver port; node 2 uses label 4
> > > for the transmitter
> > > > port and label 3 for the receiver port.   We
> > > assume that a
> > > > bi-directional LSP requires a single I/O
> > > interface.
> > > >
> > > > We consider two LSPs - a uni-directional LSP (LSP
> > > A) and a
> > > > bi-directional LSP (LSP B). Both LSPs are going
> > > from node 1
> > > > to node 2, with the uni-directional LSP setup
> > > request arriving marginally before
> > > >
> > > > the bi-directional LSP.  LSP A does not use a
> > > suggested label, and thus
> > > > is assigned a label (port) by node 2.  Label 3 is
> > > assigned,
> > > > corresponding to label 1 at node 1.  At the same
> > > time, for LSP B (the
> > > > bi-directional LSP) node 1 assigns label 2, with
> > > suggested label 1.
> > > > Because node 1 has the higher node ID, node 2 will
> > > assume (due to the
> > > > contention resolution rule for bi-directional
> > > LSPs) that LSP B wins the
> > > > contention and thus label 3 is assigned to LSP B.
> > > Thus label 1 at node
> > > > 1 (label 3 at node 2) has been assigned to two
> > > different LSPs.  Both
> > > > LSPs have "won" the contention.
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant messaging with Yahoo!
> Messenger
> > http://im.yahoo.com

Delivery-date: Wed, 05 Sep 2001 08:20:30 -0700
Date: Wed, 05 Sep 2001 11:05:21 -0400
From: Eric Gray <[email-masked]>
To: Guangzhi Li <[email-masked]>
Cc: Fong Liaw <[email-masked]>, John Drake <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Guangzhi,

    The reference to setup and holding priorities would require a reference
to [RSVP-TE] and [CR-LDP] references already included in the draft.
Whther or not these need to be specifically called out again is a call for
the authors - assuming that they include any of your proposed changes.

--
Eric Gray

You wrote:

> Fong:
>
> Would you please explain more why (2) is not needed if (1) is changed ?
> IF (holding priority == setup priority), how to resolve it ?
>
> By the way, how to interperate holding priority and setup priority should be
> explained when they are defined.
>
> (3) is an extension of current GMPLS specification. Current GMPLS clearly says that
> this rule deals with two bi-directional LSPs.
>
> Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > GMPLS includes SESSION_ATTRIBUTE object,
> > but the current text on contention resolution
> > does not take it into account. So I think adding
> > (1) as clarification is needed, however, I would
> > change (1) to
> >
> > "(1) Based on the LSPs' hold and setup priority."
> >
> > I might remove (2) if it is understood that
> > receiving a Resv means hold priority should be
> > used in (1).
> >
> > We already have (3), so that is fine.
> >
> > -Fong
> >
> > --- Guangzhi Li <[email-masked]> wrote:
> > > Hi, all:
> > >
> > > I posted the contention resolution question 10 days
> > > ago. After some fruitful
> > > discussions with John Drake, Eric Gray, Fong Liaw,
> > > Hang Liu, I propose the
> > > following three rules to resolve any contention in
> > > GMPLS although there is no
> > > signaling correctness issue. The following rules
> > > should applied in sequence to
> > > both bi-directional and uni-directional LSPs:
> > >
> > > (1) Higher priority LSP wins lower priority LSP.
> > > (2) LSP with Reply (Resv in RSVP) message wins LSP
> > > with Request
> > > (Path in RSVP) message.
> > > (3) LSP with the higher node ID assigning the label
> > > wins the contention
> > > if race conditions happen between two LSPs with
> > > Request messages.
> > >
> > > Since race conditions won't happen between two LSPs
> > > with Reply messages,
> > > the above three rules solve all possible contention
> > > scenarios.
> > >
> > > Proposed modification of the GMPLS functional
> > > specification, text from
> > > section 4.2:
> > >
> > ---------------------------------------------------------------------------
> > >
> > > By allowing bi-directional LSP setup and suggested
> > > label in the GMPLS
> > > framework,  contention for labels may occur between
> > > two bidirectional
> > > LSP setup requests, or between an uni-directional
> > > and a bi-directional
> > > LSP, traveling in opposite directions.  This
> > > contention occurs when both sides
> > > allocate the same resources (labels) at effectively
> > > the same time. If there is no
> > > restriction on the labels that can be used for
> > > bidirectional LSPs and if
> > > there are alternate resources, downstream label
> > > assignment will apply
> > > and there is no contention. However, if there is a
> > > restriction on the
> > > labels that can be used for the bidirectional LSPs
> > > (for example, if they
> > > must be physically coupled on a single I/O card), or
> > > if there are no
> > > more resources available, then the contention must
> > > be resolved by other
> > > means. Although contention resolution is not a
> > > mandatory requirement for
> > > signaling correctness, contention resolution is
> > > strongly recommended
> > > for performance optimization. To resolve contention,
> > > the following three rules
> > > SHOULD be applied in sequence:
> > > (1) A higher priority LSP wins over a lower priority
> > > LSP.
> > > (2) LSP with a Reply message wins over a LSP with a
> > > Request
> > > message.
> > > (3) LSP with higher node ID assigning the label wins
> > > the contention if
> > > race conditions happen between two LSPs with Request
> > > messages.
> > > ........
> > >
> > > The rest of the text from this section should be
> > > updated accordingly.
> > >
> > > Thanks,
> > >
> > > Guangzhi
> > >
> > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > > During GMPLS last call, I posted the same question
> > > on the mailing list
> > > > without response. Please somebody spend a little
> > > time and check with the
> > > > following example? Something seems not clear when
> > > the current GMPLS
> > > > contention resution schemes are applied on a
> > > framework with both
> > > > bi-directional and uni-directional LSPs. Your
> > > clarification is very much
> > > > appreciated.
> > > >
> > > > Sincerely,
> > > >
> > > > Guangzhi
> > > >
> > > >
> > >
> > -------------------------------------------------------------------------------
> > > >
> > > > The issue arises because contention is resolved
> > > between bi-directional
> > > > LSPs by the node with the higher node index while
> > > for uni-directional
> > > > LSPs, contention is resolved by the downstream
> > > node. Consider the
> > > > following example of two nodes with paired,
> > > bi-directional interfaces
> > > > (i.e., a transmitter/receiver pair of ports).
> > > Node 1 with ID=100 and
> > > > node 2 with ID = 50.  Node 1 uses label 1 for the
> > > transmitter port and
> > > > label 2 for the receiver port; node 2 uses label 4
> > > for the transmitter
> > > > port and label 3 for the receiver port.   We
> > > assume that a
> > > > bi-directional LSP requires a single I/O
> > > interface.
> > > >
> > > > We consider two LSPs - a uni-directional LSP (LSP
> > > A) and a
> > > > bi-directional LSP (LSP B). Both LSPs are going
> > > from node 1
> > > > to node 2, with the uni-directional LSP setup
> > > request arriving marginally before
> > > >
> > > > the bi-directional LSP.  LSP A does not use a
> > > suggested label, and thus
> > > > is assigned a label (port) by node 2.  Label 3 is
> > > assigned,
> > > > corresponding to label 1 at node 1.  At the same
> > > time, for LSP B (the
> > > > bi-directional LSP) node 1 assigns label 2, with
> > > suggested label 1.
> > > > Because node 1 has the higher node ID, node 2 will
> > > assume (due to the
> > > > contention resolution rule for bi-directional
> > > LSPs) that LSP B wins the
> > > > contention and thus label 3 is assigned to LSP B.
> > > Thus label 1 at node
> > > > 1 (label 3 at node 2) has been assigned to two
> > > different LSPs.  Both
> > > > LSPs have "won" the contention.
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
> > http://im.yahoo.com

Delivery-date: Wed, 05 Sep 2001 08:18:11 -0700
Date: Wed, 05 Sep 2001 11:02:20 -0400
From: Eric Gray <[email-masked]>
To: Guangzhi Li <[email-masked]>
Cc: Fong Liaw <[email-masked]>, John Drake <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Guangzhi,

    In any case where there is a tie between holding priority and setup
priority, holding priority wins.  Setup priority MUST be higher (i.e. -
have a lower value) than holding priority for setup to win.  This is not
clearly stated anywhere in the current RSVP-TE draft, nor in the
RFC (2751) that it refers to, nor in the CR-LDP draft.  However, it
may be directly inferred from the fact that the setup priority is allowed
to be equal to the hold/holding priority for the same LSP being setup
but may not be greater.  The stated reason for this is to preclude an
LSP from being preempted by another LSP having identical priorities
and then preempting that LSP in turn.  Clearly this intent would not
be satisfied if a tie resulted in preemption.

--
Eric Gray

wrote:

> Fong:
>
> Would you please explain more why (2) is not needed if (1) is changed ?
> IF (holding priority == setup priority), how to resolve it ?
>
> By the way, how to interperate holding priority and setup priority should be
> explained when they are defined.
>
> (3) is an extension of current GMPLS specification. Current GMPLS clearly says that
> this rule deals with two bi-directional LSPs.
>
> Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > GMPLS includes SESSION_ATTRIBUTE object,
> > but the current text on contention resolution
> > does not take it into account. So I think adding
> > (1) as clarification is needed, however, I would
> > change (1) to
> >
> > "(1) Based on the LSPs' hold and setup priority."
> >
> > I might remove (2) if it is understood that
> > receiving a Resv means hold priority should be
> > used in (1).
> >
> > We already have (3), so that is fine.
> >
> > -Fong
> >
> > --- Guangzhi Li <[email-masked]> wrote:
> > > Hi, all:
> > >
> > > I posted the contention resolution question 10 days
> > > ago. After some fruitful
> > > discussions with John Drake, Eric Gray, Fong Liaw,
> > > Hang Liu, I propose the
> > > following three rules to resolve any contention in
> > > GMPLS although there is no
> > > signaling correctness issue. The following rules
> > > should applied in sequence to
> > > both bi-directional and uni-directional LSPs:
> > >
> > > (1) Higher priority LSP wins lower priority LSP.
> > > (2) LSP with Reply (Resv in RSVP) message wins LSP
> > > with Request
> > > (Path in RSVP) message.
> > > (3) LSP with the higher node ID assigning the label
> > > wins the contention
> > > if race conditions happen between two LSPs with
> > > Request messages.
> > >
> > > Since race conditions won't happen between two LSPs
> > > with Reply messages,
> > > the above three rules solve all possible contention
> > > scenarios.
> > >
> > > Proposed modification of the GMPLS functional
> > > specification, text from
> > > section 4.2:
> > >
> > ---------------------------------------------------------------------------
> > >
> > > By allowing bi-directional LSP setup and suggested
> > > label in the GMPLS
> > > framework,  contention for labels may occur between
> > > two bidirectional
> > > LSP setup requests, or between an uni-directional
> > > and a bi-directional
> > > LSP, traveling in opposite directions.  This
> > > contention occurs when both sides
> > > allocate the same resources (labels) at effectively
> > > the same time. If there is no
> > > restriction on the labels that can be used for
> > > bidirectional LSPs and if
> > > there are alternate resources, downstream label
> > > assignment will apply
> > > and there is no contention. However, if there is a
> > > restriction on the
> > > labels that can be used for the bidirectional LSPs
> > > (for example, if they
> > > must be physically coupled on a single I/O card), or
> > > if there are no
> > > more resources available, then the contention must
> > > be resolved by other
> > > means. Although contention resolution is not a
> > > mandatory requirement for
> > > signaling correctness, contention resolution is
> > > strongly recommended
> > > for performance optimization. To resolve contention,
> > > the following three rules
> > > SHOULD be applied in sequence:
> > > (1) A higher priority LSP wins over a lower priority
> > > LSP.
> > > (2) LSP with a Reply message wins over a LSP with a
> > > Request
> > > message.
> > > (3) LSP with higher node ID assigning the label wins
> > > the contention if
> > > race conditions happen between two LSPs with Request
> > > messages.
> > > ........
> > >
> > > The rest of the text from this section should be
> > > updated accordingly.
> > >
> > > Thanks,
> > >
> > > Guangzhi
> > >
> > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > > During GMPLS last call, I posted the same question
> > > on the mailing list
> > > > without response. Please somebody spend a little
> > > time and check with the
> > > > following example? Something seems not clear when
> > > the current GMPLS
> > > > contention resution schemes are applied on a
> > > framework with both
> > > > bi-directional and uni-directional LSPs. Your
> > > clarification is very much
> > > > appreciated.
> > > >
> > > > Sincerely,
> > > >
> > > > Guangzhi
> > > >
> > > >
> > >
> > -------------------------------------------------------------------------------
> > > >
> > > > The issue arises because contention is resolved
> > > between bi-directional
> > > > LSPs by the node with the higher node index while
> > > for uni-directional
> > > > LSPs, contention is resolved by the downstream
> > > node. Consider the
> > > > following example of two nodes with paired,
> > > bi-directional interfaces
> > > > (i.e., a transmitter/receiver pair of ports).
> > > Node 1 with ID=100 and
> > > > node 2 with ID = 50.  Node 1 uses label 1 for the
> > > transmitter port and
> > > > label 2 for the receiver port; node 2 uses label 4
> > > for the transmitter
> > > > port and label 3 for the receiver port.   We
> > > assume that a
> > > > bi-directional LSP requires a single I/O
> > > interface.
> > > >
> > > > We consider two LSPs - a uni-directional LSP (LSP
> > > A) and a
> > > > bi-directional LSP (LSP B). Both LSPs are going
> > > from node 1
> > > > to node 2, with the uni-directional LSP setup
> > > request arriving marginally before
> > > >
> > > > the bi-directional LSP.  LSP A does not use a
> > > suggested label, and thus
> > > > is assigned a label (port) by node 2.  Label 3 is
> > > assigned,
> > > > corresponding to label 1 at node 1.  At the same
> > > time, for LSP B (the
> > > > bi-directional LSP) node 1 assigns label 2, with
> > > suggested label 1.
> > > > Because node 1 has the higher node ID, node 2 will
> > > assume (due to the
> > > > contention resolution rule for bi-directional
> > > LSPs) that LSP B wins the
> > > > contention and thus label 3 is assigned to LSP B.
> > > Thus label 1 at node
> > > > 1 (label 3 at node 2) has been assigned to two
> > > different LSPs.  Both
> > > > LSPs have "won" the contention.
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
> > http://im.yahoo.com

Delivery-date: Wed, 05 Sep 2001 08:00:12 -0700
From: Hang Liu <[email-masked]>
To: "'Guangzhi Li'" <[email-masked]>, Fong Liaw <[email-masked]>
Cc: Eric Gray <[email-masked]>, John Drake <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Question on GMPLS contentions resolution
Date: Wed, 5 Sep 2001 10:45:22 -0400 

I think that Fong's points are valid. We can assume that "RESV" message
means that the LSP has been set up (at least within the downstream node).
There are the holding priority associated with it. The PATH message for the
other LSP can win the contentinon only if its set-up priority > the holding
priority of another LSP.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 9:22 AM
To: Fong Liaw
Cc: Eric Gray; John Drake; [email-masked]; [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Fong:

Would you please explain more why (2) is not needed if (1) is changed ?
IF (holding priority == setup priority), how to resolve it ?

By the way, how to interperate holding priority and setup priority should be
explained when they are defined.

(3) is an extension of current GMPLS specification. Current GMPLS clearly
says that
this rule deals with two bi-directional LSPs.

Guangzhi

Fong Liaw wrote:

> Guangzhi
>
> GMPLS includes SESSION_ATTRIBUTE object,
> but the current text on contention resolution
> does not take it into account. So I think adding
> (1) as clarification is needed, however, I would
> change (1) to
>
> "(1) Based on the LSPs' hold and setup priority."
>
> I might remove (2) if it is understood that
> receiving a Resv means hold priority should be
> used in (1).
>
> We already have (3), so that is fine.
>
> -Fong
>
> --- Guangzhi Li <[email-masked]> wrote:
> > Hi, all:
> >
> > I posted the contention resolution question 10 days
> > ago. After some fruitful
> > discussions with John Drake, Eric Gray, Fong Liaw,
> > Hang Liu, I propose the
> > following three rules to resolve any contention in
> > GMPLS although there is no
> > signaling correctness issue. The following rules
> > should applied in sequence to
> > both bi-directional and uni-directional LSPs:
> >
> > (1) Higher priority LSP wins lower priority LSP.
> > (2) LSP with Reply (Resv in RSVP) message wins LSP
> > with Request
> > (Path in RSVP) message.
> > (3) LSP with the higher node ID assigning the label
> > wins the contention
> > if race conditions happen between two LSPs with
> > Request messages.
> >
> > Since race conditions won't happen between two LSPs
> > with Reply messages,
> > the above three rules solve all possible contention
> > scenarios.
> >
> > Proposed modification of the GMPLS functional
> > specification, text from
> > section 4.2:
> >
>
---------------------------------------------------------------------------
> >
> > By allowing bi-directional LSP setup and suggested
> > label in the GMPLS
> > framework,  contention for labels may occur between
> > two bidirectional
> > LSP setup requests, or between an uni-directional
> > and a bi-directional
> > LSP, traveling in opposite directions.  This
> > contention occurs when both sides
> > allocate the same resources (labels) at effectively
> > the same time. If there is no
> > restriction on the labels that can be used for
> > bidirectional LSPs and if
> > there are alternate resources, downstream label
> > assignment will apply
> > and there is no contention. However, if there is a
> > restriction on the
> > labels that can be used for the bidirectional LSPs
> > (for example, if they
> > must be physically coupled on a single I/O card), or
> > if there are no
> > more resources available, then the contention must
> > be resolved by other
> > means. Although contention resolution is not a
> > mandatory requirement for
> > signaling correctness, contention resolution is
> > strongly recommended
> > for performance optimization. To resolve contention,
> > the following three rules
> > SHOULD be applied in sequence:
> > (1) A higher priority LSP wins over a lower priority
> > LSP.
> > (2) LSP with a Reply message wins over a LSP with a
> > Request
> > message.
> > (3) LSP with higher node ID assigning the label wins
> > the contention if
> > race conditions happen between two LSPs with Request
> > messages.
> > ........
> >
> > The rest of the text from this section should be
> > updated accordingly.
> >
> > Thanks,
> >
> > Guangzhi
> >
> >
> > >  Dear GMPLS authors and all experts:
> > >
> > > During GMPLS last call, I posted the same question
> > on the mailing list
> > > without response. Please somebody spend a little
> > time and check with the
> > > following example? Something seems not clear when
> > the current GMPLS
> > > contention resution schemes are applied on a
> > framework with both
> > > bi-directional and uni-directional LSPs. Your
> > clarification is very much
> > > appreciated.
> > >
> > > Sincerely,
> > >
> > > Guangzhi
> > >
> > >
> >
>
----------------------------------------------------------------------------
---
> > >
> > > The issue arises because contention is resolved
> > between bi-directional
> > > LSPs by the node with the higher node index while
> > for uni-directional
> > > LSPs, contention is resolved by the downstream
> > node. Consider the
> > > following example of two nodes with paired,
> > bi-directional interfaces
> > > (i.e., a transmitter/receiver pair of ports).
> > Node 1 with ID=100 and
> > > node 2 with ID = 50.  Node 1 uses label 1 for the
> > transmitter port and
> > > label 2 for the receiver port; node 2 uses label 4
> > for the transmitter
> > > port and label 3 for the receiver port.   We
> > assume that a
> > > bi-directional LSP requires a single I/O
> > interface.
> > >
> > > We consider two LSPs - a uni-directional LSP (LSP
> > A) and a
> > > bi-directional LSP (LSP B). Both LSPs are going
> > from node 1
> > > to node 2, with the uni-directional LSP setup
> > request arriving marginally before
> > >
> > > the bi-directional LSP.  LSP A does not use a
> > suggested label, and thus
> > > is assigned a label (port) by node 2.  Label 3 is
> > assigned,
> > > corresponding to label 1 at node 1.  At the same
> > time, for LSP B (the
> > > bi-directional LSP) node 1 assigns label 2, with
> > suggested label 1.
> > > Because node 1 has the higher node ID, node 2 will
> > assume (due to the
> > > contention resolution rule for bi-directional
> > LSPs) that LSP B wins the
> > > contention and thus label 3 is assigned to LSP B.
> > Thus label 1 at node
> > > 1 (label 3 at node 2) has been assigned to two
> > different LSPs.  Both
> > > LSPs have "won" the contention.
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger
> http://im.yahoo.com

Delivery-date: Wed, 05 Sep 2001 06:23:12 -0700
Date: Wed, 05 Sep 2001 09:21:43 -0400
From: Guangzhi Li <[email-masked]>
To: Fong Liaw <[email-masked]>
Cc: Eric Gray <[email-masked]>, John Drake <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Fong:

Would you please explain more why (2) is not needed if (1) is changed ?
IF (holding priority == setup priority), how to resolve it ?

By the way, how to interperate holding priority and setup priority should be
explained when they are defined.

(3) is an extension of current GMPLS specification. Current GMPLS clearly says that
this rule deals with two bi-directional LSPs.

Guangzhi

Fong Liaw wrote:

> Guangzhi
>
> GMPLS includes SESSION_ATTRIBUTE object,
> but the current text on contention resolution
> does not take it into account. So I think adding
> (1) as clarification is needed, however, I would
> change (1) to
>
> "(1) Based on the LSPs' hold and setup priority."
>
> I might remove (2) if it is understood that
> receiving a Resv means hold priority should be
> used in (1).
>
> We already have (3), so that is fine.
>
> -Fong
>
> --- Guangzhi Li <[email-masked]> wrote:
> > Hi, all:
> >
> > I posted the contention resolution question 10 days
> > ago. After some fruitful
> > discussions with John Drake, Eric Gray, Fong Liaw,
> > Hang Liu, I propose the
> > following three rules to resolve any contention in
> > GMPLS although there is no
> > signaling correctness issue. The following rules
> > should applied in sequence to
> > both bi-directional and uni-directional LSPs:
> >
> > (1) Higher priority LSP wins lower priority LSP.
> > (2) LSP with Reply (Resv in RSVP) message wins LSP
> > with Request
> > (Path in RSVP) message.
> > (3) LSP with the higher node ID assigning the label
> > wins the contention
> > if race conditions happen between two LSPs with
> > Request messages.
> >
> > Since race conditions won't happen between two LSPs
> > with Reply messages,
> > the above three rules solve all possible contention
> > scenarios.
> >
> > Proposed modification of the GMPLS functional
> > specification, text from
> > section 4.2:
> >
> ---------------------------------------------------------------------------
> >
> > By allowing bi-directional LSP setup and suggested
> > label in the GMPLS
> > framework,  contention for labels may occur between
> > two bidirectional
> > LSP setup requests, or between an uni-directional
> > and a bi-directional
> > LSP, traveling in opposite directions.  This
> > contention occurs when both sides
> > allocate the same resources (labels) at effectively
> > the same time. If there is no
> > restriction on the labels that can be used for
> > bidirectional LSPs and if
> > there are alternate resources, downstream label
> > assignment will apply
> > and there is no contention. However, if there is a
> > restriction on the
> > labels that can be used for the bidirectional LSPs
> > (for example, if they
> > must be physically coupled on a single I/O card), or
> > if there are no
> > more resources available, then the contention must
> > be resolved by other
> > means. Although contention resolution is not a
> > mandatory requirement for
> > signaling correctness, contention resolution is
> > strongly recommended
> > for performance optimization. To resolve contention,
> > the following three rules
> > SHOULD be applied in sequence:
> > (1) A higher priority LSP wins over a lower priority
> > LSP.
> > (2) LSP with a Reply message wins over a LSP with a
> > Request
> > message.
> > (3) LSP with higher node ID assigning the label wins
> > the contention if
> > race conditions happen between two LSPs with Request
> > messages.
> > ........
> >
> > The rest of the text from this section should be
> > updated accordingly.
> >
> > Thanks,
> >
> > Guangzhi
> >
> >
> > >  Dear GMPLS authors and all experts:
> > >
> > > During GMPLS last call, I posted the same question
> > on the mailing list
> > > without response. Please somebody spend a little
> > time and check with the
> > > following example? Something seems not clear when
> > the current GMPLS
> > > contention resution schemes are applied on a
> > framework with both
> > > bi-directional and uni-directional LSPs. Your
> > clarification is very much
> > > appreciated.
> > >
> > > Sincerely,
> > >
> > > Guangzhi
> > >
> > >
> >
> -------------------------------------------------------------------------------
> > >
> > > The issue arises because contention is resolved
> > between bi-directional
> > > LSPs by the node with the higher node index while
> > for uni-directional
> > > LSPs, contention is resolved by the downstream
> > node. Consider the
> > > following example of two nodes with paired,
> > bi-directional interfaces
> > > (i.e., a transmitter/receiver pair of ports).
> > Node 1 with ID=100 and
> > > node 2 with ID = 50.  Node 1 uses label 1 for the
> > transmitter port and
> > > label 2 for the receiver port; node 2 uses label 4
> > for the transmitter
> > > port and label 3 for the receiver port.   We
> > assume that a
> > > bi-directional LSP requires a single I/O
> > interface.
> > >
> > > We consider two LSPs - a uni-directional LSP (LSP
> > A) and a
> > > bi-directional LSP (LSP B). Both LSPs are going
> > from node 1
> > > to node 2, with the uni-directional LSP setup
> > request arriving marginally before
> > >
> > > the bi-directional LSP.  LSP A does not use a
> > suggested label, and thus
> > > is assigned a label (port) by node 2.  Label 3 is
> > assigned,
> > > corresponding to label 1 at node 1.  At the same
> > time, for LSP B (the
> > > bi-directional LSP) node 1 assigns label 2, with
> > suggested label 1.
> > > Because node 1 has the higher node ID, node 2 will
> > assume (due to the
> > > contention resolution rule for bi-directional
> > LSPs) that LSP B wins the
> > > contention and thus label 3 is assigned to LSP B.
> > Thus label 1 at node
> > > 1 (label 3 at node 2) has been assigned to two
> > different LSPs.  Both
> > > LSPs have "won" the contention.
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
> http://im.yahoo.com

Delivery-date: Tue, 04 Sep 2001 21:28:48 -0700
Date: Tue, 4 Sep 2001 21:26:19 -0700 (PDT)
From: Fong Liaw <[email-masked]>
Subject: Re: Question on GMPLS contentions resolution
To: Guangzhi Li <[email-masked]>, Eric Gray <[email-masked]>
Cc: John Drake <[email-masked]>, [email-masked], [email-masked]

Guangzhi

GMPLS includes SESSION_ATTRIBUTE object,
but the current text on contention resolution
does not take it into account. So I think adding 
(1) as clarification is needed, however, I would 
change (1) to

"(1) Based on the LSPs' hold and setup priority."

I might remove (2) if it is understood that
receiving a Resv means hold priority should be
used in (1).

We already have (3), so that is fine.

-Fong
 
--- Guangzhi Li <[email-masked]> wrote:
> Hi, all:
> 
> I posted the contention resolution question 10 days
> ago. After some fruitful
> discussions with John Drake, Eric Gray, Fong Liaw,
> Hang Liu, I propose the
> following three rules to resolve any contention in
> GMPLS although there is no
> signaling correctness issue. The following rules
> should applied in sequence to
> both bi-directional and uni-directional LSPs:
> 
> (1) Higher priority LSP wins lower priority LSP.
> (2) LSP with Reply (Resv in RSVP) message wins LSP
> with Request
> (Path in RSVP) message.
> (3) LSP with the higher node ID assigning the label
> wins the contention
> if race conditions happen between two LSPs with
> Request messages.
> 
> Since race conditions won't happen between two LSPs
> with Reply messages,
> the above three rules solve all possible contention
> scenarios.
> 
> Proposed modification of the GMPLS functional
> specification, text from
> section 4.2:
>
---------------------------------------------------------------------------
> 
> By allowing bi-directional LSP setup and suggested
> label in the GMPLS
> framework,  contention for labels may occur between
> two bidirectional
> LSP setup requests, or between an uni-directional
> and a bi-directional
> LSP, traveling in opposite directions.  This
> contention occurs when both sides
> allocate the same resources (labels) at effectively
> the same time. If there is no
> restriction on the labels that can be used for
> bidirectional LSPs and if
> there are alternate resources, downstream label
> assignment will apply
> and there is no contention. However, if there is a
> restriction on the
> labels that can be used for the bidirectional LSPs
> (for example, if they
> must be physically coupled on a single I/O card), or
> if there are no
> more resources available, then the contention must
> be resolved by other
> means. Although contention resolution is not a
> mandatory requirement for
> signaling correctness, contention resolution is
> strongly recommended
> for performance optimization. To resolve contention,
> the following three rules
> SHOULD be applied in sequence:
> (1) A higher priority LSP wins over a lower priority
> LSP.
> (2) LSP with a Reply message wins over a LSP with a
> Request
> message.
> (3) LSP with higher node ID assigning the label wins
> the contention if
> race conditions happen between two LSPs with Request
> messages.
> ........
> 
> The rest of the text from this section should be
> updated accordingly.
> 
> Thanks,
> 
> Guangzhi
> 
> 
> >  Dear GMPLS authors and all experts:
> >
> > During GMPLS last call, I posted the same question
> on the mailing list
> > without response. Please somebody spend a little
> time and check with the
> > following example? Something seems not clear when
> the current GMPLS
> > contention resution schemes are applied on a
> framework with both
> > bi-directional and uni-directional LSPs. Your
> clarification is very much
> > appreciated.
> >
> > Sincerely,
> >
> > Guangzhi
> >
> >
>
-------------------------------------------------------------------------------
> >
> > The issue arises because contention is resolved
> between bi-directional
> > LSPs by the node with the higher node index while
> for uni-directional
> > LSPs, contention is resolved by the downstream
> node. Consider the
> > following example of two nodes with paired,
> bi-directional interfaces
> > (i.e., a transmitter/receiver pair of ports). 
> Node 1 with ID=100 and
> > node 2 with ID = 50.  Node 1 uses label 1 for the
> transmitter port and
> > label 2 for the receiver port; node 2 uses label 4
> for the transmitter
> > port and label 3 for the receiver port.   We
> assume that a
> > bi-directional LSP requires a single I/O
> interface.
> >
> > We consider two LSPs - a uni-directional LSP (LSP
> A) and a
> > bi-directional LSP (LSP B). Both LSPs are going
> from node 1
> > to node 2, with the uni-directional LSP setup
> request arriving marginally before
> >
> > the bi-directional LSP.  LSP A does not use a
> suggested label, and thus
> > is assigned a label (port) by node 2.  Label 3 is
> assigned,
> > corresponding to label 1 at node 1.  At the same
> time, for LSP B (the
> > bi-directional LSP) node 1 assigns label 2, with
> suggested label 1.
> > Because node 1 has the higher node ID, node 2 will
> assume (due to the
> > contention resolution rule for bi-directional
> LSPs) that LSP B wins the
> > contention and thus label 3 is assigned to LSP B. 
> Thus label 1 at node
> > 1 (label 3 at node 2) has been assigned to two
> different LSPs.  Both
> > LSPs have "won" the contention.
> 
> 

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Delivery-date: Tue, 04 Sep 2001 18:53:05 -0700
From: "Anantha, Vic" <[email-masked]>
To: [email-masked]
Subject: RE: Question on GMPLS contentions resolution
Date: Tue, 4 Sep 2001 15:47:59 -0700 

Could somebody point me to where I can read up more about the node IDs that
are being mentioned here. Are they IP addresses that are interpreted as 32
bit unsigned integers?

Vik

-----Original Message-----
From: Guangzhi Li [mailto:[email-masked]]
Sent: Monday, August 27, 2001 2:13 PM
To: Fong Liaw
Cc: [email-masked]; [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Fong:

Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both
uni-directional and bi-directional together and uses the same port pool,
then a PATH and a RESV may cross each other. I think that it should be legal
based on current GMPLS specification. IF this scenario happens, GMPLS has to
provide one standard way to handle this situation.

Your suggestion works but it still involves the implementations of node 1
and node 2. Both nodes should interperate the same way. That means RESV
message always wins PATH message. No problem.

I assume that the I/O ports of bi-didrectional LSP are paired together, then
suggested_label = upstream_label and suggested_label is hard binding. Note
that contention happens in either this case or lack of resource. If
suggested_label could be different upstream_label, no contention problem at
all.

-- Guangzhi

Fong Liaw wrote:

> Guangzhi
>
> The GMPLS contention resolution applies to the scenario
> that two Path messages cross each other.  Your example
> have Resv and Path cross each other so the rule in the
> contention resolution does not directly apply and is more
> of a policy and implementation issue.
>
> Here is one possible solution and is within the
> interpretation of the draft, IMHO. here it is.
> If node 2 already sends Resv to node 1, LSP A should
> be considered established and therefore LSP B should
> be rejected by node 2. If node 2 hasn't sent back Resv,
> LSP A is still in establishing mode and node 2 can resolve
> the contention internally by rejecting LSP A or LSP B, based
> on their setting up priority or it can change LSP A's
> label and reprogram the cross-connect without ever noticed
> by any external node.  In both cases, node 2 is the one
> that resolve this contention.  Hope this helps.
>
> p.s. I think you meant to use LABEL_SET since
> Suggested label is a suggestion, not a hard binding.
>
> Regards
> -Fong
>
> >  -----Original Message-----
> >  From: Guangzhi Li [mailto:[email-masked]]
> >  Sent: Monday, August 27, 2001 6:17 AM
> >  To: [email-masked]; [email-masked]
> >  Cc: [email-masked]
> >  Subject: Question on GMPLS contentions resolution
> >
> >
> >  Dear GMPLS authors and all experts:
> >
> >  During GMPLS last call, I posted the same question on the
> >  mailing list
> >  without response. Please somebody spend a little time and
> >  check with the
> >  following example? Something seems not clear when the current GMPLS
> >  contention resution schemes are applied on a framework with both
> >  bi-directional and uni-directional LSPs. Your clarification
> >  is very much
> >  appreciated.
> >
> >  Sincerely,
> >
> >  Guangzhi
> >
> >  -------------------------------------------------------------
> >  -------------------------------------
> >
> >  The issue arises because contention is resolved between
> >  bi-directional
> >  LSPs by the node with the higher node index while for uni-directional
> >  LSPs, contention is resolved by the downstream node. Consider the
> >  following example of two nodes with paired, bi-directional interfaces
> >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> >  node 2 with ID = 50.  Node 1 uses label 1 for the
> >  transmitter port and
> >  label 2 for the receiver port; node 2 uses label 4 for the
> >  transmitter
> >  port and label 3 for the receiver port.   We assume that a
> >  bi-directional LSP requires a single I/O interface.
> >
> >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> >  to node 2,
> >  with the uni-directional LSP setup request arriving marginally before
> >  the bi-directional LSP.  LSP A does not use a suggested
> >  label, and thus
> >  is assigned a label (port) by node 2.  Label 3 is assigned,
> >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> >  Because node 1 has the higher node ID, node 2 will assume (due to the
> >  contention resolution rule for bi-directional LSPs) that LSP
> >  B wins the
> >  contention and thus label 3 is assigned to LSP B.  Thus
> >  label 1 at node
> >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> >  LSPs have "won" the contention.
> >
> >

Delivery-date: Tue, 04 Sep 2001 12:50:30 -0700
From: "S Kalipatnapu" <[email-masked]>
To: "Bart Batsleer WX22 54174" <[email-masked]>, <[email-masked]>
Subject: Re: Questions on OSPF extensions for TE 
Date: Tue, 4 Sep 2001 17:06:21 -0400

Bart,

Section 2.5.5  on Traffic Engineering Metric, states the following:
>
>The Traffic Engineering Metric sub-TLV specifies the link metric for
> traffic engineering purposes. This metric may be different than the
> standard OSPF link metric.
>
The "may be" in the last sentence may be indicating what you are looking
for.

Regards,
--Sitaram

----- Original Message -----
From: "Bart Batsleer WX22 54174" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 04, 2001 11:27 AM
Subject: Questions on OSPF extensions for TE

> Hello,
>
> I have 2 questions related to the draft-katz-yeung-ospf-traffic-05
>
> 1) In case the traffic engineering metric sub-tlv is not present in the
> link
> tlv, does the traffic engineering SPF calculation have to rely on the
> standard OSPF link metric ?
>
> 2) The behaviour is stated in the corresponding isis draft
> (draft-ietf-isis-traffic-02), is there a
> reason why this is not stated in the OSPF draft ?
>
> Thanks in advance,
> Bart
>
>
>

Delivery-date: Tue, 04 Sep 2001 11:59:34 -0700
To: "Atkinson, Stephen" <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-mpls-generalized-signaling-05 Interface Identification 
Date: Tue, 04 Sep 2001 11:56:41 -0700
From: Yakov Rekhter <[email-masked]>

Steve,

> draft-ietf-mpls-generalized-signaling-05 section 9.1 defines a new
> Interface_ID TLV which
> allows for specifying Types of:
> 
>     IPv4
>     IPv6
>     IF_INDEX
>     COMPONENT_IF_DOWNSTREAM
>     COMPONENT_IF_UPSTREAM
> 
> Why the inclusion of Components?
> Shouldn't components be signaled as per draft-kompella-mpls-bundle-05?
> In the presence of bundling is it valid to have an Interface_ID TLV which
> specifies the components? Wouldn't it be redundant?
> 
> Having two ways of signaling the same information may simply create problems
> with interoperability.

Agreed wrt "two ways". And that is why we just submitted a revised version 
of the bundling Internet Draft that uses just IF_ID. 

Yakov.

Delivery-date: Tue, 04 Sep 2001 08:29:26 -0700
Date: Tue, 04 Sep 2001 17:27:42 +0200
From: Bart Batsleer WX22 54174 <[email-masked]>
Organization: Alcatel Telecom - Antwerp - Belgium
To: [email-masked]
Subject: Questions on OSPF extensions for TE 

Hello,

I have 2 questions related to the draft-katz-yeung-ospf-traffic-05

1) In case the traffic engineering metric sub-tlv is not present in the
link
tlv, does the traffic engineering SPF calculation have to rely on the
standard OSPF link metric ?

2) The behaviour is stated in the corresponding isis draft
(draft-ietf-isis-traffic-02), is there a
reason why this is not stated in the OSPF draft ?

Thanks in advance,
Bart

Delivery-date: Tue, 04 Sep 2001 07:47:56 -0700
Date: Tue, 04 Sep 2001 10:51:52 -0400
From: Guangzhi Li <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: John Drake <[email-masked]>, Fong Liaw <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Hi, all:

I posted the contention resolution question 10 days ago. After some fruitful
discussions with John Drake, Eric Gray, Fong Liaw, Hang Liu, I propose the
following three rules to resolve any contention in GMPLS although there is no
signaling correctness issue. The following rules should applied in sequence to
both bi-directional and uni-directional LSPs:

(1) Higher priority LSP wins lower priority LSP.
(2) LSP with Reply (Resv in RSVP) message wins LSP with Request
(Path in RSVP) message.
(3) LSP with the higher node ID assigning the label wins the contention
if race conditions happen between two LSPs with Request messages.

Since race conditions won't happen between two LSPs with Reply messages,
the above three rules solve all possible contention scenarios.

Proposed modification of the GMPLS functional specification, text from
section 4.2:
---------------------------------------------------------------------------

By allowing bi-directional LSP setup and suggested label in the GMPLS
framework,  contention for labels may occur between two bidirectional
LSP setup requests, or between an uni-directional and a bi-directional
LSP, traveling in opposite directions.  This contention occurs when both sides
allocate the same resources (labels) at effectively the same time. If there is no
restriction on the labels that can be used for bidirectional LSPs and if
there are alternate resources, downstream label assignment will apply
and there is no contention. However, if there is a restriction on the
labels that can be used for the bidirectional LSPs (for example, if they
must be physically coupled on a single I/O card), or if there are no
more resources available, then the contention must be resolved by other
means. Although contention resolution is not a mandatory requirement for
signaling correctness, contention resolution is strongly recommended
for performance optimization. To resolve contention, the following three rules
SHOULD be applied in sequence:
(1) A higher priority LSP wins over a lower priority LSP.
(2) LSP with a Reply message wins over a LSP with a Request
message.
(3) LSP with higher node ID assigning the label wins the contention if
race conditions happen between two LSPs with Request messages.
........

The rest of the text from this section should be updated accordingly.

Thanks,

Guangzhi

>  Dear GMPLS authors and all experts:
>
> During GMPLS last call, I posted the same question on the mailing list
> without response. Please somebody spend a little time and check with the
> following example? Something seems not clear when the current GMPLS
> contention resution schemes are applied on a framework with both
> bi-directional and uni-directional LSPs. Your clarification is very much
> appreciated.
>
> Sincerely,
>
> Guangzhi
>
> -------------------------------------------------------------------------------
>
> The issue arises because contention is resolved between bi-directional
> LSPs by the node with the higher node index while for uni-directional
> LSPs, contention is resolved by the downstream node. Consider the
> following example of two nodes with paired, bi-directional interfaces
> (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> node 2 with ID = 50.  Node 1 uses label 1 for the transmitter port and
> label 2 for the receiver port; node 2 uses label 4 for the transmitter
> port and label 3 for the receiver port.   We assume that a
> bi-directional LSP requires a single I/O interface.
>
> We consider two LSPs - a uni-directional LSP (LSP A) and a
> bi-directional LSP (LSP B). Both LSPs are going from node 1
> to node 2, with the uni-directional LSP setup request arriving marginally before
>
> the bi-directional LSP.  LSP A does not use a suggested label, and thus
> is assigned a label (port) by node 2.  Label 3 is assigned,
> corresponding to label 1 at node 1.  At the same time, for LSP B (the
> bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> Because node 1 has the higher node ID, node 2 will assume (due to the
> contention resolution rule for bi-directional LSPs) that LSP B wins the
> contention and thus label 3 is assigned to LSP B.  Thus label 1 at node
> 1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> LSPs have "won" the contention.

Delivery-date: Tue, 04 Sep 2001 05:50:18 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: [email-masked]
Subject: draft-ietf-mpls-generalized-signaling-05 Interface Identification
Date: Tue, 4 Sep 2001 08:48:44 -0400 

draft-ietf-mpls-generalized-signaling-05 section 9.1 defines a new
Interface_ID TLV which
allows for specifying Types of:

    IPv4
    IPv6
    IF_INDEX
    COMPONENT_IF_DOWNSTREAM
    COMPONENT_IF_UPSTREAM

Why the inclusion of Components?
Shouldn't components be signaled as per draft-kompella-mpls-bundle-05?
In the presence of bundling is it valid to have an Interface_ID TLV which
specifies
the components? Wouldn't it be redundant?

Having two ways of signaling the same information may simply create problems
with interoperability.

Thanks,
steve atkinson

Delivery-date: Tue, 04 Sep 2001 05:50:12 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Generalized MPLS, Bundling, and bi-directional LSPs with uni-dire ctional interfaces
Date: Tue, 4 Sep 2001 08:46:12 -0400 

To quote from draft-ietf-mpls-generalized-rsvp-te-04 section  8.1,
"In all cases but bundling [MPLS-BUNDLE] the upstream interface is implied
by the downstream interface.  For bundling, the path sender explicitly
identifies the component interface used in each direction.".

I'm missing something here. This means, in the absence of Bundling, 
interfaces must always be bi-directional if used for setting up
bi-directional LSPs. 

Why is Bundling different in this regard? Is there something specific to
bundling requiring the ability to setup bi-directional LSPs on
uni-directional interfaces, which isn't required in the absence of bundling?

For example Node A and Node B are connected by 4 fibers. Two fibers
on Node A are outgoing and two are incoming. In both cases below we're
setting up a bi-directional LSP.

Case 1: The fibers are bundled as per MPLS-BUNDLE. In this case the 
             component to use in each direction is specified by
DOWNSTREAM_COMPONENT_INTERFACE_ID
             and UPSTREAM_COMPONENT_INTERFACE_ID as per MPLS-BUNDLE.

Case 2: The fibers are not bundled. In this case we can use the Interface_ID
TLV as per section 9.1
             of draft-ietf-mpls-generalized-signaling-05 (Type = 1, 2 or 3)
to specify the downstream fiber
             to use. There is no mechanism for specifying the upstream
fiber. 

Case 2 won't work unless there's an apriori coupling of an incoming and
outgoing fiber. If this is the
case, why is this coupling not used in the presence of bundling?

Thanks,
steve atkinson

Delivery-date: Tue, 04 Sep 2001 05:50:07 -0700
From: "Atkinson, Stephen" <[email-masked]>
To: [email-masked]
Subject: Questions on draft-kompella-mpls-bundle-05
Date: Tue, 4 Sep 2001 08:47:28 -0400 

I've been reading the bundle-05 spec and have a couple questions.

Bundling (section 5.2) requires that the upstream node specify the
component interface used in each direction when setting up bi-directional
LSPs. But only the "Explicit Indication by Component Interface ID"
mechanism of signaling specifies how this is accomplished. 

How can you specify both components using "Explicit Indication
by IP Address"? Are the IP source and destination addresses expected
to be the means of specifying both the  Upstream and Downstream components?

How can you specify both components using "Implicit Indication"? I don't
see a way to make this work.

Is it intended that Explicit Indication by IP Address and Implicit
Indication only setup bi-directional LSPs using bi-directional links?

Thanks,
steve atkinson