Subject: Question the relationship between LMP and IGP
From: "Lu Shen" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 1 Aug 2002 01:04:46 -0700

Is there anyone, who can clarify me out of the following questions:
1. Do we still need hello message to maintain neriborhood messages in IGP
(e.g. extension to OSPF), if we employ LMP to discover the neiboring nodes
and maintain TE link status? If we still need, why?
2. How does the LMP cooperate with routing protocols?

thanks,
lu

Delivery-date: Wed, 31 Jul 2002 06:29:37 -0700
Date: Wed, 31 Jul 2002 09:13:14 -0400
From: Ron Bonica <[email-masked]>
Subject: Administrivia
To: [email-masked]

Folks,

If you spoke at the IETF 54 CCAMP meeting and have not already emailed your
slides to me, please do so now.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================

Delivery-date: Wed, 31 Jul 2002 01:25:26 -0700
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 31 Jul 2002 10:18:42 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: "[email-masked]" <[email-masked]>
Subject: Comments on LMP draft version 04

Hello Jonathan,

We are very disappointed that you have not provided the
clarifications as requested in
- http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html
- http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
nor the method of neighbor discovery as proposed in
- http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html

Please find below comments on the LMP draft, version 04
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-04.txt).
Hopefully clarification can be provided in a next
version.

Best regards,

Greg Bernstein (Ciena Corporation)
Michiel van Everdingen (Lucent Technologies)

General: please clarify what a control channel is. Only when that
is clarified, we can comment on the mandatory need to manage this
control channel (section 3). If a control channel can be many
things, please mention these things so we can comment on these
interpretations one by one.

Some first comments assuming an interpretation that was recently
provided on this list:

A. "control channel on top of a control network"
   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html
   - From section 1: "To enable communication between nodes for
     routing, signaling, and link management, control channels must
     be established between the node pair".
     Please clarify why control channels must be established. The
     control network seems enough to enable communication.
   - From section 2: "...the control channel MUST terminate on
     the same two nodes that the TE link spans"
     What information is terminated at the end of a control channel ?
     ('electrically terminated' as mentioned in the 4th paragraph of
      section 3 does not provide much information).
     Compare e.g. LSP termination (in which an MPLS label is
     terminated/removed), TCP termination (in which the TCP header is
     terminated/removed) and STS-1 termination (in which STS-1 line
     overhead is terminated/removed). What is terminated/removed at
     the end of a control channel ?

B. "a control network is one instantiation of a control channel"
   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00835.html
   How to read sentences (taken from draft-ietf-ccamp-lmp-04.txt)
   like:
   - "Control channel management is used to establish and maintain
      control channels between adjacent nodes."
   - "LMP requires that a pair of nodes have at least one active bi-
      directional control channel between them."
   - "the control channel MUST terminate on the same two nodes that
      the TE link spans"
   when a control network is used to instantiate the "control
   channel" (i.e. try to replace "control channel" with "control
   network" in the indicated sentences) ?

LMP version 4 now includes some neighbor discovery (3rd paragraph
section 3 and start of section 5). A separate draft is provided
to specify discovery in the case of "out-of-band control channels"
  http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
Why separating the "in-band" and the "out-of-band" cases in different
drafts, especially if a method exists that does not make any assumption
on the configuration of the control network ?
  http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00

Section 1, 4th paragraph: "a data-bearing link may be either a
'port' or a 'component link' depending on its multiplexing capability".
The multiplexing capabilities are present at the *end-points* of the
data-bearing link. The data-bearing link itself does not have
multiplexing capabilities. See
  http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00
on how to use alternative terminology (TTP & CTP).

Section 1, 4th paragraph: the "timeslot label" that is needed to
identify a "link resource" is not mentioned anymore in the remainder
of the document.

Section 3.2: what IGP is meant here ? The IGP building the topology
of the "control plane" or the "signaling plane" ? See for definitions
of these terms:
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html

Section 14.8: In case the test message is transmitted over the DCC
"with bit-oriented HDLC framing format", is this by-passing the
DCN ? Please spend more words on how to prevent conflicts (e.g.
using a proprietary PPP protocol id to prevent the test message
to be handled by the normal routing mechanisms of DCN ?)

Delivery-date: Mon, 29 Jul 2002 06:18:30 -0700
Subject: draft-nadeau-ccamp-gmpls-te-mib-01 - A clarification
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 29 Jul 2002 15:10:30 +0200

Hi Thomas,
                          I'm implementing your MIB but there is a thing
related with the gmplsTunnelHopEntry that is not completely clear to me.

Let me ask to you a clarification about that.

Suppose I've two ERO with the following two path A-B-C and D-E.

W.r.t. to the gmplsTunnelHopEntry which is the correct implementation
between the following two. Key (1) is gmplsTunnelHopListIndex while key(2)
is gmplsTunnelHopIndex

1)
key(1)    key(2)    hop
1            1            A
1            2            B
1            3            C
2            1            D
2            2            E

2)
key(1)    key(2)    hop
1            2            A
2            3            B
3            --           C
4            5            D
5            --           E

Thanks in advance for you time.

Best Regards Diego.

----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI

Delivery-date: Wed, 24 Jul 2002 22:38:20 -0700
Date: Thu, 25 Jul 2002 11:45:48 +0800
From: Qiang Liu <[email-masked]>
Subject: LMP Message BeginVerifyAck and Hello
To: [email-masked]
Cc: [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Jonathan,

  In page 40 of draft lmp04,
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                <VERIFY_ID>
Shall we add <REMOTE_LINK_ID> in? That is
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<REMOTE_LINK_ID>
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                <VERIFY_ID>
which is more fit to the discription in page16.

  Also, in Hello message,
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>,
I suppose we shall use REMOTE_CCID replace LOCAL_CCID, that is
<Hello Message> ::= <Common Header> <REMOTE_CCID> <HELLO>
else the receiver node can not identify the "hello" easily.

regard,

LIU, Qiang

--
LIU QIANG  Ph.D
Optical Networking Services Group
Laboratories for Information Technology (LIT)
21 Heng Mui Keng Terrace
Singapore 119613
E-mail: [email-masked]
Tel:    +65 6874 6697 (DID)

Delivery-date: Tue, 23 Jul 2002 03:57:08 -0700
From: Apratim Mukherjee <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Admin Status object and Style object 
Date: Tue, 23 Jul 2002 11:50:44 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi ,

A few questions on the Admin Status object and style of reservation in
Generalized RSVP-TE.
Lets assume that SE style is not required in GMPLS network , and we are
using only FF style .In the FF style , lets say that there are lsps 1 , 2 ,
3 and 4 between an ingress A and an egress B . (Of course this is possible
only if multiple lsps are allowed in an FF style session in Generalized
RSVP-Te but there is no specific mention in the draft that this is
prohibited ).

Now , egress B wants to delete lsp 2 only . It appears that this is not
possible looking at the BNF of the Resv Message where there is one Admin
Status _PER_ Resv Message as opposed to 
One Admin Status per _FLOW_DESC_ which would solve the FF  problem mentioned
above or 
One Admin Status per _FILTER_DESC_ which would solve the problem of
indicating which lsp is going down for both SE and FF . 

Is the assumption that for all Gmpls constructed sessions using RSVP-Te
there will always be a single FF lsp per session and no other combination is
possible , e.g multiple lsps in _ONE_ FF Session or mutiple lsps in one SE
style session ? 

I could find only one thread of some relevance to this discussion in the
archives and so am attaching that with this mail .I would be grateful if
someone could clear up this doubt . 

Thanks
Apratim 

============================================================================
=====================
< Attached mail from archive > 

Re: position of ADMIN_STATUS object in RESV message

----------------------------------------------------------------------------
----

To: "Saha, Sayandeb" <[email-masked]> 
Subject: Re: position of ADMIN_STATUS object in RESV message 
From: Eric Gray <[email-masked]> 
Date: Mon, 19 Nov 2001 10:40:31 -0500 
Cc: "[email-masked]'" <[email-masked]> 
References:
<[email-masked]> 

----------------------------------------------------------------------------
----

Sayan,

    I may be looking at this somewhat simply, but I know of no reason why a
transit node would need to disable an SE LSP because one of the reservations
sharing the LSP at that node sets its admin status to down.  Even in the
case
where the D bit is set, this should have the effect of removing the transit
node
from the particular reservation being torn down, rather than tearing down
all
reservations sharing resources at that transit node.

You wrote:

> Hi,
> Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the
> admin_status as not being a
> part of the <flow descriptor list> in the RESV message.
> This works fine for the FF style of reservation.
> But for the SE style of reservation if just one filter is taken out by
> setting the D bit in admin status,
> all others must go down because the admin_status applies for the entire
RESV
> instead of just the particular
> filter in question.
> Or for that matter if only one filter's state(LSP) is taken
administratively
> down( by setting A bit), it will now apply to all filters
> Is this intended? Or is it the optical world will never do SE style
> reservations? Am I missing something here?
> -Sayan

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 22 Jul 2002 14:25:28 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Martin Dubuc <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Jing Qian <[email-masked]>
Cc: [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 23:24:06 +0200

> Bert,
> 
> As the description of the notification says, the first object 
> (ifIndex) is the interface index of the TE link. This index 
> is an index to the lmpTeLinkTable.

Why do you not spell that out in the description clause, 
I think that will make that much clearer for novice readers

> The second object 
> (lmpDataLinkRemoteIfId) is the remote data link (not TE link) 
> interface identifier. It is the index to the lmpDataLinkTable 
> on the remote node.
> 
> There is no way to figure out TE link index from the remote 
> data link interface identifier OID and vice-versa.
> 
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 3:01 PM
> To: Martin Dubuc; Jing Qian
> Cc: [email-masked]
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> 
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[email-masked]]
> > Sent: maandag 22 juli 2002 18:49
> > To: Wijnen, Bert (Bert); Jing Qian
> > Cc: [email-masked]
> > Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > 
> > 
> > Bert,
> > 
> > For the lmpDataLinkPropertyMismatch notification, the first 
> > object (ifIndex) is the interface index of the TE link and 
> > the lmpDataLinkRemoteIfId is the data link remote interface 
> > identifier. Both objects are required in this notification.
> > 
> Is that not the same ifIndex as the one used to index into this
> table? If so then it is already part of the OID for 
> lmpDataLinkremotedIfId is it not? If not, then you may want to
> make that somewhat clearer... (or is it just me who does not
> see this right away????)
> 
> > For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications, 
> > I could use the lmpTeLinkOperStatus object instead of 
> > ifIndex. For the lmpTeLinkDegraded, ifIndex is good enough, 
> > but for lmpTeLinkNotDegraded, the lmpTeLinkOperStatus would 
> > bring some value. We probably want to have same object for 
> > both notifications. I'll make note of this change for the 
> > next version.
> > 
> Thanks
> 
> Bert
> > Martin
> > 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Monday, July 22, 2002 11:05 AM
> > To: Jing Qian
> > Cc: Martin Dubuc; [email-masked]
> > Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > 
> > 
> > Inline
> > > -----Original Message-----
> > > From: Jing Qian [mailto:[email-masked]]
> > > Sent: maandag 22 juli 2002 16:21
> > > To: Wijnen, Bert (Bert)
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > > 
> > > Did you mean OID is automatically as part of the trap 
> > message payload?
> > 
> > the lmpCcId is the INDEX for these objects itself, so that is
> > why it comes as part of the OID in the varbind for OperStatus and 
> > Adminstatus
> > 
> > > If in this case, why all the other trap still put the OID in 
> > > the OBJECT part?
> > > For example, in draft-ietf-ccamp-lmp-mib-03.txt:
> > >         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> > >            OBJECTS       { ifIndex,
> > >                                          lmpDataLinkRemoteIfId }
> > 
> > In the above case, the ifIndex indeed already is part of theOID
> > for the lmpDataLinkRemoteIfId, and so it is not needed.
> > 
> > >         lmpTeLinkDegraded NOTIFICATION-TYPE
> > >            OBJECTS       { ifIndex }
> > > 
> > In this one, at least some object seems to be needed in order
> > to indicate to the interface that has a problem. But possibly 
> > another object might make more sense.
> > 
> > Authors/WG... what do you think about this?
> > 
> > > Also, why need lmpCcOperStatus for lmpControlChannelUp and
> > > lmpControlChannelDown? The trap message name already define
> > > the lmpCcOperStatus.
> > > 
> > That is a valid question. I think sending the extra OperStatus
> > varbind does not really hurt, but it indeed seems to be
> > implied in the name of the NOTIFICATION
> > 
> > Bert
> > 
> 

Delivery-date: Mon, 22 Jul 2002 14:11:43 -0700
content-class: urn:content-classes:message
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 17:06:22 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Jing Qian" <[email-masked]>
Cc: <[email-masked]>

Bert,

As the description of the notification says, the first object (ifIndex) =
is the interface index of the TE link. This index is an index to the =
lmpTeLinkTable. The second object (lmpDataLinkRemoteIfId) is the remote =
data link (not TE link) interface identifier. It is the index to the =
lmpDataLinkTable on the remote node.

There is no way to figure out TE link index from the remote data link =
interface identifier OID and vice-versa.

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Monday, July 22, 2002 3:01 PM
To: Martin Dubuc; Jing Qian
Cc: [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: maandag 22 juli 2002 18:49
> To: Wijnen, Bert (Bert); Jing Qian
> Cc: [email-masked]
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
>=20
>=20
> Bert,
>=20
> For the lmpDataLinkPropertyMismatch notification, the first=20
> object (ifIndex) is the interface index of the TE link and=20
> the lmpDataLinkRemoteIfId is the data link remote interface=20
> identifier. Both objects are required in this notification.
>=20
Is that not the same ifIndex as the one used to index into this
table? If so then it is already part of the OID for=20
lmpDataLinkremotedIfId is it not? If not, then you may want to
make that somewhat clearer... (or is it just me who does not
see this right away????)

> For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications,=20
> I could use the lmpTeLinkOperStatus object instead of=20
> ifIndex. For the lmpTeLinkDegraded, ifIndex is good enough,=20
> but for lmpTeLinkNotDegraded, the lmpTeLinkOperStatus would=20
> bring some value. We probably want to have same object for=20
> both notifications. I'll make note of this change for the=20
> next version.
>=20
Thanks

Bert
> Martin
>=20
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 11:05 AM
> To: Jing Qian
> Cc: Martin Dubuc; [email-masked]
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
>=20
>=20
> Inline
> > -----Original Message-----
> > From: Jing Qian [mailto:[email-masked]]
> > Sent: maandag 22 juli 2002 16:21
> > To: Wijnen, Bert (Bert)
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> >=20
> > Did you mean OID is automatically as part of the trap=20
> message payload?
>=20
> the lmpCcId is the INDEX for these objects itself, so that is
> why it comes as part of the OID in the varbind for OperStatus and=20
> Adminstatus
>=20
> > If in this case, why all the other trap still put the OID in=20
> > the OBJECT part?
> > For example, in draft-ietf-ccamp-lmp-mib-03.txt:
> >         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex,
> >                                          lmpDataLinkRemoteIfId }
>=20
> In the above case, the ifIndex indeed already is part of theOID
> for the lmpDataLinkRemoteIfId, and so it is not needed.
>=20
> >         lmpTeLinkDegraded NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex }
> >=20
> In this one, at least some object seems to be needed in order
> to indicate to the interface that has a problem. But possibly=20
> another object might make more sense.
>=20
> Authors/WG... what do you think about this?
>=20
> > Also, why need lmpCcOperStatus for lmpControlChannelUp and
> > lmpControlChannelDown? The trap message name already define
> > the lmpCcOperStatus.
> >=20
> That is a valid question. I think sending the extra OperStatus
> varbind does not really hurt, but it indeed seems to be
> implied in the name of the NOTIFICATION
>=20
> Bert
>=20

Delivery-date: Mon, 22 Jul 2002 12:02:24 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Martin Dubuc <[email-masked]>, Jing Qian <[email-masked]>
Cc: [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 21:00:55 +0200

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: maandag 22 juli 2002 18:49
> To: Wijnen, Bert (Bert); Jing Qian
> Cc: [email-masked]
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> Bert,
> 
> For the lmpDataLinkPropertyMismatch notification, the first 
> object (ifIndex) is the interface index of the TE link and 
> the lmpDataLinkRemoteIfId is the data link remote interface 
> identifier. Both objects are required in this notification.
> 
Is that not the same ifIndex as the one used to index into this
table? If so then it is already part of the OID for 
lmpDataLinkremotedIfId is it not? If not, then you may want to
make that somewhat clearer... (or is it just me who does not
see this right away????)

> For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications, 
> I could use the lmpTeLinkOperStatus object instead of 
> ifIndex. For the lmpTeLinkDegraded, ifIndex is good enough, 
> but for lmpTeLinkNotDegraded, the lmpTeLinkOperStatus would 
> bring some value. We probably want to have same object for 
> both notifications. I'll make note of this change for the 
> next version.
> 
Thanks

Bert
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 11:05 AM
> To: Jing Qian
> Cc: Martin Dubuc; [email-masked]
> Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> Inline
> > -----Original Message-----
> > From: Jing Qian [mailto:[email-masked]]
> > Sent: maandag 22 juli 2002 16:21
> > To: Wijnen, Bert (Bert)
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > 
> > Did you mean OID is automatically as part of the trap 
> message payload?
> 
> the lmpCcId is the INDEX for these objects itself, so that is
> why it comes as part of the OID in the varbind for OperStatus and 
> Adminstatus
> 
> > If in this case, why all the other trap still put the OID in 
> > the OBJECT part?
> > For example, in draft-ietf-ccamp-lmp-mib-03.txt:
> >         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex,
> >                                          lmpDataLinkRemoteIfId }
> 
> In the above case, the ifIndex indeed already is part of theOID
> for the lmpDataLinkRemoteIfId, and so it is not needed.
> 
> >         lmpTeLinkDegraded NOTIFICATION-TYPE
> >            OBJECTS       { ifIndex }
> > 
> In this one, at least some object seems to be needed in order
> to indicate to the interface that has a problem. But possibly 
> another object might make more sense.
> 
> Authors/WG... what do you think about this?
> 
> > Also, why need lmpCcOperStatus for lmpControlChannelUp and
> > lmpControlChannelDown? The trap message name already define
> > the lmpCcOperStatus.
> > 
> That is a valid question. I think sending the extra OperStatus
> varbind does not really hurt, but it indeed seems to be
> implied in the name of the NOTIFICATION
> 
> Bert
> 

Delivery-date: Mon, 22 Jul 2002 11:58:59 -0700
Date: Mon, 22 Jul 2002 13:56:25 -0500
From: Jing Qian <[email-masked]>
To: Martin Dubuc <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt

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

I misunderstood the concept of OID for each OBJECT. Thank you all.

Jing

Martin Dubuc wrote:

> Jing,
>
> For the case of lmpControlChannelUp and lmpControlChannelDown, the CCID is part of the lmpCcAdminStatus OID and lmpCcOperStatus OID. So there is no need for a separate object in the notification. However, for the lmpDataLinkPropertyMismatch and lmpTeLinkDegraded notifications, there are no other object that contain the id of the data-bearing link or TE link, so this is why they are defined explicitly in the notification.
>
> The reason we have a lmpControlChannelUp and lmpControlChannelDown instead of just one notification lmpControlChannelChange is to model the control channel status change similar to interface status change as defined in the IF-MIB which has a linkUp and linkDown trap. It could be done either way.
>
> Martin
>
> -----Original Message-----
> From: Jing Qian [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 10:21 AM
> To: Wijnen, Bert (Bert)
> Cc: Martin Dubuc; [email-masked]
> Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
>
> Hi, Bert
>
> Did you mean OID is automatically as part of the trap message payload?
> If in this case, why all the other trap still put the OID in the OBJECT
> part?
> For example, in draft-ietf-ccamp-lmp-mib-03.txt:
>         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>            OBJECTS       { ifIndex,
>                                          lmpDataLinkRemoteIfId }
>         lmpTeLinkDegraded NOTIFICATION-TYPE
>            OBJECTS       { ifIndex }
>
> Also, why need lmpCcOperStatus for lmpControlChannelUp and
> lmpControlChannelDown? The trap message name already define
> the lmpCcOperStatus.
>
> Regards,
>
> Jing
>
> "Wijnen, Bert (Bert)" wrote:
>
> > If you send the AdminStatus and OperStatus, then
> > ythe CcId comes automatically as part of the OID
> > (namely the index part).
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: Jing Qian [mailto:[email-masked]]
> > > Sent: vrijdag 19 juli 2002 17:36
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > >
> > >
> > >
> > > Dear Mr. Dubuc:
> > >
> > > A small question:
> > >
> > > In  draft-ietf-ccamp-lmp-mib-02.txt and
> > > draft-ietf-ccamp-lmp-mib-03.txt,
> > >
> > > lmpControlChannelUp NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > > lmpControlChannelDown NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > >
> > > In draft-ietf-ccamp-lmp-mib-01.txt:
> > > lmpControlChannelUp NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcId }
> > > lmpControlChannelDown NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcId }
> > >
> > > Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
> > > draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
> > > channels in one node, lmpCcId as an OBJECTS makes more sense to me.
> > >
> > > Regards,
> > >
> > > Jing Qian
> > >

--------------DA6A1A66BB9EAD27F7D05F24
Content-Type: text/x-vcard; charset=us-ascii;
 name="jing.qian.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jing Qian
Content-Disposition: attachment;
 filename="jing.qian.vcf"

begin:vcard 
n:Qian ;Jing 
tel;fax:(972)477-8017
tel;work:(972)477-2761
x-mozilla-html:FALSE
org:;Research & Innovation
adr:;;1000 Coit Rd.;Plano;TX;75075;
version:2.1
email;internet:[email-masked]
title:Software Engineer - Core Routing
x-mozilla-cpt:;-13176
fn:Jing Qian
end:vcard

--------------DA6A1A66BB9EAD27F7D05F24--

Delivery-date: Mon, 22 Jul 2002 09:53:55 -0700
content-class: urn:content-classes:message
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 12:48:49 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Jing Qian" <[email-masked]>
Cc: <[email-masked]>

Bert,

For the lmpDataLinkPropertyMismatch notification, the first object =
(ifIndex) is the interface index of the TE link and the =
lmpDataLinkRemoteIfId is the data link remote interface identifier. Both =
objects are required in this notification.

For the lmpTeLinkDegraded/lmpTeLinkNotDegraded notifications, I could =
use the lmpTeLinkOperStatus object instead of ifIndex. For the =
lmpTeLinkDegraded, ifIndex is good enough, but for lmpTeLinkNotDegraded, =
the lmpTeLinkOperStatus would bring some value. We probably want to have =
same object for both notifications. I'll make note of this change for =
the next version.

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Monday, July 22, 2002 11:05 AM
To: Jing Qian
Cc: Martin Dubuc; [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt

Inline
> -----Original Message-----
> From: Jing Qian [mailto:[email-masked]]
> Sent: maandag 22 juli 2002 16:21
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
>=20
> Did you mean OID is automatically as part of the trap message payload?

the lmpCcId is the INDEX for these objects itself, so that is
why it comes as part of the OID in the varbind for OperStatus and=20
Adminstatus

> If in this case, why all the other trap still put the OID in=20
> the OBJECT part?
> For example, in draft-ietf-ccamp-lmp-mib-03.txt:
>         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>            OBJECTS       { ifIndex,
>                                          lmpDataLinkRemoteIfId }

In the above case, the ifIndex indeed already is part of theOID
for the lmpDataLinkRemoteIfId, and so it is not needed.

>         lmpTeLinkDegraded NOTIFICATION-TYPE
>            OBJECTS       { ifIndex }
>=20
In this one, at least some object seems to be needed in order
to indicate to the interface that has a problem. But possibly=20
another object might make more sense.

Authors/WG... what do you think about this?

> Also, why need lmpCcOperStatus for lmpControlChannelUp and
> lmpControlChannelDown? The trap message name already define
> the lmpCcOperStatus.
>=20
That is a valid question. I think sending the extra OperStatus
varbind does not really hurt, but it indeed seems to be
implied in the name of the NOTIFICATION

Bert

Delivery-date: Mon, 22 Jul 2002 08:19:05 -0700
content-class: urn:content-classes:message
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 11:14:51 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Jing Qian" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: <[email-masked]>

Jing,

For the case of lmpControlChannelUp and lmpControlChannelDown, the CCID =
is part of the lmpCcAdminStatus OID and lmpCcOperStatus OID. So there is =
no need for a separate object in the notification. However, for the =
lmpDataLinkPropertyMismatch and lmpTeLinkDegraded notifications, there =
are no other object that contain the id of the data-bearing link or TE =
link, so this is why they are defined explicitly in the notification.

The reason we have a lmpControlChannelUp and lmpControlChannelDown =
instead of just one notification lmpControlChannelChange is to model the =
control channel status change similar to interface status change as =
defined in the IF-MIB which has a linkUp and linkDown trap. It could be =
done either way.

Martin

-----Original Message-----
From: Jing Qian [mailto:[email-masked]]
Sent: Monday, July 22, 2002 10:21 AM
To: Wijnen, Bert (Bert)
Cc: Martin Dubuc; [email-masked]
Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt

Hi, Bert

Did you mean OID is automatically as part of the trap message payload?
If in this case, why all the other trap still put the OID in the OBJECT
part?
For example, in draft-ietf-ccamp-lmp-mib-03.txt:
        lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
           OBJECTS       { ifIndex,
                                         lmpDataLinkRemoteIfId }
        lmpTeLinkDegraded NOTIFICATION-TYPE
           OBJECTS       { ifIndex }

Also, why need lmpCcOperStatus for lmpControlChannelUp and
lmpControlChannelDown? The trap message name already define
the lmpCcOperStatus.

Regards,

Jing

"Wijnen, Bert (Bert)" wrote:

> If you send the AdminStatus and OperStatus, then
> ythe CcId comes automatically as part of the OID
> (namely the index part).
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Jing Qian [mailto:[email-masked]]
> > Sent: vrijdag 19 juli 2002 17:36
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt
> >
> >
> >
> > Dear Mr. Dubuc:
> >
> > A small question:
> >
> > In  draft-ietf-ccamp-lmp-mib-02.txt and
> > draft-ietf-ccamp-lmp-mib-03.txt,
> >
> > lmpControlChannelUp NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > lmpControlChannelDown NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> >
> > In draft-ietf-ccamp-lmp-mib-01.txt:
> > lmpControlChannelUp NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcId }
> > lmpControlChannelDown NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcId }
> >
> > Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
> > draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
> > channels in one node, lmpCcId as an OBJECTS makes more sense to me.
> >
> > Regards,
> >
> > Jing Qian
> >

Delivery-date: Mon, 22 Jul 2002 08:06:42 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Jing Qian <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 17:04:48 +0200

Inline
> -----Original Message-----
> From: Jing Qian [mailto:[email-masked]]
> Sent: maandag 22 juli 2002 16:21
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> Did you mean OID is automatically as part of the trap message payload?

the lmpCcId is the INDEX for these objects itself, so that is
why it comes as part of the OID in the varbind for OperStatus and 
Adminstatus

> If in this case, why all the other trap still put the OID in 
> the OBJECT part?
> For example, in draft-ietf-ccamp-lmp-mib-03.txt:
>         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>            OBJECTS       { ifIndex,
>                                          lmpDataLinkRemoteIfId }

In the above case, the ifIndex indeed already is part of theOID
for the lmpDataLinkRemoteIfId, and so it is not needed.

>         lmpTeLinkDegraded NOTIFICATION-TYPE
>            OBJECTS       { ifIndex }
> 
In this one, at least some object seems to be needed in order
to indicate to the interface that has a problem. But possibly 
another object might make more sense.

Authors/WG... what do you think about this?

> Also, why need lmpCcOperStatus for lmpControlChannelUp and
> lmpControlChannelDown? The trap message name already define
> the lmpCcOperStatus.
> 
That is a valid question. I think sending the extra OperStatus
varbind does not really hurt, but it indeed seems to be
implied in the name of the NOTIFICATION

Bert

Delivery-date: Mon, 22 Jul 2002 07:49:16 -0700
Date: Mon, 22 Jul 2002 10:47:59 -0400
To: Jing Qian <[email-masked]>
From: Baktha Muralidharan <[email-masked]>
Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]

The OID (varbind) arugment serves to identify the object instance.
Thus, the lmpCcOperStatus carries the CC ID (the status
is know from trap type).

Yes, a single trap definition, such as "lmpCCStatusChange"
with lmpCCOperStatus as the varbind would work just as well.

/Baktha

At 09:21 AM 7/22/2002 -0500, Jing Qian wrote:
>Hi, Bert
>
>Did you mean OID is automatically as part of the trap message payload?
>If in this case, why all the other trap still put the OID in the OBJECT
>part?
>For example, in draft-ietf-ccamp-lmp-mib-03.txt:
>         lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>            OBJECTS       { ifIndex,
>                                          lmpDataLinkRemoteIfId }
>         lmpTeLinkDegraded NOTIFICATION-TYPE
>            OBJECTS       { ifIndex }
>
>Also, why need lmpCcOperStatus for lmpControlChannelUp and
>lmpControlChannelDown? The trap message name already define
>the lmpCcOperStatus.
>
>Regards,
>
>Jing
>
>
>"Wijnen, Bert (Bert)" wrote:
>
> > If you send the AdminStatus and OperStatus, then
> > ythe CcId comes automatically as part of the OID
> > (namely the index part).
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: Jing Qian [mailto:[email-masked]]
> > > Sent: vrijdag 19 juli 2002 17:36
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt
> > >
> > >
> > >
> > > Dear Mr. Dubuc:
> > >
> > > A small question:
> > >
> > > In  draft-ietf-ccamp-lmp-mib-02.txt and
> > > draft-ietf-ccamp-lmp-mib-03.txt,
> > >
> > > lmpControlChannelUp NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > > lmpControlChannelDown NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > >
> > > In draft-ietf-ccamp-lmp-mib-01.txt:
> > > lmpControlChannelUp NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcId }
> > > lmpControlChannelDown NOTIFICATION-TYPE
> > >    OBJECTS       { lmpCcId }
> > >
> > > Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
> > > draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
> > > channels in one node, lmpCcId as an OBJECTS makes more sense to me.
> > >
> > > Regards,
> > >
> > > Jing Qian
> > >

Delivery-date: Mon, 22 Jul 2002 07:22:27 -0700
Date: Mon, 22 Jul 2002 09:21:29 -0500
From: Jing Qian <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Question in draft-ietf-ccamp-lmp-mib-03.txt

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

Hi, Bert

Did you mean OID is automatically as part of the trap message payload?
If in this case, why all the other trap still put the OID in the OBJECT
part?
For example, in draft-ietf-ccamp-lmp-mib-03.txt:
        lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
           OBJECTS       { ifIndex,
                                         lmpDataLinkRemoteIfId }
        lmpTeLinkDegraded NOTIFICATION-TYPE
           OBJECTS       { ifIndex }

Also, why need lmpCcOperStatus for lmpControlChannelUp and
lmpControlChannelDown? The trap message name already define
the lmpCcOperStatus.

Regards,

Jing

"Wijnen, Bert (Bert)" wrote:

> If you send the AdminStatus and OperStatus, then
> ythe CcId comes automatically as part of the OID
> (namely the index part).
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Jing Qian [mailto:[email-masked]]
> > Sent: vrijdag 19 juli 2002 17:36
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt
> >
> >
> >
> > Dear Mr. Dubuc:
> >
> > A small question:
> >
> > In  draft-ietf-ccamp-lmp-mib-02.txt and
> > draft-ietf-ccamp-lmp-mib-03.txt,
> >
> > lmpControlChannelUp NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> > lmpControlChannelDown NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> >
> > In draft-ietf-ccamp-lmp-mib-01.txt:
> > lmpControlChannelUp NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcId }
> > lmpControlChannelDown NOTIFICATION-TYPE
> >    OBJECTS       { lmpCcId }
> >
> > Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
> > draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
> > channels in one node, lmpCcId as an OBJECTS makes more sense to me.
> >
> > Regards,
> >
> > Jing Qian
> >

--------------A88A6111D230B3E73548D2D2
Content-Type: text/x-vcard; charset=us-ascii;
 name="jing.qian.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jing Qian
Content-Disposition: attachment;
 filename="jing.qian.vcf"

begin:vcard 
n:Qian ;Jing 
tel;fax:(972)477-8017
tel;work:(972)477-2761
x-mozilla-html:FALSE
org:;Research & Innovation
adr:;;1000 Coit Rd.;Plano;TX;75075;
version:2.1
email;internet:[email-masked]
title:Software Engineer - Core Routing
x-mozilla-cpt:;-13176
fn:Jing Qian
end:vcard

--------------A88A6111D230B3E73548D2D2--

Delivery-date: Mon, 22 Jul 2002 06:28:30 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Jing Qian <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Question in draft-ietf-ccamp-lmp-mib-03.txt
Date: Mon, 22 Jul 2002 15:21:34 +0200

If you send the AdminStatus and OperStatus, then
ythe CcId comes automatically as part of the OID
(namely the index part).

Thanks,
Bert 

> -----Original Message-----
> From: Jing Qian [mailto:[email-masked]]
> Sent: vrijdag 19 juli 2002 17:36
> To: [email-masked]
> Cc: [email-masked]
> Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt
> 
> 
> 
> Dear Mr. Dubuc:
> 
> A small question:
> 
> In  draft-ietf-ccamp-lmp-mib-02.txt and 
> draft-ietf-ccamp-lmp-mib-03.txt,
> 
> lmpControlChannelUp NOTIFICATION-TYPE
>    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> lmpControlChannelDown NOTIFICATION-TYPE
>    OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
> 
> In draft-ietf-ccamp-lmp-mib-01.txt:
> lmpControlChannelUp NOTIFICATION-TYPE
>    OBJECTS       { lmpCcId }
> lmpControlChannelDown NOTIFICATION-TYPE
>    OBJECTS       { lmpCcId }
> 
> Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
> draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
> channels in one node, lmpCcId as an OBJECTS makes more sense to me.
> 
> Regards,
> 
> Jing Qian
> 

Delivery-date: Fri, 19 Jul 2002 11:40:35 -0700
From: Kshitij Kumar <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>
Subject: Why isn't there an LSC in GMPLS?
Date: Fri, 19 Jul 2002 14:37:50 -0400

Folks,

I am curious. Please humour my curiousity.

There are PSCs, L2SCs, etc. in GMPLS. 

Take the case of p2p links, GigE for instance.

A PSC (for instance an IP router capable of MPLS forwarding) needs to look at the MAC address, then look at the label and make a forwarding decision, changing the MAC SA/DA in the process.

An L2SC (for instance an Ethernet switch capable of doing MPLS) checks the MAC destination and presumably make a forwarding decision based on either the MAC or the label. If it is a pure L2SC, I assume it makes the decision based on the label and should not change the MAC SA/DA. Why does an L2SC look at the L2 header? What's the relationship between the L2 header vs. Label for an L2SC? This is never explained in the GMPLS drafts.

And, there is no "Label Switch Capable" (LSC) device that I know of, or is there?

An LSC would be a device that would simply switch based on labels and labels only. It would have interfaces that would be P2P - for instance GE or FE p2p links, and would not spend cycles looking at the L2 header for making forwarding decisions. 

The LSC would be a "real" GMPLS device - one that is "Generalized" not just at the control plane, but also at the data plane. (Of course, one can't generalize the implementation, but you get my point).

It's big advantage could be that it could be transparent to any L2 bridging or L3 routing - it would work purely based on MPLS tunnels. (Will need some routing for GMPLS signaling, but that's it).

Has such a concept been discussed and if so, what happened? If not, why not?

Thanks,

Kshitij.
--
My cure for procrastination: 
"I wasted time, and now doth time waste me."
King Richard-II, Shakespeare.

Delivery-date: Fri, 19 Jul 2002 08:40:25 -0700
Date: Fri, 19 Jul 2002 10:35:32 -0500
From: Jing Qian <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Question in draft-ietf-ccamp-lmp-mib-03.txt

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

Dear Mr. Dubuc:

A small question:

In  draft-ietf-ccamp-lmp-mib-02.txt and draft-ietf-ccamp-lmp-mib-03.txt,

lmpControlChannelUp NOTIFICATION-TYPE
   OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }
lmpControlChannelDown NOTIFICATION-TYPE
   OBJECTS       { lmpCcAdminStatus, lmpCcOperStatus }

In draft-ietf-ccamp-lmp-mib-01.txt:
lmpControlChannelUp NOTIFICATION-TYPE
   OBJECTS       { lmpCcId }
lmpControlChannelDown NOTIFICATION-TYPE
   OBJECTS       { lmpCcId }

Is this a type mistake in draft-ietf-ccamp-lmp-mib-02.txt and
draft-ietf-ccamp-lmp-mib-03.txt? Since there are multiple control
channels in one node, lmpCcId as an OBJECTS makes more sense to me.

Regards,

Jing Qian

--------------2154CE73F8FCD5988C7920BC
Content-Type: text/x-vcard; charset=us-ascii;
 name="jing.qian.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jing Qian
Content-Disposition: attachment;
 filename="jing.qian.vcf"

begin:vcard 
n:Qian ;Jing 
tel;fax:(972)477-8017
tel;work:(972)477-2761
x-mozilla-html:FALSE
org:;Research & Innovation
adr:;;1000 Coit Rd.;Plano;TX;75075;
version:2.1
email;internet:[email-masked]
title:Software Engineer - Core Routing
x-mozilla-cpt:;-13176
fn:Jing Qian
end:vcard

--------------2154CE73F8FCD5988C7920BC--

Delivery-date: Thu, 18 Jul 2002 04:44:54 -0700
Date: Thu, 18 Jul 2002 13:42:17 +0200
From: Loa Andersson <[email-masked]>
To: ccamp <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: info:  cr-ldp discussion to take place on the mpls list

All,

this message is sent to the ccamp, ppvpn and pwe3 wg mailing lists
as information, plese do not reply to the list(s).

At the mpls wg meeting today the issue of having two functionally
similar protocols for te and setting up expicit routes (rsvp-te and
cr-ldp), a discussion were initiated and it was decided that it shall
take place on the mpls wg mailing <mpls@uu-net>.

As separate message will be sent to the mpls list with further
background.

/Loa

-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           [email-masked]
     WWW             www.utfors.se

Delivery-date: Wed, 17 Jul 2002 22:24:50 -0700
From: "Soo-Hyun Choi" <[email-masked]>
To: <[email-masked]>
Subject: Multicast for the CCAMP WG
Date: Thu, 18 Jul 2002 14:23:16 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_00E0_01C22E66.A8328420
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGksIGFsbCwNCg0KSXMgdGhlcmUgYW55Ym9keSB3aG8gaGFkIGEgY2hhbmNlIHRvIGRvd25sb2Fk
IHRoZSBtdWx0aWNhc3QgbXBlZzQgZmlsZSBmb3IgdGhlIDU0dGggY2NhbXAgd2cgbWVldGluZz8N
CkkndmUgZG93bmxvYWRlZCB0aGF0IGZpbGUgdHdvIHRpbWVzIGZyb20gdGhlIElFVEYgcGFnZSwg
YnV0IGZhaWxlZCB0byBwbGF5IHdpdGggUmVhbCBPbmUgUGxheWVyLg0KDQpUbzogV0cgY2hhaXIg
b3IgcmVsYXRlZCBwZXJzb25uZWwsDQpXb3VsZCB5b3UgcGx6IGNoZWNrIGlmIHRoZSBtdWx0aWNh
c3QgZmlsZSBpcyBlcnJvci1mcmVlbHkgdXBsb2FkZWQgYnkgdGhlIFVuaXYuIG9mIE9yZWdvbiBm
b2xrcz8NCg0KQmVzdCwNClNvby1IeXVuIENob2kNCg==

------=_NextPart_000_00E0_01C22E66.A8328420
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_00E0_01C22E66.A8328420--

Delivery-date: Tue, 16 Jul 2002 17:43:23 -0700
From: [email-masked]
Date: Tue, 16 Jul 2002 19:41:23 -0500
Subject: ITU-T SG15 updates to IETF-CCAMP
TO: [email-masked]
CC: [email-masked]

--openmail-part-475a81ff-00000001
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline; filename="BDY.RTF"
	;Creation-Date="Tue, 16 Jul 2002 19:40:11 -0500"
Content-Transfer-Encoding: 8bit

Attached is the ITU-T SG15 updates to CCAMP that was presented in the
CCAMP meeting in Japan.

Thanks.
 
-----------------------------------------------------------------
Wesam Alanqar                         
Member of Technical Staff
ITU-T SG15 representative to IETF-CCAMP
Technology Research Group, Technology Planning & Integration Dept(TP&I) 
6220 Sprint Pkwy- Bldg 4, Overland Park, KS 66251 

Phone: 913-794-2362 Work, Fax: 913-794-0415
MailStop: KSOPHD0404-4D476

-----------------------------------------------------------------

--openmail-part-475a81ff-00000001
Content-Type: application/mspowerpoint
Content-Disposition: attachment; filename="ITU_020714_ccamp.ppt"
	;Creation-Date="Tue, 16 Jul 2002 19:41:18 -0500"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAJAAAAPgIAAAAA
AAAAEAAAVAIAAAEAAAD+////AAAAADkCAAA6AgAAOwIAADwCAAA9AgAAfwIAAP4CAAB8AwAA
AAQAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz/////////vOK83f//vb3/////
//////////////////////////z/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////8///////du9y0tLuub73/////////
///////////////////////8////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////8/////5OS3f//tbu1tLz////////////////////////////////8////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////P////+9/7W7u7y1u////////////////////////////////////Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz////D////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/////////////////////////////P//////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////P////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////z////////////////////////////8////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////8/////////////////////////////P//////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////P////////////////////////////z/////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////z////////////////////////////8////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////8/////////////////////////////P//////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////P////////////////////////////z/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//z////////////////////////////8////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////8
/////////////////////////////P//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////P//
//////////////////////////z/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////z/////
///////////////////////8////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////8////////
/////////////////////P//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////
//////////////////z/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////z/////////////
///////////////8////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////8////////////////
/////////////P//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////P//////////////////
//////////z/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////z/////////////////////
///////8////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////8////////////////////////
/////P//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////P//////////////////////////
//z/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////////////////////////////P//
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////P////////////////////////////z/////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////z////////////////////////////8////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////P////////////////////////////z/////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////z////////////////////////////8////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////8/////////////////////////////P//////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////P////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////z////////////////////////////8////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////8/////////////////////////////P//////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////P////////////////////////////z/////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////z////////////////////////////8////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////8/////////////////////////////P//////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////P////////////////////////////z/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//z////////////////////////////8////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////8
/////////////////////////////P//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////P//
//////////////////////////z/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////z/////
///////////////////////8////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////8////////
/////////////////////P//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////
//////////////////z/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////z/////////////
///////////////8////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////P////////////////////////////z/////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////z////////////////////////////8////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////////////////////////////P//
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////P////////////////////////////z/////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////z////////////////////////////8////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////P////////////////////////////z/////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////z////////////////////////////8////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////8/////////////////////////////P//////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////P////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////z////////////////////////////8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAA

--openmail-part-475a81ff-00000001--

Delivery-date: Tue, 16 Jul 2002 09:07:28 -0700
Date: Wed, 17 Jul 2002 01:02:18 +0900
To: "David Allan" <[email-masked]>
From: Atsushi Iwata <[email-masked]>
Subject: re: crankback draft, was  54th IETF Meeting - Common Control and Measurement Plane  (ccamp)
Cc: Kireeti Kompella <[email-masked]>, Ron Bonica <[email-masked]>, [email-masked]

David,

At 01:14 02/07/16 -0400, David Allan wrote:

>I'd like to suggest that this be harmonized with the feedback draft that 
is already an MPLS WG draft. Solution addresses a common space so why have 
two very similar solutions?

Thank you for your comments. We also think that our draft should be 
harmonized with the feedback draft (only specifies CR-LDP extensions, 
though), if possible. Our draft covers both CR-LDP and RSVP-TE, and also 
could be a basis to support GMPLS-ASON requirement.

Thank you.

----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Principal Researcher
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     [email-masked]
NEC-internal E-mail: [email-masked]
NEC-internal Home Page: http://www.nwk.cl.nec.co.jp/~iwata/index.html

Delivery-date: Mon, 15 Jul 2002 22:16:27 -0700
From: "David Allan" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, Atsushi Iwata <[email-masked]>
Cc: Ron Bonica <[email-masked]>, [email-masked]
Subject: re: crankback draft, was  54th IETF Meeting - Common Control and  Measurement Plane  (ccamp)
Date: Tue, 16 Jul 2002 01:14:54 -0400

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

------_=_NextPart_001_01C22C87.B863F6A2
Content-Type: text/plain;
	charset="iso-8859-1"

I'd like to suggest that this be harmonized with the feedback draft that is
already an MPLS WG draft. Solution addresses a common space so why have two
very similar solutions?

cheers
Dave 

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, July 15, 2002 10:35 PM
> To: Atsushi Iwata
> Cc: Ron Bonica; [email-masked]
> Subject: Re: 54th IETF Meeting - Common Control and Measurement Plane
> (ccamp)
> 
> 
> Hi Atsushi,
> 
> On Mon, 15 Jul 2002, Atsushi Iwata wrote:
> 
> > Kireeti and Ron,
> >
> > I requested the slot for presentation of our draft.
> >
> > Could you give me a 5 minute slot for this presentation?
> 
> I read the draft, and don't see much new in it.  So, instead of
> presenting it again, I would suggest that we start/continue a
> discussion on the mailing list.
> 
> So, here goes.  Folks that think that this work is interesting
> (especially non-authors) please respond.
> 
> First off, I think this is useful work (I didn't need to be hit
> over the head with "Crankback has been identified by the ITU-T as
> requirement" -- although that is good to know).
> 
> My question is, do we need a 32 page draft with quite so many
> extensions to get there?
> 
> As the draft itself says, "full crankback information should
> indicate the node, link and other resources which have been
> attempted but have failed".  The current notify message has some,
> but not all, of this information.  It seems to me that starting
> with new error codes, and an indication of where the error was
> would be sufficient (for now).
> 
> Can we apply Occam's Razor, please?  (It's generally a good idea.)
> If the extensions *are* needed, can we have justifications?
> 
> Thanks,
> Kireeti.
> 
> 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>re: crankback draft, was  54th IETF Meeting - Common Control and =
Measurement Plane  (ccamp)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'd like to suggest that this be harmonized with the =
feedback draft that is already an MPLS WG draft. Solution addresses a =
common space so why have two very similar solutions?</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, July 15, 2002 10:35 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Atsushi Iwata</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Ron Bonica; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: 54th IETF Meeting - Common Control =
and Measurement Plane</FONT>
<BR><FONT SIZE=3D2>&gt; (ccamp)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Atsushi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Mon, 15 Jul 2002, Atsushi Iwata =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Kireeti and Ron,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I requested the slot for presentation of =
our draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Could you give me a 5 minute slot for this =
presentation?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I read the draft, and don't see much new in =
it.&nbsp; So, instead of</FONT>
<BR><FONT SIZE=3D2>&gt; presenting it again, I would suggest that we =
start/continue a</FONT>
<BR><FONT SIZE=3D2>&gt; discussion on the mailing list.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, here goes.&nbsp; Folks that think that this =
work is interesting</FONT>
<BR><FONT SIZE=3D2>&gt; (especially non-authors) please respond.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First off, I think this is useful work (I =
didn't need to be hit</FONT>
<BR><FONT SIZE=3D2>&gt; over the head with &quot;Crankback has been =
identified by the ITU-T as</FONT>
<BR><FONT SIZE=3D2>&gt; requirement&quot; -- although that is good to =
know).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My question is, do we need a 32 page draft with =
quite so many</FONT>
<BR><FONT SIZE=3D2>&gt; extensions to get there?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As the draft itself says, &quot;full crankback =
information should</FONT>
<BR><FONT SIZE=3D2>&gt; indicate the node, link and other resources =
which have been</FONT>
<BR><FONT SIZE=3D2>&gt; attempted but have failed&quot;.&nbsp; The =
current notify message has some,</FONT>
<BR><FONT SIZE=3D2>&gt; but not all, of this information.&nbsp; It =
seems to me that starting</FONT>
<BR><FONT SIZE=3D2>&gt; with new error codes, and an indication of =
where the error was</FONT>
<BR><FONT SIZE=3D2>&gt; would be sufficient (for now).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Can we apply Occam's Razor, please?&nbsp; (It's =
generally a good idea.)</FONT>
<BR><FONT SIZE=3D2>&gt; If the extensions *are* needed, can we have =
justifications?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Kireeti.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C22C87.B863F6A2--

Delivery-date: Mon, 15 Jul 2002 21:13:13 -0700
Date: Tue, 16 Jul 2002 12:36:13 +0900
To: <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: 54th IETF Meeting - Common Control and Measurement Plane  (ccamp)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi, Ron Kiretti, and all

   I also have similar problem with Atsushi-san.
   Could you spare me time slot for following agenda along with Atsushi?
   I required time slot in June 28th with attached e-mail.
   Could you mind if rearranging CCAMP Agenda, again?
   I made significant change in my draft.

Sincearly,
W. Imajuku
---------------------------------------------------
Dear Dr. Kompella and Dr. Gill

  Attached please find a refined draft named
"draft-imajuku-ml-routing-02.txt"
  I'm happy if you consider this material as the one of agenda
in CCAMP WG of IETF 54th meeting.
  I already sent this draft to [email-masked].

Best Regards,
W. Imajuku

----------------------------------------------------
Title: Multilayer routing using multilayer switch capable LSRs
File:  draft-imajuku-ml-routing-02.txt

Abstract
    The integration of multilayer switching capabilities within one
    box, such as the packet-switch capability (PSC) and the lambda-
    switch capability (LSC) under the MPLS/Generalized-MPLS control
    mechanism, paves the way for achieving network resource optimization
    considering multilayer routing. This document clarifies the model of
    the GMPLS-controlled integrated PSC/LSC label switch router (LSR)
    and discusses the requirements of the routing extensions needed to
    achieve optimized multilayer traffic engineering.

---------------------------------------------
Wataru Imajuku
Research Engineer@NTT Network Innovation Labs.
807A, 1-1 Hikari-no-oka, Yokosuka, Kanagawa, Japan
Zip: 239-0847
E-mail: [email-masked]
TEL: +81-468-59-4315
FAX: +81-468-59-3396 

Envelope-to: [email-masked]
Delivery-date: Mon, 15 Jul 2002 19:55:57 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Atsushi Iwata" <[email-masked]>
Cc: "Ron Bonica" <[email-masked]>, <[email-masked]>
Subject: Re: 54th IETF Meeting - Common Control and Measurement Plane  (ccamp)
Date: Mon, 15 Jul 2002 22:55:09 -0400

> I read the draft, and don't see much new in it.  So, instead of
> presenting it again, I would suggest that we start/continue a
> discussion on the mailing list.

Well, I'm sure Atsushi didn't plan to present it :-)
If there is time in the agenda (ho, ho) and interest from the crowd, then 'm
sure kick-starting the discussion in Yokohama would be no bad thing.

> So, here goes.  Folks that think that this work is interesting
> (especially non-authors) please respond.

Sorry, I'm an author.

> First off, I think this is useful work (I didn't need to be hit
> over the head with "Crankback has been identified by the ITU-T as
> requirement" -- although that is good to know).
>
> My question is, do we need a 32 page draft with quite so many
> extensions to get there?

Good question.
The history of this draft includes much debate about whether/why we need
crankback.  This has lengthened the draft with explanations.  Ideally these
would be removed into another draft or completely if the question has been put
to bed.

> As the draft itself says, "full crankback information should
> indicate the node, link and other resources which have been
> attempted but have failed".  The current notify message has some,
> but not all, of this information.  It seems to me that starting
> with new error codes, and an indication of where the error was
> would be sufficient (for now).
>
> Can we apply Occam's Razor, please?  (It's generally a good idea.)
> If the extensions *are* needed, can we have justifications?

So there are three distinct features:
- requesting crankback information
- supplying crankback information
- controlling the use of crankback information

[The fourth point - using crankback information - may be discussed but doesn't
need protocol changes]

The bulk of the draft is (as you suggest) devoted to supplying crankback
information.  There is a lot of commonality with the extended (c-type 3) Error
Spec.  Perhaps a happier solution would be to look at the TLVs for that Error
Spec and see which others are needed/useful for crankback.

Questions I have are
- is this going the right way with regard to requesting/controlling crankback?
- is it valuable to have a protocol agnostic TLV-based solution?

Cheers,
Adrian

Delivery-date: Mon, 15 Jul 2002 19:37:19 -0700
Date: Mon, 15 Jul 2002 19:34:54 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Atsushi Iwata <[email-masked]>
cc: Ron Bonica <[email-masked]>, <[email-masked]>
Subject: Re: 54th IETF Meeting - Common Control and Measurement Plane  (ccamp)

Hi Atsushi,

On Mon, 15 Jul 2002, Atsushi Iwata wrote:

> Kireeti and Ron,
>
> I requested the slot for presentation of our draft.
>
> Could you give me a 5 minute slot for this presentation?

I read the draft, and don't see much new in it.  So, instead of
presenting it again, I would suggest that we start/continue a
discussion on the mailing list.

So, here goes.  Folks that think that this work is interesting
(especially non-authors) please respond.

First off, I think this is useful work (I didn't need to be hit
over the head with "Crankback has been identified by the ITU-T as
requirement" -- although that is good to know).

My question is, do we need a 32 page draft with quite so many
extensions to get there?

As the draft itself says, "full crankback information should
indicate the node, link and other resources which have been
attempted but have failed".  The current notify message has some,
but not all, of this information.  It seems to me that starting
with new error codes, and an indication of where the error was
would be sufficient (for now).

Can we apply Occam's Razor, please?  (It's generally a good idea.)
If the extensions *are* needed, can we have justifications?

Thanks,
Kireeti.

Delivery-date: Sun, 14 Jul 2002 22:17:28 -0700
Date: Mon, 15 Jul 2002 14:14:56 +0900
To: Ron Bonica <[email-masked]>
From: Atsushi Iwata <[email-masked]>
Subject: Re: 54th IETF Meeting - Common Control and Measurement Plane (ccamp)
Cc: [email-masked], Kireeti Kompella <[email-masked]>

Kireeti and Ron,

I requested the slot for presentation of our draft.

Could you give me a 5 minute slot for this presentation?

Thank you.

--
Title: Crankback Routing Extensions for MPLS Signaling

File-name: draft-iwata-mpls-crankback-04.txt

Authors: Atsushi Iwata, Norihito Fujita, Gerald R. Ash, Adrian Farrel, and 
Simon Marshall-Unitt

Abstract:
   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, 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.
   Crankback has been identified by the ITU-T as requirement
   for the Automatically Switched Optical Network (ASON) and
   should be added to the GMPLS signaling protocols to meet
   this requirement.

------ 

At 21:59 02/07/14 -0400, Ron Bonica wrote:
>> 
>> 
>> Common Control and Measurement Plane WG (ccamp)
>> 
>> Wednesday, July 17 at 0900- 1130
>> ==============================
>> 
>> CHAIRS:  Kireeti Kompella <[email-masked]>
>>          Ron Bonica <[email-masked]>
>> 
>> 
>> 
>> AGENDA:
>> 
>> 9:00-9:05         Agenda Bashing
>> 9:05-9:15         WG Status 
>>                    (Kompella)
>> 9:15-9:25         ITU-T SG 15 
>>                      (Wesam Alanqar)
>> 9:25-10:15        draft-ietf-ccamp-gmpls-architecture-03  
>>                   draft-ietf-ccamp-gmpls-g709-01 
>>                   draft-gasparini-ccamp-gmpls-g709-ospf-isis-03 
>>                   draft-ietf-ccamp-gmpls-sonet-sdh-05
>>                   draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-01 
>>                   draft-mannie-ccamp-gmpls-lbm-tdm-03  
>>                   draft-mannie-gmpls-recovery-terminology-01  
>>                   draft-papadimitriou-ccamp-gmpls-recovery-analysis-01 
>>                     (Papadimitriou)
>> 10:05-10:10       draft-aboulmagd-crldp-ext-ason-00 
>>                     (Aboul-Magd)
>> 10:15-10:25       draft-lee-ccamp-rsvp-te-exclude-route-00 
>>                     (Lee)
>> 10:25-10:30       draft-vasseur-mpls-path-computation-rsvp-te-3 
>>                   draft-vasseur-mpls-ospf-pcsd-discovery-00.txt 
>>                     (Vasseur)
>> 10:30-10:45       draft-maeno-ospf-optical-subnet-00 
>>                   draft-yagyu-gmpls-shared-restoration-routing-00
>>                   draft-suemura-protection-hierarchy-00
>>                     (Yagyu)
>> 
>> 10:45-10:50       draft-rabbat-fault-notification-protocol-00 
>>                     (Rabbat)
>> 10:50-10:55       draft-lin-ccamp-gmpls-ason-rsvpte-00 
>>                     (???)
>> 10:55-11:00       draft-shiomoto-multiarea-te-01 
>>                     (shimoto)
>> 11:00-11:05       draft-oki-ccamp-upstream-labelset-00 
>>                     (Oki)
>> 11:05-11:10       draft-many-ccamp-gmpls-nsid-00
>>                     (Kim)
>> 11:10-11:20		draft-ietf-ccamp-gmpls-te-mib-00 
>>                   draft-ietf-ccamp-gmpls-tc-mib-00 
>>                     (Harrison)	
>> 11:20-11:30		draft-vigoureux-ccamp-gmpls-architecture-hpn-00 
>>                   draft-papadimitriou-ccamp-lmp-ls-applicability-00 
>>                     (Papadimitriou)
>> 
>
----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Principal Researcher
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     [email-masked]
NEC-internal E-mail: [email-masked]
NEC-internal Home Page: http://www.nwk.cl.nec.co.jp/~iwata/index.html

Delivery-date: Sun, 14 Jul 2002 19:12:40 -0700
Date: Sun, 14 Jul 2002 21:59:02 -0400
From: Ron Bonica <[email-masked]>
Subject: 54th IETF Meeting - Common Control and Measurement Plane (ccamp)
To: [email-masked]

> 
> 
> Common Control and Measurement Plane WG (ccamp)
> 
> Wednesday, July 17 at 0900- 1130
> ==============================
> 
> CHAIRS:  Kireeti Kompella <[email-masked]>
>          Ron Bonica <[email-masked]>
> 
> 
> 
> AGENDA:
> 
> 9:00-9:05         Agenda Bashing
> 9:05-9:15         WG Status 
>                    (Kompella)
> 9:15-9:25         ITU-T SG 15 
>                      (Wesam Alanqar)
> 9:25-10:15        draft-ietf-ccamp-gmpls-architecture-03  
>                   draft-ietf-ccamp-gmpls-g709-01 
>                   draft-gasparini-ccamp-gmpls-g709-ospf-isis-03 
>                   draft-ietf-ccamp-gmpls-sonet-sdh-05
>                   draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-01 
>                   draft-mannie-ccamp-gmpls-lbm-tdm-03  
>                   draft-mannie-gmpls-recovery-terminology-01  
>                   draft-papadimitriou-ccamp-gmpls-recovery-analysis-01 
>                     (Papadimitriou)
> 10:05-10:10       draft-aboulmagd-crldp-ext-ason-00 
>                     (Aboul-Magd)
> 10:15-10:25       draft-lee-ccamp-rsvp-te-exclude-route-00 
>                     (Lee)
> 10:25-10:30       draft-vasseur-mpls-path-computation-rsvp-te-3 
>                   draft-vasseur-mpls-ospf-pcsd-discovery-00.txt 
>                     (Vasseur)
> 10:30-10:45       draft-maeno-ospf-optical-subnet-00 
>                   draft-yagyu-gmpls-shared-restoration-routing-00
>                   draft-suemura-protection-hierarchy-00
>                     (Yagyu)
> 
> 10:45-10:50       draft-rabbat-fault-notification-protocol-00 
>                     (Rabbat)
> 10:50-10:55       draft-lin-ccamp-gmpls-ason-rsvpte-00 
>                     (???)
> 10:55-11:00       draft-shiomoto-multiarea-te-01 
>                     (shimoto)
> 11:00-11:05       draft-oki-ccamp-upstream-labelset-00 
>                     (Oki)
> 11:05-11:10       draft-many-ccamp-gmpls-nsid-00
>                     (Kim)
> 11:10-11:20		draft-ietf-ccamp-gmpls-te-mib-00 
>                   draft-ietf-ccamp-gmpls-tc-mib-00 
>                     (Harrison)	
> 11:20-11:30		draft-vigoureux-ccamp-gmpls-architecture-hpn-00 
>                   draft-papadimitriou-ccamp-lmp-ls-applicability-00 
>                     (Papadimitriou)
> 

Delivery-date: Thu, 11 Jul 2002 08:07:12 -0700
From: "Naidu, Venkata" <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-04.txt
Date: Thu, 11 Jul 2002 11:04:03 -0400

Jonathan,

  A quick note, section 9 in the new LMP draft still 
  has traces of IP instead of UDP.

--
Venkata.

-> A New Internet-Draft is available from the on-line 
-> Internet-Drafts directories.
-> This draft is a work item of the Common Control and 
-> Measurement Plane Working Group of the IETF.
-> 
-> 	Title		: Link Management Protocol (LMP)
-> 	Author(s)	: J. Lang
-> 	Filename	: draft-ietf-ccamp-lmp-04.txt
-> 	Pages		: 65
-> 	Date		: 02-Jul-02

Delivery-date: Tue, 09 Jul 2002 13:41:16 -0700
Date: Tue, 09 Jul 2002 22:35:44 +0200
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: draft-vasseur-mpls-computation-rsvp-03.txt

Hi,

The rev -03 of draft-vasseur-mpls-computation-rsvp has been posted and 
includes various enhancements.
The draft has been first presented at IETF-52 (Dec 2001) and is getting 
quite mature now.
As a reminder, this Path Computation Server - Path Computation Client 
signalling protocol based on RSVP TE extensions can be used in several 
contexts:
	- Inter-area TE (scenario 2, 4 and 5 of 
draft-kompella-mpls-multiarea-te-03.txt)
	- MPLS Traffic Engineering Fast reroute: backup tunnel path computation 
for bandwidth protection (draft-vasseur-mpls-back-computation-00.txt)
	- GMPLS
	- off-line TE LSP path computation (primary TE LSP placement)
	- ...

Path Computation Server vendors expressed an interest in this draft.

Any feed-backs on this draft is very welcome !

JP.

Delivery-date: Thu, 04 Jul 2002 05:54:26 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Doubt regarding label set
Date: Thu, 4 Jul 2002 18:23:41 +1000
Organization: wipro technologies

This is a multi-part message in MIME format.

------=_NextPartTM-000-995b3687-8d9e-11d6-ba7c-006067005148
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0198_01C22387.ECBA88C0"

------=_NextPart_000_0198_01C22387.ECBA88C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In draft-ietf-mpls-generalized-signaling-08.txt

5.1. Required Information

   A label set is composed of one or more Label_Set objects/TLVs.  Each
   object/TLV contains one or more elements of the Label Set.  Each
   element is referred to as a subchannel identifier and has the same
   format as a generalized label.

  Is subchannel specified in the Label_Set objects/TLVs is of type =
generalized label

TLV ??

If its not an object/TLV then in case of a sonet/SDH label request with =
label set Object/TLV containing list of discrete concatenated label, it =
is not possible to interpret the Label Set Object/TLV ??

Please do correct me if i have misinterpreted things over here ..

thanks

venkat=20

Wipro Technologies, Bangalore

*************************************************************************=
*********************
It is one of the blessings of  friends that you can afford to be stupid =
with them.
 ----- Ralph Waldo Emerson.

------=_NextPart_000_0198_01C22387.ECBA88C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT size=3D2><FONT size=3D2>
<P align=3Djustify><FONT face=3DArial>In=20
draft-ietf-mpls-generalized-signaling-08.txt</FONT></P>
<P align=3Djustify><FONT face=3DArial>5.1. Required =
Information<BR><BR>&nbsp;&nbsp;=20
A label set is composed of one or more Label_Set objects/TLVs.&nbsp;=20
Each<BR>&nbsp;&nbsp; object/TLV contains one or more elements of the =
Label=20
Set.&nbsp; Each<BR>&nbsp;&nbsp; element is referred to as a subchannel=20
identifier and has the same<BR>&nbsp;&nbsp; format as a generalized=20
label.</FONT></P>
<P align=3Djustify><FONT face=3DArial>&nbsp; Is subchannel specified in =
the=20
Label_Set objects/TLVs is of type generalized label</FONT></P>
<P align=3Djustify><FONT face=3DArial>TLV ??</FONT></P>
<P align=3Djustify><FONT face=3DArial>If its not an object/TLV then in =
case of a=20
sonet/SDH label request with label set Object/TLV containing list of =
discrete=20
concatenated label, it is not possible to interpret the Label Set =
Object/TLV=20
??</FONT></P>
<P align=3Djustify><FONT face=3DArial>Please do correct me if i have =
misinterpreted=20
things over here ..</FONT></P>
<P align=3Djustify><FONT face=3DArial>thanks</FONT></P>
<P align=3Djustify><FONT face=3DArial>venkat </FONT></P>
<P align=3Djustify><FONT face=3DArial>Wipro Technologies, =
Bangalore</FONT></P><FONT=20
face=3DArial>
<P align=3Djustify><BR></P></FONT></FONT></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>****************************************************************=
******************************<BR>It=20
is one of the blessings of&nbsp; friends that you can afford to be =
stupid with=20
them.<BR>&nbsp;----- Ralph Waldo Emerson.<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0198_01C22387.ECBA88C0--

------=_NextPartTM-000-995b3687-8d9e-11d6-ba7c-006067005148--

Delivery-date: Wed, 03 Jul 2002 03:30:44 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-03.txt
Date: Wed, 03 Jul 2002 06:27:16 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol Management Information Base
	Author(s)	: M. Dubuc et al.
	Filename	: draft-ietf-ccamp-lmp-mib-03.txt
	Pages		: 82
	Date		: 02-Jul-02
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling the Link
Management Protocol (LMP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-03.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-lmp-mib-03.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-lmp-mib-03.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-lmp-mib-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-mib-03.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, 03 Jul 2002 03:30:38 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-00.txt
Date: Wed, 03 Jul 2002 06:27:21 -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		: Recovery (Protection and Restoration) Terminology for 
                          GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-00.txt
	Pages		: 15
	Date		: 02-Jul-02
	
This document defines a common terminology for GMPLS based recovery
mechanisms (i.e. protection and restoration) that are under
consideration by the CCAMP Working Group.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-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, 03 Jul 2002 03:30:32 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-04.txt
Date: Wed, 03 Jul 2002 06:27:11 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-04.txt
	Pages		: 65
	Date		: 02-Jul-02
	
Optical networks are being developed to include photonic switches, 
optical crossconnects, and routers that are configured with control 
channels and data links. Furthermore, multiple data links may be 
combined to form a single traffic engineering (TE) link for routing 
purposes. This draft specifies a link management protocol (LMP) that 
runs between neighboring nodes and is used to manage TE links. 
Specifically, LMP will be used to maintain control channel 
connectivity, verify the physical connectivity of the data-bearing 
channels, correlate the link property information, suppress 
downstream alarms, and localize link failures for 
protection/restoration purposes in both opaque and transparent 
networks.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 02 Jul 2002 23:48:00 -0700
Date: Wed, 03 Jul 2002 11:25:24 +0900
To: [email-masked]
From: Wataru Imajuku <[email-masked]>
Subject: Re:  I-D ACTION:draft-imajuku-ml-routing-02.txt

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi, all.

  We have updated our routing draft attached below.
  We've recognized that interface switching capability descriptor (ISCD) 
being defined in routing protocols
lacks functionality in order to properly operate multilayer LSRs with 
LSC+PSC, LSC+DXC+PSC, and so on.
  So, we want to add definition of new interface descriptor called 
"interface adaptation capability descriptor".

  Background and aim of this proposal is to realize of multilayer routing 
domain which tunnels any kind of LSPs using the multilayer LSR.
  However, the proposed ISCD in this stage cannot properly express the LSP 
termination capability
in each multilayer LSR.
  I think this problems is very common especially in circuit switch capable 
such as LSC and DXC.
  In some case, these switches can have different capability between LSP 
forwarding capability and termination
capability. We already encountered this kind of problems in routing 
calculation of O-LSP.
  For example, a PXC-LSR can provide forwarding capability for any kind of 
O-LSPs, but termination capability
depends on the adaptation functionality attached to the PXC. But, the ISCD 
cannot effectively express such constraints for routing calculation.

  I'm happy and appreciate if we could share the problems I mentioned, and 
if you would support our proposal.
  I'm very much looking forward to see you at Yokohama, Japan !

Best Regards,
W. Imajuku@NTT

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : Multilayer routing using multilayer switch capable
>                           LSRs
>         Author(s)       : W. Imajuku et al.
>         Filename        : draft-imajuku-ml-routing-02.txt
>         Pages           : 17
>         Date            : 01-Jul-02
>
>The integration of multilayer switching capabilities within one
>box, such as the packet-switch capability (PSC) and the lambda-
>switch capability (LSC) under the MPLS/Generalized-MPLS control
>mechanism, paves the way for achieving network resource optimization
>considering multilayer routing. This document clarifies the model of
>the GMPLS-controlled integrated PSC/LSC label switch router (LSR)
>and discusses the requirements of the routing extensions needed to
>achieve optimized multilayer traffic engineering.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-imajuku-ml-routing-02.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-imajuku-ml-routing-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-imajuku-ml-routing-02.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-imajuku-ml-routing-02.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-imajuku-ml-routing-02.txt>

---------------------------------------------
Wataru Imajuku
Research Engineer@NTT Network Innovation Labs.
807A, 1-1 Hikari-no-oka, Yokosuka, Kanagawa, Japan
Zip: 239-0847
E-mail: [email-masked]
TEL: +81-468-59-4315
FAX: +81-468-59-3396 

Delivery-date: Tue, 02 Jul 2002 15:30:50 -0700
Date: Wed, 03 Jul 2002 07:28:59 +0900
From: Kohei Shiomoto <[email-masked]>
To: [email-masked]
Subject: Multi-layer path control

Hi folks,

I feel that GMPLS opens a new direction for multi-layer path network control and the topic should be addressed in the CCAMP. Traffic engineering in multi-layer networks is a promising application. I posted the following I-D on traffic engineering in multi-layer networks. Comments and feedbacks are highly appreciated.

Kind regards
---
Kohei Shiomoto
NTT Network Innovation Laboratories
----------------------------------

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

	Title		: Multi-area multi-layer traffic engineering using 
                          hierarchical LSPs in GMPLS networks
	Author(s)	: K. Shiomoto et al.
	Filename	: draft-shiomoto-ccamp-multiarea-te-01.txt
	Pages		: 10
	Date		: 25-Jun-02
	
This draft proposes a traffic engineering framework for multi-layer path
networks using dynamic virtual topology configuration capability of
GMPLS protocols.  The electrical label switched path is routed over the
virtual topology built on a set of optical label switched path in multi-
layer path networks.  The virtual topology is dynamically altered by
setting up or tearing down optical label switched paths.  Virtual topol-
ogy is configured in response to traffic demand change so that conges-
tion of the network is mitigated.  Utilization of label switched path is
measured at ingress node and disseminated with routing protocol
extensions for the individual node to decide whether the virtual topol-
ogy should be altered or not without centralized coordination.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-multiarea-te-01.txt

Delivery-date: Tue, 02 Jul 2002 03:38:57 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-imajuku-ml-routing-02.txt
Date: Tue, 02 Jul 2002 06:32:52 -0400

--NextPart

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

	Title		: Multilayer routing using multilayer switch capable 
                          LSRs
	Author(s)	: W. Imajuku et al.
	Filename	: draft-imajuku-ml-routing-02.txt
	Pages		: 17
	Date		: 01-Jul-02
	
The integration of multilayer switching capabilities within one 
box, such as the packet-switch capability (PSC) and the lambda-
switch capability (LSC) under the MPLS/Generalized-MPLS control 
mechanism, paves the way for achieving network resource optimization 
considering multilayer routing. This document clarifies the model of 
the GMPLS-controlled integrated PSC/LSC label switch router (LSR) 
and discusses the requirements of the routing extensions needed to 
achieve optimized multilayer traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-imajuku-ml-routing-02.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-imajuku-ml-routing-02.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 01 Jul 2002 03:39:28 -0700
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-04.txt
Date: Mon, 01 Jul 2002 06:36:10 -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, S. Marshall-Unitt
	Filename	: draft-iwata-mpls-crankback-04.txt
	Pages		: 32
	Date		: 28-Jun-02
	
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 01 Jul 2002 03:39:21 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-00.txt
Date: Mon, 01 Jul 2002 06:34:50 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) 
                          Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-00.txt
	Pages		: 49
	Date		: 28-Jun-02
	
This memo defines an experimental portion of the
Management Information Base (MIB) for use with network
management protocols in the Internet community.  In
particular, it describes managed objects for Generalized
Multiprotocol Label Switching (GMPLS) [GMPLSArch] based
traffic engineering.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-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: Mon, 01 Jul 2002 03:39:15 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-00.txt
Date: Mon, 01 Jul 2002 06:34:46 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) 
                          Label Switch Router Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-00.txt
	Pages		: 33
	Date		: 28-Jun-02
	
This memo defines a portion of the Management Information
Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes
managed objects for Generalized Multiprotocol Label
Switching (GMPLS) Label Switched Routers (LSRs).

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-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: Mon, 01 Jul 2002 03:39:10 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-00.txt
Date: Mon, 01 Jul 2002 06:34:42 -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		: Definition of Textual Conventions and 
                          OBJECT-IDENTITIES for Generalized Multiprotocol Label 
                          Switching (GMPLS) Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-00.txt
	Pages		: 12
	Date		: 28-Jun-02
	
This memo describes Textual Conventions and OBJECT-
IDENTITIES common to the Management Information Bases
(MIBs) for managing Generalized Multiprotocol Label
Switching (GMPLS) networks.
It supplements [TCMIB] which describes Textual
Conventions and OBJECT-IDENTITIES common to the
Management Information Bases (MIBs) for managing
Multiprotocol Label Switching (MPLS) networks.

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

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

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

--OtherAccess--

--NextPart--