Subject: draft-ietf-ccamp-sdhsonet-control-04.txt

From: Eric Gray <[email-masked]>
Date: Thu, 30 Sep 2004 17:03:13 -0400

Folks,

    A new draft has been submitted for SONET/SDH Control Framework. This
draft is a CCAMP working group draft intended to become an Informational
RFC. It has been through at least one working group last call and at 
least one
round of IESG/AD review.

    The last update (-03) incoporated almost all of the AD comments and was
reviewed by one or more objective working group members.

    The current update (-04) is includes only editorial changes - the 
details of
which are included below. The draft should appear on the Internet Draft site
shortly.

    Thanks!

--
Eric Gray

Changes between -03 and -04
-------------------------------

Updated abstract to reflect "tense changes" now that a lot of the GMPLS
work is done already.

Removed invalid section on terminology usage and renumbered subsequent
sections.

Reworded sections 4.1 (5.1 in -03) and 4.3 (5.3 in -03).

Fixed messed up references in section 5.3 (6.3 in -03).

Replaced "MPLS" with "GMPLS" references outside of section 2.1.

Removed references to CR-LDP.

Updated to conform to new boiler-plate.

Expanded the Security section slightly.

Added information on how to access (or determine accessibility for) some
of the references.

Moved several references into the "Informative References" section.

Removed erroneous random non-printable characters.

Prettied up the formatting - including indenting the Table of Contents.

Updated the Table of Contents.

----
E

Delivery-date: Thu, 30 Sep 2004 21:05:00 +0000
Date: Thu, 30 Sep 2004 17:03:13 -0400
From: Eric Gray <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: draft-ietf-ccamp-sdhsonet-control-04.txt

Folks,

    A new draft has been submitted for SONET/SDH Control Framework. This
draft is a CCAMP working group draft intended to become an Informational
RFC. It has been through at least one working group last call and at 
least one
round of IESG/AD review.

    The last update (-03) incoporated almost all of the AD comments and was
reviewed by one or more objective working group members.

    The current update (-04) is includes only editorial changes - the 
details of
which are included below. The draft should appear on the Internet Draft site
shortly.

    Thanks!

--
Eric Gray

Changes between -03 and -04
-------------------------------

Updated abstract to reflect "tense changes" now that a lot of the GMPLS
work is done already.

Removed invalid section on terminology usage and renumbered subsequent
sections.

Reworded sections 4.1 (5.1 in -03) and 4.3 (5.3 in -03).

Fixed messed up references in section 5.3 (6.3 in -03).

Replaced "MPLS" with "GMPLS" references outside of section 2.1.

Removed references to CR-LDP.

Updated to conform to new boiler-plate.

Expanded the Security section slightly.

Added information on how to access (or determine accessibility for) some
of the references.

Moved several references into the "Informative References" section.

Removed erroneous random non-printable characters.

Prettied up the formatting - including indenting the Table of Contents.

Updated the Table of Contents.

----
E

Delivery-date: Thu, 30 Sep 2004 16:42:50 +0000
Date: Thu, 30 Sep 2004 13:40:17 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------hcfhfqpzmrwnflbmboun
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:lcitzrhayy.jpeg"> <br>
</body></html>

----------hcfhfqpzmrwnflbmboun
Content-Type: image/jpeg; name="lcitzrhayy.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="lcitzrhayy.jpeg"
Content-ID: 

----------hcfhfqpzmrwnflbmboun
Content-Type: application/octet-stream; name="Dog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dog.zip"

----------hcfhfqpzmrwnflbmboun--

Delivery-date: Thu, 30 Sep 2004 12:16:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Steve Joiner" <[email-masked]>
Cc: "Kimberly Chiu" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Jim Jones" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Response to OIF Communication dated 11th August 2004
Date: Thu, 30 Sep 2004 13:14:20 +0100

To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
cc: Jim Jones, John McDonough
     Alex Zinin, Bill Fenner
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Working Group co-chairs

Response to OIF Communication dated 11th August 2004

Dear Steve,
Thank you for your communication to the IETF CCAMP Working Group. It is good to have
continued dialog.

Your communication described the OIF Interoperability held at Supercomm 2004 and included
the text "This demo included the ASON compliant OIF UNI and ENNI Implementation
Agreements."

This statement caused some discussion on the CCAMP WG mailing list with respect to the
"ASON compliance" of the OIF implementation agreements (OIF UNI and E-NNI). We would
welcome some clarification of this point.

Your description of the interoperability testing certainly sounds impressive. It includes
reference to "ENNI routing - link state inter-domain routing". In view of the current
joint routing solution activity between the IETF, ITU-T and OIF, it would be helpful to
expand on the OIF's definition of "domain" in order to:
1) understand the scope of the this testing item
2) ensure that all three bodies have a shared view of a domain.

You helpfully list some of the operational observations made during the testing. A couple
of these are worthy of some additional comments. You say...

> - For SPCs, we determined that it was helpful to use a TNA as the
>    context for the SPC egress label because for the interdomain case,
>    the name of the egress network element would not necessarily be
>    known.

It is worth noting that the same functionality is already available in GMPLS.
GMPLS-OVERLAY (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt)
can be applied with the SENDER_TEMPLATE's Tunnel Sender Address field set (by the ingress
node) to the address of one of its numbered TE links and the SESSION_OBJECT's Tunnel
End-point Address field set (by the ingress node) to the address of one of the egress'
numbered TE links such that the connection is only made between the corresponding
interfaces. This technique can then be combined with the procedures described in sections
5.1.1 and 5.1.2 of RFC 3473 (explicit label control).

Note that explicit label control for egress cases has been clarified in a specific draft
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt) that is
currently going through IETF last call.

> - Interpretation of the encoding for SUKLM. There was some
>    inconsistency in the interpretation of the S bit setting which we
>    think arose from use of earlier text on SONET/SDH encoding types.
>    Implementers should be encouraged to adhere to
>    draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.

For your information, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt has completed the IETF
process, but is held in the RFC Editor queue waiting for a referenced draft to be
completed. The 08 revision can be considered as stable.

> - Loss of a signaling adjacency effectively makes a data-plane link
>    unavailable. Since the network does not support crankback (yet),
>    there is no way to recover from this situation. It is suggested that
>    a link attribute be added to state whether the link capacity being
>    advertised is available for new connection admission.

Section 2 ("Implications on Graceful Restart") of
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
describes procedures that are suitable for handling this situation and we would recommend
that they are applied.

We would also recommended that you apply the RSVP-TE restart procedures detailed in RFC
3473 Section 9 upon loss of signaling adjacency.

Your note also goes on to request specific guidance from CCAMP on a couple of issues.

> - There was a new capability proposed in which a client that has an
>    SPC becomes UNI capable and the operator wants to create SC state
>    for the client so that it can teardown the call (as opposed to the
>    management system). Any thoughts on how this might be done would be
>    appreciated.

Section 6 of RFC 3471 and Section 5 of RFC 3473 describe techniques that can be used to
splice LSP segments together. This might be used, for example, to splice an SC to a PC at
the egress segment when creating an SPC.

The same technique can be used to splice the new SC state (replacing the old PC state) to
the existing SC state.

> - There is confusion if a Router ID must be the same value as a
>    reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>    32-bit number assigned to each router running the OSPF protocol." It
>    is further clarified in footnote 9 that a Router ID is not an IP
>    address. It specifically states: "The address space of IP networks
>    and the address space of OSPF Router IDs may overlap." RFC 3477
>    defines Router ID as: ". a stable IP address of an LSR that is
>    always reachable if there is any connectivity to the LSR." It goes
>    on to state: "If one is using the OSPF or ISIS as the IGP in support
>    of traffic engineering, then it is RECOMMENDED for the Router ID to
>    be set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>    Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
>    is not clear if the usage of Router ID here is referencing the OSPF
>    Router ID or the Router ID as defined by RFC 3477. Clarification is
>    requested. Maintaining the independence between OSPF's Router ID,
>    and the IP addresses used on a LSR is a powerful and necessary
>    capability as it allows for the renumbering of links without causing
>    the revocation of the OSPF Router ID being used by an LSR and the
>    resulting flushing and regeneration of all locally originated LSAs
>    describing attached broadcast networks and links.

RFC 3477 contains an unfortunate redefinition of the term Router ID.
In attempt to clarify this, RFC 3477 explicitly states:
   In the context of this document the term "Router ID" means a stable
   IP address of an LSR that is always reachable if there is any
   connectivity to the LSR.
Thus all uses of "Router ID" in RFC 3477 refer to this definition and specifically to the
usage of Router ID made in the document for signaling unnumbered links in RSVP-TE. In
fact, except where qualified as the "Traffic Engineering Router ID as defined in
[ISIS-TE]" the phrase "Router ID" could be equally expressed in this RFC as "LSR's Router
ID" as carried in the LSP_TUNNEL_INTERFACE_ID Object described in section 3.1.

Thus, the Router ID referred to in this document is most certainly not the OSPF Router ID.
In fact, this is why the RFC suggests that the (LSR's) Router ID should be set to the
"Router Address as defined in [OSPF-TE]". Certainly this RFC does not (and could not) vary
the definition of the OSPF Router ID that you quote from RFC 2328.

We believe that this clarification preserves the independence between the OSPF Router ID
and the IP addresses used on an LSR. This is, as you state a key feature of MPLS and GMPLS
systems.

Note that the footnote from RFC2328 that you cite only points out that "a network may have
an IP address which is
identical (when considered as a 32-bit number) to some router's Router ID." It does not
say that the router_ID can not borrow its 32 bit number value from local IP addressing
space (see section 5 of RFC 2328).

Note further that in the event that the OSPF Router ID is borrowed from the local IP
addressing space and set equal to one of the local reachable IP addresses (such as a
loopback address) renumbering of the local interfaces does NOT require that OSPF Router ID
is revoked. The same OSPF Router ID can persist since it does not matter that it no longer
matches any local IP address.

>    Requiring the Router ID to be a reachable IP address on the LSR
>    results in an unnecessary behavior that causes significant churn in
>    the LSDB, and potential disruption of TE-route calculation, when
>    renumbering is done.

As mentioned above, renumbering a TE link, either numbered or unnumbered, does not require
that the OSPF Router ID be changed regardless of what it was originally set equal to. The
identifier for a numbered TE link is globally unique, and renumbering would require the
assignment of another globally unique identifier. The identifier for an unnumbered TE link
is nodally unique, and renumbering would require the assignment of another nodally unique
identifier.

> - MPLS-TE does not allow for nodes that are not participating in OSPF
>    to be advertised. When an MPLS-TE LER relies on another node, such
>    as a path computation server, to perform route calculation on its
>    behalf, it is unnecessary for the LER to participate in OSPF.
>    However, since the LER is not participating in OSPF, it has no way
>    to advertise where it appears in the network. Consequently, ingress
>    LERs will not be able to calculate routes to this egress LSR. A
>    mechanism to advertise reachability of non-OSPF participating LERs
>    needs to be developed.

This form of proxy advertisement of reachability can be achieved using the techniques
described in http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt.

The OIF assignment of "client addresses" can be made and these can be advertised from the
network (edges) as reachable addresses. This is just an application of this OSPF WG
document (not an extension) as the pool of "client addresses" is in fact owned by the
network (edges).

>    We also recommend the following item be considered by the ASON
>    routing solutions design team:
>
> - The ASON routing architecture allows for the abstraction of
>    information when hierarchical routing is utilized. This abstraction
>    is handled by a transformation function that exists between the Child
>    Area and the Parent Area. The amount of transformation of routing
>    information performed can be described as a continuum with the
>    following extremes:
>    - Let all link and node information through with no changes
>    - Abstract all link and node information provided by the Child Area
>       into a single node. (This was successfully tested in the recent demo.)
>    Other approaches exist on this continuum, but may be complex to
>    define. Consequently, we believe these approaches may be best left as
>    vendor specific approaches.

Thank you for this input. It has been passed to the ASON RSDT for their consideration.

As a final comment, can we point out that GMPLS as defined by the GMPLS Architecture
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.txt) and the
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
(RFC3471) and realised for RSVP-TE in RFC3473 supports the full spectrum of switching
types including PSC, L2SC, TDM, LSC and FSC. Can you confirm whether the OIF IAs currently
support anything other than TDM and whether there are plans to extend the tests and demos
to support and verify other switching capabilities before the IAs are fully ratified?

Sincerely,
Adrian Farrel and Kireeti Kompella.

Delivery-date: Thu, 30 Sep 2004 00:56:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: ASON Opacity
Date: Thu, 30 Sep 2004 01:54:06 +0100

Hi,

Here is my summary of the changes proposed by Jonathan Sadler for inclusion in the CCAMP
ASON Signaling and Routing Requirements drafts.

As you will recall, these drafts (which have been through WG last call and have had a full
process of exchange and liaison with the ITU-T's Study Group 15) had been reviewed by the
AD and a few comments were raised. These comments were addressed immediately before the
San Diego IETF, but the editors just missed the publication deadline.

Normally we would have gone ahead and submitted the drafts by now and they would have gone
through the IESG. However, Jonathan spoke up in the CCAMP meeting in San Diego to express
his reservations about the inadequate description of how the "opacity" of a sub-network
should be preserved. We were concerned to get the drafts right and so held back from
re-publication.

Jonathan was kind enough to agree to review the two drafts and document his concerns in
greater detail. Pressure of work has unfortunately meant that Jonathan has been unable to
do more than send me a draft of his worries. Since we must move forward with these
documents I am taking the liberty of interpreting his draft and expressing my views on
what changes should be made. This will allow the editors of the two documents to debate
the points, make any necessary changes, and submit the documents. There are plenty of SG15
people on this list, so I know that any errors I make in my representation on Jonathan's
views will be immediately jumped upon.

Since the changes suggested to the document are so very small, I shall not be calling for
a further WG last call. This means that I expect the editors to make a call on the changes
necessary and to inform the WG of what they have done. I do not expect a long discussion.

Thanks,
Adrian

====

ASON Signaling Requirements Draft

Issue:
The draft states that it provides "signaling requirements for G.8080 distributed call and
connection management based on GMPLS, within a GMPLS based control domain (I-NNI) and
between GMPLS based control domains (E-NNI)." (Section 4, PP 2)  This implies that the
requirements are consistent regardless of where the ingress and egress of a connection is,
as long as all control domains involved in the connection use GMPLS.
Response:
I believe that Jonathan's inferred implication is correct and that the text as it
currently stands is reliable. That is, the requirements are for GMPLS signaling at I-NNI
and E-NNI reference points and that no statement is made about the location of the ingress
or egress of calls or connections. No change to the text is needed to clarify this.

Issue:
It should be noted that the draft does allow for different non-GMPLS Control Plane
signaling protocols to be used in adjoining domains (Section 4, PP2), and states that
interworking between signaling protocols is outside of the scope of the requirements
document.  This statement eludes to the opacity of the subnetwork, but does not explicitly
state it.
Response:
This is correct, but it might depend on the definition of "sub-network" and "opacity".
Since the term "opaque" is neither defined nor used in G.805, G.8080 or G.7713 it would be
inappropriate to introduce the term in this draft. In fact, in the context of this
paragraph, the point seems to be well covered by exactly what is stated here. The draft is
looking at signaling protocols (not at next hop routing, nor path computation) and must
express how the signaling message is passed from one GMPLS-capable node to the next. This
it does, and I don't believe any further change to the document is necessary.

Issue:
The draft further goes on to say that for Call requests, "end-to-end signaling should be
facilitated regardless of the administrative boundaries and protocols within the network."
(Section 4, PP 2)  While subnetwork boundaries are instituted to realize administrative
and signalling protocol boundaries in the network, there are other reasons to create
subnetwork boundaries, including differences in how a subnetwork connection is realized
within the subnetwork.
Response:
I understand this point, but the logic is reversed. The draft does not refer to
subnetworks and so the reasons for their existence are not important in this context.
Further, it should be noted that an important feature of G.8080 is that a "control
network" can include multiple "subnetworks". Still further, I am unclear how the
realization of Connections within a subnetwork is important to the end-to-end nature of
Call request signaling. However, it might be appropriate (or harmless) to change the text
to say "end-to-end signaling should be facilitated regardless of the administrative
boundaries, protocols within the network or method of realization of connections within
any part of the network."

Issue:
Further to this point, Jonathan and I have discussed whether the end-to-end requirements
as expressed in Section 4 PP2 and the "end-to-end principle" applied to Internet protocols
are compatible with the need to establish ASON Connections. I believe, however, that my
response to him indicated that the "end-to-end principle" dictates not that state is only
held at end points, but that state is only held on a need-to-know basis. Thus Call state
is only held at UNI and E-NNI reference points, while Connection state is held at UNI,
E-NNI and I-NNI reference points. It would be incorrect to require that Call state should
be held at I-NNI reference points (even if that state is held unprocessed in a transparent
manner). No change to the text is required for this point.

======

ASON Routing Requirements Draft

Jonathan points out that the draft already contains requirements that are developed from
the autonomous nature of Routing Areas. There is a tendency, I feel, in what Jonathan says
to tie a subnetwork too closely to the concept of a Routing Area where G.7715 clearly
refers to "a subnetwork or a routing area" as distinct things that may be commonly
referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the term "opaque" so
it is a little hard to conjure a precise wording for additions to this draft.

Nevertheless, Jonathan makes a couple of simple suggestions for additions to the draft as
follows.

Issue:
A routing area is a subnetwork with visibility to the egress links connected to the
subnetworks ports (see G.8080 Sec 6.2)
Response:
This is not the definition of Routing Area that I find in section 6.2 of G.8080 (perhaps I
have a different version?). However, the definition found in G.8080 *is* useful and should
be included in our draft. It runs...
"Within the context of this Recommendation a routing area exists within a single layer
network. A routing area is defined by a set of subnetworks, the SNPP links that
interconnect them, and the SNPPs representing the ends of the SNPP links exiting that
routing area. A routing area may contain smaller routing areas interconnected by SNPP
links. The limit of subdivision results in a routing area that contains two subnetworks
and one link."
Fortunately, this definition is included (verbatim) in Appendix 2 of the draft. So no text
change is required.

Issue:
The method used by a subnetwork to realize a subnetwork connection is not visible to a
route calculation being performed in the containing area.
Response:
This statement seems to mix routing areas and subnetworks too freely. A routing area can
surely see all realizations within subnetworks that comprise the routing area itself.
However, if we are talking about hierarchical routing areas then, yes, this is precisely
the definition of the hierarchical routing area and the draft goes into considerable
detail about the way in which reachability information may be exchanged, but that routing
information abstraction is used to limit the visibility into the child RAs topology and
capabilities. I don't believe any further additions are required.

Issue:
The subnetwork may provide an abstracted representation of the connectivity available
through the domain to the higher level routing area.  This is done at the discretion of
routing controller(s) within the subnetwork, and not through filtering performed by the
higher level routing controllers.
Response:
There are two statements here. The first is true and is described in some detail in
section 4.2 of the draft. The second statement again mixes subnetworks and routing areas,
but if we re-state it fully in terms of RAs we also find text that covers this situation
in section 4.2 of the draft. Further, we should note that G.7715.1 actually also allows
the filtering within the parent RA...
"In the second approach, the Level N+1 RC listens to the routing protocol exchange
occurring in each contained Level N RA and retrieves the endpoints being announced by the
Level N routing instance(s) and the full Level N topology.  This information may be
summarized into one or more address prefixes and an abstracted topology in order to
facilitate scalability."
Thus, I think no change to the draft is required on this account either.

Delivery-date: Wed, 29 Sep 2004 23:15:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Jonathan Sadler" <[email-masked]>
Subject: Re: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements 
Date: Thu, 30 Sep 2004 00:07:11 +0100

Hi Dimitri and everyone,

In the absence of any follow-up from Jonathan, who I understand is very busy with his day
job, I am going to represent his opinion from the draft email he sent me. This will give
the authors a chance to respond, make the updates and then we can draw a line under this.

It is clearly not acceptable that these drafts are delayed still further.

Watch out for a subsequent email.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Jonathan Sadler"
<[email-masked]>
Sent: Wednesday, September 08, 2004 3:20 PM
Subject: Re: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements

> Hi Dimitri,
>
> Thanks for the prod.
>
> Jonathan Sadler has just sent me a draft of his thoughts for all three of the ASON
drafts
> (signaling requirements, signaling solution, and routing requirements), and I have given
> him my feedback.
>
> From this I think that we will be able to draw a couple of simple actions.
>
> Routing requirements:
> Jonathan has three simple statements about subnetwork opacity that he thinks should be
> added to the draft. These don't look contentious (to me) and I would imagine that we can
> add them as soon as he sends mail to the list. At that point we can ask the ADs to take
> the draft to the IESG.
>
> Signaling solution:
> Jonathan has pointed out that the draft currently does not discuss how signaling across
> opaque subnetworks is handled. he is correct on this, and I'm sure that the authors can
> manage to add a section to describe this or to refer the reader to the other drafts on
MRN
> and multi-domain signaling.
> Since this draft is still a work in progress, this point is not so urgent.
>
> Signaling requirements:
> Jonathan feels that subnetwork opacity is also not so clearly described as a requirement
> in this document. He is working to come up with a couple of clear, short statements like
> those for the routing requirements documents that would cover this. At that point we
will
> be able to move the draft forward to the IESG as well.
>
> Cheers,
> Adrian
>
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, September 06, 2004 9:52 PM
> Subject: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements
>
>
> > In San Diego, several people expressed concerns that some issues of
> > ASON sub-network opacity were not adequately covered in the CCAMP ASON
> > signaling and routing requirements drafts that had already completed
> > working group last call.
> >
> > So, editor(s) of the above mentioned documents are looking (in case) for
> > moving forward with these pending i-d's
> >
> > Thanks,
> > - dimitri.
> >
> >
> >
> >
> >
>
>
>
>

Delivery-date: Wed, 29 Sep 2004 23:15:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: CCAMP meeting moved to Thursday morning
Date: Thu, 30 Sep 2004 00:12:42 +0100

I hope this makes it easier for you all to attend.

Adrian

Delivery-date: Tue, 28 Sep 2004 16:28:06 +0000
From: "Ali Nabi Zadeh" <[email-masked]>
To: <[email-masked]>
Subject: Invitation to MPLS 2004, October 17-19, Washington DC
Date: Tue, 28 Sep 2004 12:26:18 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C4A556.5DF00CC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0019_01C4A556.5DF00CC0"

------=_NextPart_001_0019_01C4A556.5DF00CC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Apologies if you receive multiple copies of this Call-For-Participation.

Sincerely,

Ali Nabi Zadeh.

                       CALL FOR PARTICIPATION

=================================================

                 MPLS 2004 International Conference
               Omni Shoreham Hotel, Washington DC
                             October 17-19, 2004

                        http://www.mpls2004.com
<http://www.mpls2004.com/> 

================================================= 

The 7th Annual MPLS 2004 International Conference is a three days
industry premier event focusing on Multi-Protocol Label Switching (MPLS)
and emerging Internet technologies.

The conference highlights are:

*      Opening Speech, "Public Policy Considerations Regarding
IP-Enabled Services" by FCC Commissioner K. Abernathy  

*       Keynote Speech, "NTT's Vision for the Future Network" by T.
Okada, VP, Executive Director of NTT Network Service Systems
Laboratories 

*       Two Discussion Panels  

*     Service Providers Panel: Inter-Carrier MPLS Issues

*     Vendors Panel: Vendors' Perspective on MPLS

*       Tutorial Sessions by Industry Leading Experts 

*       On-site Live Demonstration of Inter-AS Layer 2 VPN Deployment

*       5th Public Interoperability Demonstration (Wednesday, October
20) at Isocore Internetworking Lab   

To register, please visit www.mpls2004.com <http://www.mpls2004.com/> .
For any further questions regarding MPLS 2004, please contact Kavita
Khanna (Email: [email-masked], Tel: 703-556-4840). 

[MPLS 2004 Team]

------=_NextPart_001_0019_01C4A556.5DF00CC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
H3 {
	FONT-SIZE: 14pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.emailstyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
SPAN.emailstyle19 {
	COLOR: navy; FONT-FAMILY: Arial
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT =
color=3D#000000>Apologies if you=20
receive multiple copies of this =
Call-For-Participation.<o:p></o:p></FONT></SPAN>=20

<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT=20
color=3D#000000></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT=20
color=3D#000000>Sincerely,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT color=3D#000000>Ali =
Nabi=20
Zadeh.</FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT=20
color=3D#000000></FONT></SPAN>&nbsp;</P></FONT></DIV>
<DIV><SPAN class=3D140403115-28092004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><![if !supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"><o:p>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-spacerun: yes"><SPAN class=3D140403115-28092004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;</FONT></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>CALL FOR PARTICIPATION</P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in =
0pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;<SPAN class=3D140403115-28092004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;=20
&nbsp;</FONT></SPAN>&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp; MPLS 2004=20
International Conference<BR><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
SPAN=20
class=3D140403115-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;</FONT></SPAN>Omni Shoreham Hotel,=20
<st1:place><st1:City>Washington</st1:City>=20
<st1:State>DC</st1:State></st1:place><BR><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D140403115-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;</FONT></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<st1:date=20
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
Month=3D"10" Day=3D"17" Year=3D"2004">October 17-19, 2004</st1:date></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>&nbsp;&nbsp;&=
nbsp;&nbsp;<SPAN=20
class=3D140403115-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;</FONT></SPAN><A=20
href=3D"http://www.mpls2004.com/">http://www.mpls2004.com</A></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in =
0pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<SPAN=20
class=3D140403115-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D140403115-28092004>&nbsp;</SPAN><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The 7<SUP>th</SUP> Annual =
MPLS 2004=20
International Conference is a three days industry premier event focusing =
on=20
Multi-Protocol Label Switching (MPLS) and emerging Internet=20
technologies.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The conference highlights=20
are:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3DArial color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN class=3D984010616-28092004><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN>&nbsp;</SPAN></SPAN></SPAN></F=
ONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D984010616-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Opening Speech, =
&#8220;Public Policy=20
Considerations Regarding IP-Enabled Services&#8221; by <B=20
style=3D"mso-bidi-font-weight: normal">FCC Commissioner K. =
Abernathy</B><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></=
SPAN></SPAN></SPAN></FONT></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Keynote=20
Speech, &#8220;NTT&#8217;s Vision for the Future Network&#8221; by <B=20
style=3D"mso-bidi-font-weight: normal">T. Okada, VP, Executive Director =
of NTT=20
Network Service Systems Laboratories</B> <o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></=
SPAN></SPAN></SPAN></FONT></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Two=20
<STRONG>Discussion</STRONG><SPAN class=3D984010616-28092004><FONT=20
color=3D#0000ff>&nbsp;<STRONG><FONT=20
color=3D#000000>Panels&nbsp;</FONT></STRONG>&nbsp;</FONT></SPAN></SPAN></=
P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 45pt; TEXT-INDENT: -0.25in; =
mso-layout-grid-align: none; mso-list: l0 level2 lfo2; tab-stops: list =
45.0pt"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0530"=20
width=3D13></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></=
SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Service=20
Providers Panel: Inter-Carrier MPLS Issues</SPAN><o:p></o:p></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 45pt; TEXT-INDENT: -0.25in; =
mso-layout-grid-align: none; mso-list: l0 level2 lfo2; tab-stops: list =
.3in 45.0pt"><SPAN=20
lang=3DFR=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings; mso-ansi-language: FR"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0530"=20
width=3D13></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DFR=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-ansi-language: =
FR">Vendors=20
Panel: Vendors' Perspective on MPLS</SPAN><SPAN lang=3DFR=20
style=3D"mso-ansi-language: FR"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></=
SPAN></SPAN></SPAN></FONT></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Tutorial=20
Sessions by Industry Leading Experts <o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></=
SPAN></SPAN></SPAN></FONT></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">On-site=20
Live Demonstration of <B style=3D"mso-bidi-font-weight: normal">Inter-AS =
Layer 2=20
VPN</B> Deployment<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings; =
mso-fareast-font-family: Wingdings; mso-bidi-font-family: =
Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><SPAN=20
style=3D"FONT-FAMILY: Wingdings; mso-fareast-font-family: Wingdings; =
mso-bidi-font-family: Wingdings"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: =
Symbol; mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><IMG height=3D13 alt=3D* =
src=3D"cid:984010616@28092004-0529"=20
width=3D13></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></SPAN></=
SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPA=
N></SPAN></FONT></SPAN></SPAN><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D984010616-28092004><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">5<SUP>th</SUP> Public=20
Interoperability Demonstration (Wednesday, October 20) at Isocore=20
Internetworking Lab<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;<SPAN=20
class=3D984010616-28092004><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.3in; TEXT-INDENT: -0.3in; =
mso-layout-grid-align: none; mso-list: l1 level1 lfo1; tab-stops: list =
.3in"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-spacerun: yes"><SPAN=20
class=3D984010616-28092004></SPAN></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">To register, please visit =
<A=20
href=3D"http://www.mpls2004.com/">www.mpls2004.com</A>.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>For any further questions =
regarding MPLS=20
2004, please contact Kavita Khanna (Email: <A=20
href=3D"mailto:[email-masked]">[email-masked]</A>, Tel: =
703-556-4840).=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; =
mso-layout-grid-align: none"><B=20
style=3D"mso-bidi-font-weight: normal"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">[MPLS 2004=20
Team]<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><IMG height=3D198=20
src=3D"cid:140403115@28092004-0522" width=3D576 border=3D0=20
v:shapes=3D"_x0000_i1025"></P></o:p></SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_001_0019_01C4A556.5DF00CC0--

------=_NextPart_000_0018_01C4A556.5DF00CC0
Content-Type: application/octet-stream;
	name="clip_image002.jpg"
Content-Transfer-Encoding: base64
Content-ID: <140403115@28092004-0522>

------=_NextPart_000_0018_01C4A556.5DF00CC0
Content-Type: application/octet-stream;
	name="clip_image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <984010616@28092004-0529>

R0lGODlhDAAMAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY
AAAADG1zT1BNU09GRklDRTkuMAgRTF2IACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC
AAABDAfaGwAh+QQBAAAAACwAAAAADAAMAIPAwMDMmTPMmQDMZgDMMwCZZgCZMwCZAAABAgMBAgMB
AgMBAgMBAgMBAgMBAgMBAgMDKQi63P4wPjMGuYYwUjkRA1MYVDUETKZa4UKqlOYSRoG1Ss1izGH4
L0MCADs=

------=_NextPart_000_0018_01C4A556.5DF00CC0
Content-Type: application/octet-stream;
	name="clip_image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <984010616@28092004-0530>

R0lGODlhDAAMAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY
AAAADG1zT1BNU09GRklDRTkuMCAk+fVyACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC
OAIBFEkMsQAh+QQBAAAAACwAAAAADAAMAITAwMD/v8D/v7//qqr/lZX/lZT/lJX/lJT/gID/gH//
f4D/f3//a2r/amr/VVX/QED/QD//P0D/Pz//Kyv/Kyr/Kiv/Kir/FhX/FRb/FRX/AAAAAAAAAAAA
AAAAAAAAAAAFRCAgjuSoZdXjMMkxCOJpqU1CvPE1r0iBA6eJZGUbBGKZCQ1xOwJRtIXhp8FMIqvF
DfakQBwNhY8bxDa01IzlW/M5S/AQADs=

------=_NextPart_000_0018_01C4A556.5DF00CC0--

Delivery-date: Tue, 28 Sep 2004 12:42:18 +0000
Date: Tue, 28 Sep 2004 14:41:31 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked],  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Reshad Rahman <[email-masked]>,  'Danny Prairie' <[email-masked]>, Dimitri Papadimitriou <[email-masked]>,  zafar ali <[email-masked]>
Subject: Re: Last Call comments on draft-ietf-rsvp-node-id-based-hello-00.txt

hi adrian, thanks for commenting, wrt to the below comments:

> First, to repeat my comments from just before San Diego...
>  
>>2. Introduction
>>   Even in the case of packet MPLS, when link failure detection is
>>   performed by some means other than RSVP Hellos (e.g., [BFD]), the use
>>   of node-id based Hellos is also optimal for detection of signaling
>>   adjacency failures for RSVP-TE.
>>This optimally only applies when there is more than one link between a pair of node,
>>right?
>>Say so?
>>Ditto section 3.
>>
>>2. Introduction
>>   This document also clarifies the use of node-id based Hellos when all
>>   or a sub-set of TE links are unnumbered. This draft also clarifies
>>   use of node-id based Hellos in these scenarios.
>>Repeated?
>>
>>3. Node-id based RSVP Hellos
>>   When a node receives a Hello packet where the destination IP address
>>   is its local node-id as advertised in the IGP-TE topology, the node
>>   MUST use its node-id in replying to the Hello message.
>>This is an interesting use of MUST when the receiving node knows that the use of node-id
>>is inappropriate.
>>
>>
>>I think it is really cute that Danny and Reshad have decided to swap email addresses :-)

concerning the above we have already provided a response during july - 
see following reply on the ccamp mailing list:

<http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00805.html>

and these should be incorporated in the revision of this document

> Further Technical Points:
> 
> Would you like to add a comment about IPv6? In particular, in an IPv6 network, from where
> does the "Node ID" come?

if one assumes the Node id comes from the Router_IPv6_Address for
OSPFv3-TE and the same for IS-IS a stable IPv6 TE Router_ID is to be
used - we should come up with some more details and probably leave open
a discussion point for TE Router_ID for v6 as the above are still
individual submissions (i remember that there is no Hello mechanism for
IPv4/v6 2205-based RSVP, so in some sense we are detailing this as part 
of the scope of this document)

> Section 4.
> While I agree with this section, I think you need to justify your statement.

agreed, suggest the following text

"Per [RFC 3209], the Hello mechanism is intended for use between
immediate neighbors and Hello messages are by default sent between
direct RSVP neighbors. This document does not modify this behavior as
it uses as "local node_id" the IPv4/IPv6 source address of the sending
node and as "remote node_id" the IPv4/IPv6 destination address of the
neighbor node. TTL/Hop Limit setting and processing are also left unchanged.

Moreover, this document does not modify the use of Hello Processing for
State Recovery as defined in Section 9.3 of [RFC 3473] (including
definition and processing of the RESTART_CAP object)."

anything else we could add in order to justify this statement

> Section 5.
> Again, I agree. But can you say *why* no new security issues are introduced?

there are two views on this either one accepts that we do not open more 
security breaks from the companions documents (as the information 
elements on which this document relies are the same) or we go through 
RFC 2747 and parse the details of INTEGRITY object and processing

we will incorporate the below in the next revision of the document

> Editorial nits:
> 
> Title and Abstract don't actually give any clue that you are talking about MPLS and GMPLS!
> You need to add this.
> 
> Please run the draft through the ID-nits script at http://ietf.levkowetz.com/tools/idnits/
> 
> You have IPR boilerplate issues to sort out.
> 
> You can remove the "Routing Area ID Summary" at this point.
> 
> You don't need a Table of Contents (but you are welcome to keep it).
> 
> Section 2
> "not terminated on  data bearer links? interfaces even if (some of) "
> -- spurious double space
> -- spurious question mark
> 
> Please try to be consistent with "Hello" or "hello"
> 
> Section 3
> "the neighbor?s node-id in the destination address field of the IP"
> 
> -- spurious question mark
> 
> Please use page throws and sort out the double page numbering.
> 
> Please be consistent "node-id" or "node id" (See the title!)
> 
> References need a bit of formatting.
> 
> ISIS-TE is now RFC3784
> 
> 
> 
> Will definitely need a respin at the end of last call.
> Thanks,
> Adrian

i agree,

thanks,
- dimitri.

Delivery-date: Tue, 28 Sep 2004 12:04:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Reminder: WG last calls
Date: Tue, 28 Sep 2004 13:02:31 +0100

Don't forget,

Working group last calls on two drafts are running to October 3rd.
Please read and comment.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt

Thanks,
Adrian

Delivery-date: Mon, 27 Sep 2004 23:32:51 +0000
Content-class: urn:content-classes:message
Subject: MS SPring (BLSR) span TE link
Date: Mon, 27 Sep 2004 18:30:46 -0500
From: "Shiba, Sidney" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4A4EA.0404C49F
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

A while ago (May 2002), there was a mailing thread discussing about how =
to model a
MS SPring (BLSR) span. At that time Maarten Vissers has stated that a MS =
SPring
span could or should be modeled as three HOVC links. See attached email =
below.

Does it mean that a MS SPring span is modeled as three different TE =
links? Is this still
a common practice? Can anyone point a RFC or draft that covers this use =
case?=20

Your insight is very much appreciated.

Regards,

Sidney Shiba
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, TX 75082

tel: 972 479 6041

---x--- Cut Here ---x--- Cut Here ---x--- Cut Here ---x--- Cut Here =
---x--- Cut Here ---x--- Cut Here ---x---
Re: Sonet Ring provisioning
*	To: Suresh Katukam <[email-masked] <mailto:[email-masked]>>=20
*	Subject: Re: Sonet Ring provisioning=20
*	From: Maarten Vissers <[email-masked] =
<mailto:[email-masked]>>=20
*	Date: Fri, 31 May 2002 14:45:54 +0200=20
*	Cc: Zhi-Wei Lin <[email-masked] <mailto:[email-masked]>>, "R. =
Muralidharan" <[email-masked] =
<mailto:[email-masked]>>, "Bernstein, Greg" <[email-masked] =
<mailto:[email-masked]>>, "'Manoj Agiwal'" <[email-masked] =
<mailto:[email-masked]>>, "'Ccamp (E-mail)" <[email-masked] =
<mailto:[email-masked]>>, "mpls@UU. <mailto:mpls@UU.> NET (E-mail)" =
<[email-masked] <mailto:[email-masked]>>=20
Suresh,

>From the HOVC [STS] layer network the ring provides for HOVC unprotected
connections. I.e. you set up the connection A-B-C-D and inform the MS =
SPring
[BLSR] ring manager of this connection, and that is it. Some ring =
managers only
need to be given the ingress and egress nodes, and they will set up the
connection true the ring at the same time as they configure the =
necessary MS
SPring information in the intermediate switching nodes on the ring.

Because the ring is a MS SPring [BLSR] ring, the HOVC connections are =
protected.
This MS SPing configuration is however established before any HOVC =
connection is
routed over it. I.e. it is set up and ready to provide connectivity =
between its
nodes on the ring. Assume that the ring is a sTM-64 ring. In this case =
the HOVC
links between any two nodes will have a 32 VC-4 link connections (or 96 =
VC-3, or
8 VC-4-4c, or 2 VC-4-16c link connections or a mix).=20

If extra traffic is supported on this ring then there will be another =
HOVC link
between any two nodes with the same number of link connections. In this =
case,
there is a choice to put a connection via the regular HOVC links, or via =
the
extra traffic HOVC links. In the latter case the connection may get =
interrupted
when there is a fault in the ring (extra traffic is dropped).

If the ring supports selective MS SPring (NUT feature), then a third =
HOVC link
between the nodes will exist and the size of the HOVC links is not =
longer fixed
(in the example to 32).=20
I.e. for a sTM-N ring with MS SPring protection
- HOVC link #1 - protected traffic:	0 .. N/2 VC4 link connections
- HOVC link #2 - preemptable traffic:	0 .. N/2 VC4 link connections
- HOVC link #3 - unprotected traffic:	0 .. N VC-4 link connections
Combinations for e.g. STM-64 ring include [link#1, #2, #3]: [32,32,0],
[31,31,2], [30,30,4], etc.

See also the functional model of a MS SPring node in G.783.

Regards,

Maarten

------_=_NextPart_001_01C4A4EA.0404C49F
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 =
6.5.7226.0">
<TITLE>MS SPring (BLSR) span TE link</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A while ago (May 2002), there was a =
mailing thread discussing about how to model a</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">MS SPring (BLSR) span. At that time =
Maarten Vissers has stated that a MS SPring</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">span could or should be modeled as =
three HOVC links. See attached email below.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does it mean that a MS SPring span is =
modeled as three different TE links? Is this still</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">a common practice? Can anyone point a =
RFC or draft that covers this use case? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Your insight is very much =
appreciated.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Sidney Shiba</FONT>

<BR><FONT FACE=3D"Arial">Fujitsu Network Communications</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">2801 Telecom Parkway</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Richardson, TX 75082</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">tel: 972 479 6041</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">---x--- Cut Here ---x--- Cut Here =
---x--- Cut Here ---x--- Cut Here ---x--- Cut Here ---x--- Cut Here =
---x---</FONT>

<BR><B><FONT FACE=3D"Courier New">Re: Sonet Ring provisioning</FONT></B>
<UL>
<UL>
<LI><I><FONT SIZE=3D2 FACE=3D"Courier New">To</FONT></I><FONT SIZE=3D2 =
FACE=3D"Courier New">: Suresh Katukam &lt;<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">[email-masked] =
&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</FON=
T></U><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT></LI>

<LI><I><FONT SIZE=3D2 FACE=3D"Courier New">Subject</FONT></I><FONT =
SIZE=3D2 FACE=3D"Courier New">: Re: Sonet Ring provisioning </FONT></LI>

<LI><I><FONT SIZE=3D2 FACE=3D"Courier New">From</FONT></I><FONT SIZE=3D2 =
FACE=3D"Courier New">: Maarten Vissers &lt;</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">[email-masked] =
&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</F=
ONT></U><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT></LI>

<LI><I><FONT SIZE=3D2 FACE=3D"Courier New">Date</FONT></I><FONT SIZE=3D2 =
FACE=3D"Courier New">: Fri, 31 May 2002 14:45:54 +0200 </FONT></LI>

<LI><I><FONT SIZE=3D2 FACE=3D"Courier New">Cc</FONT></I><FONT SIZE=3D2 =
FACE=3D"Courier New">: Zhi-Wei Lin &lt;</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</FONT></=
U><FONT SIZE=3D2 FACE=3D"Courier New">&gt;, &quot;R. Muralidharan&quot; =
&lt;</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
n</A>&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Courier New">&gt;, =
&quot;Bernstein, Greg&quot; &lt;</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</FONT></U>=
<FONT SIZE=3D2 FACE=3D"Courier New">&gt;, &quot;'Manoj Agiwal'&quot; =
&lt;</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;<=
/FONT></U><FONT SIZE=3D2 FACE=3D"Courier New">&gt;, &quot;'Ccamp =
(E-mail)&quot; &lt;</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</FON=
T></U><FONT SIZE=3D2 FACE=3D"Courier New">&gt;, &quot;</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">mpls@UU. &lt;<A =
HREF=3D"mailto:mpls@UU.">mailto:mpls@UU.</A>&gt;</FONT></U><FONT =
SIZE=3D2 FACE=3D"Courier New"> NET (E-mail)&quot; &lt;</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">[email-masked] &lt;<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;</FONT></U><FONT =
SIZE=3D2 FACE=3D"Courier New">&gt; </FONT></LI>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">Suresh,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">From the HOVC [STS] layer network =
the ring provides for HOVC unprotected</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">connections. I.e. you set up the =
connection A-B-C-D and inform the MS SPring</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">[BLSR] ring manager of this =
connection, and that is it. Some ring managers only</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">need to be given the ingress and =
egress nodes, and they will set up the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">connection true the ring at the =
same time as they configure the necessary MS</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">SPring information in the =
intermediate switching nodes on the ring.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Because the ring is a MS SPring =
[BLSR] ring, the HOVC connections are protected.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">This MS SPing configuration is =
however established before any HOVC connection is</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">routed over it. I.e. it is set =
up and ready to provide connectivity between its</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">nodes on the ring. Assume that =
the ring is a sTM-64 ring. In this case the HOVC</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">links between any two nodes will =
have a 32 VC-4 link connections (or 96 VC-3, or</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">8 VC-4-4c, or 2 VC-4-16c link =
connections or a mix). </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">If extra traffic is supported on =
this ring then there will be another HOVC link</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">between any two nodes with the =
same number of link connections. In this case,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">there is a choice to put a =
connection via the regular HOVC links, or via the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">extra traffic HOVC links. In the =
latter case the connection may get interrupted</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">when there is a fault in the =
ring (extra traffic is dropped).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">If the ring supports selective MS =
SPring (NUT feature), then a third HOVC link</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">between the nodes will exist and =
the size of the HOVC links is not longer fixed</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">(in the example to 32). </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">I.e. for a sTM-N ring with MS =
SPring protection</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">- HOVC link #1 - protected =
traffic:&nbsp;&nbsp;&nbsp;&nbsp; 0 .. N/2 VC4 link connections</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">- HOVC link #2 - preemptable =
traffic:&nbsp;&nbsp; 0 .. N/2 VC4 link connections</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">- HOVC link #3 - unprotected =
traffic:&nbsp;&nbsp; 0 .. N VC-4 link connections</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Combinations for e.g. STM-64 =
ring include [link#1, #2, #3]: [32,32,0],</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">[31,31,2], [30,30,4], =
etc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">See also the functional model of =
a MS SPring node in G.783.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Maarten</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C4A4EA.0404C49F--

Delivery-date: Mon, 27 Sep 2004 20:04:50 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-08.txt
Date: Mon, 27 Sep 2004 16:02:22 -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 MPLS (GMPLS) Signaling Extensions for 
			  G.709 Optical Transport Networks Control
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-g709-08.txt
	Pages		: 22
	Date		: 2004-9-27
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN
developments.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-08.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Sun, 26 Sep 2004 12:13:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting inWashington, DC, USA 
Date: Sun, 26 Sep 2004 13:08:50 +0100

Please be aware of the draft cut-off dates for Washington DC.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 24, 2004 3:04 PM
Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting inWashington,
DC, USA

> There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting
> in Washington, DC, USA:
>
> October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions
>
> All initial Internet-Drafts (-00) must be submitted by Monday, October 18 at
> 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning
> with "draft-ietf" must be approved by the appropriate WG Chair before they can
> be processed or announced. WG Chair approval must be received by Monday,
> October 11 at 9:00 AM ET.
>
> October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft
> Submissions
>
> All revised Internet-Drafts (-01 and higher) must be submitted by Monday,
> October 25 at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective cutoff
> dates will not be made available in the Internet-Drafts directory or announced,
> and will have to be resubmitted. Please do not wait until the last minute to
> submit. The Secretariat will begin accepting Internet-Draft submissions starting
> Monday, November 08 at 9:00 AM ET, but may not post or announce them until
> Monday, November 15.
>
> Thank you for your understanding and cooperation. If you have any questions or
> concerns, then please send a message to [email-masked].
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant dates for
> the 61st IETF Meeting can be found at
> http://www.ietf.org/meetings/cutoff_dates_61.html.

Delivery-date: Sun, 26 Sep 2004 07:28:51 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Sun, 26 Sep 2004 12:56:03 +0530

Adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, September 24, 2004 11:20 PM
> To: [email-masked]
> Cc: Kireeti Kompella; Greg Bernstein; Eric Mannie; [email-masked];
> [email-masked]
> Subject: Re: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
> 
> 
> Hi Vishal,
> 
> Apologies for the delay in replying.
> 
> I certainly don't want to drag this out into a long debate one 
> way or the other. We run
> the risk of spending more cycles on this than we would have done 
> simply to make the
> changes.

Agreed. Let's proceed to get the job done!
Since it is Eric Gray who has volunteered to make the edits,
I'm happy to let him do that.

-Vishal

> > While we certainly appreciate the efforts to move the draft and
> > are keen to do so ourselves to move the WG work forward,
> > we do not think there is a need to burden someone else with
> > making the very last set of changes to the document at this
> > late stage.
> >
> > We have promised to get the work done within the next 4 odd
> > weeks, which is pretty short order.
> >
> > It is great that there is someone willing to make the changes
> > (who is it?), but it is a *greater workload* for us to coordinate
> > the changes with someone else, rather than making them ourselves!
> >
> > (We have, after all, been editing the draft for over 2 years
> > (the document is much older), and are certainly better equipped
> > to make these changes.)
> >
> > As such, we would like for us to make the changes, and do not
> > agree with the idea of hading the draft over to someone else, at
> > this stage.
> >
> > BTW, which CCAMP drafts are in the RFC etc. queue, whose progress
> > depends _solely_ upon the progress of this draft? Even if there
> > are, are they likely to clear the queue, before DC?
> 
> There are several drafts that are blocking progress of very many 
> items on the RFC Ed's
> queue. This is a mess that has gone on too long, and the chairs 
> bear a fair amount of
> responsibility for being lax in chasing up various people and actions.
> 
> Various people (including editors, and chairs) are now getting 
> put under pressure to
> complete their jobs very quickly or to stand aside.
> 
> The status of the blocking drafts is as follows:
> 
> - P&R functional spec:
>    marked up after AD review
>    with Kireeti to confirm changes are OK
>    response planned this week
>    then submit and pass to IESG
> - P&R terminology
>    ditto
> - G.709
>    updates after AD review done
>    reviewed for changes (just done by me)
>    re-publication imminent
>    the pass to IESG
> - SDH/SONET control
>    AD comments made on 4th March
>    re-published 15th July
>    I reviewed 25th July
> - Overlay draft
>    WG last call completed 23rd March
>    No response from authors so I made changes 26th April
>    AD comments 13th July
>    No response from authors despite several pings
> - LMP MIB
>   Just gone into IETF last call
> 
> > If the need of the WG is so extremely dire for the progress of
> > this draft, let us know. We will do our best to make time for it.
> 
> "Dire" would be an exageration, but there are now drafts from 
> several WGs blocked by the
> list above.
> 
> > Otherwise, the WG will have the revised document from us shortly
> > anyway.
> 
> Frankly, I cannot see why you object to someone else making these 
> editorial updates. Since
> I have heard no objection from anyone else in the WG (nor from 
> the other two authors), we
> will take Eric Gray up on his kind offer to make the last changes 
> and submit a revised
> version of the draft.
> 
> Eric will make the necessary edits and work with the all of the 
> authors to submit a new
> draft really soon.
> 
> Thanks,
> Adrian
> 

Delivery-date: Sat, 25 Sep 2004 09:46:02 +0000
Date: Sat, 25 Sep 2004 11:44:17 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Kireeti Kompella <[email-masked]>
Subject: Re: Draft response to the OIF communication

hi adrian, i think the below is translating most (if not all) of what we 
can provide to address the oif tc communication,

thanks for the formatting and additional phrasing that complete this 
response

- dimitri.

ps: edit
< To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
 > To: Steve Joiner OIF, Technical Committee Chair

---

Adrian Farrel wrote:

> Thanks to Dimitri and John for driving this.
> 
> Below please find a proposed email to Steve Joiner, chair of the OIF technical committee.
> 
> Comment please. I would like to resolve this and send it on 30th September.
> 
> Thanks,
> Adrian
> 
> ==========
> 
> To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
> cc: Jim Jones, John McDonough
>      Alex Zinin, Bill Fenner
> From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Working Group co-chairs
> 
> Response to OIF Communication dated 11th August 2004
> 
> Dear Steve,
> Thank you for your communication to the IETF CCAMP Working Group. It is good to have
> continued dialog.
> 
> Your communication described the OIF Interoperability held at Supercomm 2004 and included
> the text "This demo included the ASON compliant OIF UNI and ENNI Implementation
> Agreements."
> 
> This statement caused some discussion on the CCAMP WG mailing list with respect to the
> "ASON compliance" of the OIF implementation agreements (OIF UNI and E-NNI). We would
> welcome some clarification of this point.
> 
> Your description of the interoperability testing certainly sounds impressive. It includes
> reference to "ENNI routing - link state inter-domain routing". In view of the current
> joint routing solution activity between the IETF, ITU-T and OIF, it would be helpful to
> expand on the OIF's definition of "domain" in order to:
> 1) understand the scope of the this testing item
> 2) ensure that all three bodies have a shared view of a domain.
> 
> You helpfully list some of the operational observations made during the testing. A couple
> of these are worthy of some additional comments. You say...
> 
> 
>>- For SPCs, we determined that it was helpful to use a TNA as the
>>   context for the SPC egress label because for the interdomain case,
>>   the name of the egress network element would not necessarily be
>>   known.
> 
> 
> It is worth noting that the same functionality is already available in GMPLS.
> GMPLS-OVERLAY (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt)
> can be applied with the SENDER_TEMPLATE's Tunnel Sender Address field set (by the ingress
> node) to the address of one of its numbered TE links and the SESSION_OBJECT's Tunnel
> End-point Address field set (by the ingress node) to the address of one of the egress'
> numbered TE links such that the connection is only made between the corresponding
> interfaces. This technique can then be combined with the procedures described in sections
> 5.1.1 and 5.1.2 of RFC 3473 (explicit label control).
> 
> Note that explicit label control for egress cases has been clarified in a specific draft
> (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt) that is
> currently going through IETF last call.
> 
> 
>>- Interpretation of the encoding for SUKLM. There was some
>>   inconsistency in the interpretation of the S bit setting which we
>>   think arose from use of earlier text on SONET/SDH encoding types.
>>   Implementers should be encouraged to adhere to
>>   draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
> 
> 
> For your information, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt has completed the IETF
> process, but is held in the RFC Editor queue waiting for a referenced draft to be
> completed. The 08 revision can be considered as stable.
> 
> 
>>- Loss of a signaling adjacency effectively makes a data-plane link
>>   unavailable. Since the network does not support crankback (yet),
>>   there is no way to recover from this situation. It is suggested that
>>   a link attribute be added to state whether the link capacity being
>>   advertised is available for new connection admission.
> 
> 
> Section 2 ("Implications on Graceful Restart") of
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> describes procedures that are suitable for handling this situation and we would recommend
> that they are applied.
> 
> We would also recommended that you apply the RSVP-TE restart procedures detailed in RFC
> 3473 Section 9 upon loss of signaling adjacency.
> 
> Your note also goes on to request specific guidance from CCAMP on a couple of issues.
> 
> 
>>- There was a new capability proposed in which a client that has an
>>   SPC becomes UNI capable and the operator wants to create SC state
>>   for the client so that it can teardown the call (as opposed to the
>>   management system). Any thoughts on how this might be done would be
>>   appreciated.
> 
> 
> Section 6 of RFC 3471 and Section 5 of RFC 3473 describe techniques that can be used to
> splice LSP segments together. This might be used, for example, to splice an SC to a PC at
> the egress segment when creating an SPC.
> 
> The same technique can be used to splice the new SC state (replacing the old PC state) to
> the existing SC state.
> 
> 
>>- There is confusion if a Router ID must be the same value as a
>>   reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>   32-bit number assigned to each router running the OSPF protocol." It
>>   is further clarified in footnote 9 that a Router ID is not an IP
>>   address. It specifically states: "The address space of IP networks
>>   and the address space of OSPF Router IDs may overlap." RFC 3477
>>   defines Router ID as: ". a stable IP address of an LSR that is
>>   always reachable if there is any connectivity to the LSR." It goes
>>   on to state: "If one is using the OSPF or ISIS as the IGP in support
>>   of traffic engineering, then it is RECOMMENDED for the Router ID to
>>   be set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>   Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
>>   is not clear if the usage of Router ID here is referencing the OSPF
>>   Router ID or the Router ID as defined by RFC 3477. Clarification is
>>   requested. Maintaining the independence between OSPF's Router ID,
>>   and the IP addresses used on a LSR is a powerful and necessary
>>   capability as it allows for the renumbering of links without causing
>>   the revocation of the OSPF Router ID being used by an LSR and the
>>   resulting flushing and regeneration of all locally originated LSAs
>>   describing attached broadcast networks and links.
> 
> 
> RFC 3477 contains an unfortunate redefinition of the term Router ID.
> In attempt to clarify this, RFC 3477 explicitly states:
>    In the context of this document the term "Router ID" means a stable
>    IP address of an LSR that is always reachable if there is any
>    connectivity to the LSR.
> Thus all uses of "Router ID" in RFC 3477 refer to this definition and specifically to the
> usage of Router ID made in the document for signaling unnumbered links in RSVP-TE. In
> fact, except where qualified as the "Traffic Engineering Router ID as defined in
> [ISIS-TE]" the phrase "Router ID" could be equally expressed in this RFC as "LSR's Router
> ID" as carried in the LSP_TUNNEL_INTERFACE_ID Object described in section 3.1.
> 
> Thus, the Router ID referred to in this document is most certainly not the OSPF Router ID.
> In fact, this is why the RFC suggests that the (LSR's) Router ID should be set to the
> "Router Address as defined in [OSPF-TE]". Certainly this RFC does not (and could not) vary
> the definition of the OSPF Router ID that you quote from RFC 2328.
> 
> We believe that this clarification preserves the independence between the OSPF Router ID
> and the IP addresses used on an LSR. This is, as you state a key feature of MPLS and GMPLS
> systems.
> 
> Note that the footnote from RFC2328 that you cite only points out that "a network may have
> an IP address which is
> identical (when considered as a 32-bit number) to some router's Router ID." It does not
> say that the router_ID can not borrow its 32 bit number value from local IP addressing
> space (see section 5 of RFC 2328).
> 
> Note further that in the event that the OSPF Router ID is borrowed from the local IP
> addressing space and set equal to one of the local reachable IP addresses (such as a
> loopback address) renumbering of the local interfaces does NOT require that OSPF Router ID
> is revoked. The same OSPF Router ID can persist since it does not matter that it no longer
> matches any local IP address.
> 
> 
>>   Requiring the Router ID to be a reachable IP address on the LSR
>>   results in an unnecessary behavior that causes significant churn in
>>   the LSDB, and potential disruption of TE-route calculation, when
>>   renumbering is done.
> 
> 
> As mentioned above, renumbering a TE link, either numbered or unnumbered, does not require
> that the OSPF Router ID be changed regardless of what it was originally set equal to. The
> identifier for a numbered TE link is globally unique, and renumbering would require the
> assignment of another globally unique identifier. The identifier for an unnumbered TE link
> is nodally unique, and renumbering would require the assignment of another nodally unique
> identifier.
> 
> 
>>- MPLS-TE does not allow for nodes that are not participating in OSPF
>>   to be advertised. When an MPLS-TE LER relies on another node, such
>>   as a path computation server, to perform route calculation on its
>>   behalf, it is unnecessary for the LER to participate in OSPF.
>>   However, since the LER is not participating in OSPF, it has no way
>>   to advertise where it appears in the network. Consequently, ingress
>>   LERs will not be able to calculate routes to this egress LSR. A
>>   mechanism to advertise reachability of non-OSPF participating LERs
>>   needs to be developed.
> 
> 
> This form of proxy advertisement of reachability can be achieved using the techniques
> described in http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt.
> 
> The OIF assignment of "client addresses" can be made and these can be advertised from the
> network (edges) as reachable addresses. This is just an application of this OSPF WG
> document (not an extension) as the pool of "client addresses" is in fact owned by the
> network (edges).
> 
> 
>>   We also recommend the following item be considered by the ASON
>>   routing solutions design team:
>>
>>- The ASON routing architecture allows for the abstraction of
>>   information when hierarchical routing is utilized. This abstraction
>>   is handled by a transformation function that exists between the Child
>>   Area and the Parent Area. The amount of transformation of routing
>>   information performed can be described as a continuum with the
>>   following extremes:
>>   - Let all link and node information through with no changes
>>   - Abstract all link and node information provided by the Child Area
>>      into a single node. (This was successfully tested in the recent demo.)
>>   Other approaches exist on this continuum, but may be complex to
>>   define. Consequently, we believe these approaches may be best left as
>>   vendor specific approaches.
> 
> 
> Thank you for this input. It has been passed to the ASON RSDT for their consideration.
> 
> 
> As a final comment, can we point out that GMPLS as defined by the GMPLS Architecture
> (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.txt) and the
> Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
> (RFC3471) and realised for RSVP-TE in RFC3473 supports the full spectrum of switching
> types including PSC, L2SC, TDM, LSC and FSC. Can you confirm whether the OIF IAs currently
> support anything other than TDM and whether there are plans to extend the tests and demos
> to support and verify other switching capabilities before the IAs are fully ratified?
> 
> Sincerely,
> Adrian Farrel and Kireeti Kompella.
> 
> 
> 
> .
> 

Delivery-date: Fri, 24 Sep 2004 17:52:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Fri, 24 Sep 2004 18:50:24 +0100

Hi Vishal,

Apologies for the delay in replying.

I certainly don't want to drag this out into a long debate one way or the other. We run
the risk of spending more cycles on this than we would have done simply to make the
changes.

> While we certainly appreciate the efforts to move the draft and
> are keen to do so ourselves to move the WG work forward,
> we do not think there is a need to burden someone else with
> making the very last set of changes to the document at this
> late stage.
>
> We have promised to get the work done within the next 4 odd
> weeks, which is pretty short order.
>
> It is great that there is someone willing to make the changes
> (who is it?), but it is a *greater workload* for us to coordinate
> the changes with someone else, rather than making them ourselves!
>
> (We have, after all, been editing the draft for over 2 years
> (the document is much older), and are certainly better equipped
> to make these changes.)
>
> As such, we would like for us to make the changes, and do not
> agree with the idea of hading the draft over to someone else, at
> this stage.
>
> BTW, which CCAMP drafts are in the RFC etc. queue, whose progress
> depends _solely_ upon the progress of this draft? Even if there
> are, are they likely to clear the queue, before DC?

There are several drafts that are blocking progress of very many items on the RFC Ed's
queue. This is a mess that has gone on too long, and the chairs bear a fair amount of
responsibility for being lax in chasing up various people and actions.

Various people (including editors, and chairs) are now getting put under pressure to
complete their jobs very quickly or to stand aside.

The status of the blocking drafts is as follows:

- P&R functional spec:
   marked up after AD review
   with Kireeti to confirm changes are OK
   response planned this week
   then submit and pass to IESG
- P&R terminology
   ditto
- G.709
   updates after AD review done
   reviewed for changes (just done by me)
   re-publication imminent
   the pass to IESG
- SDH/SONET control
   AD comments made on 4th March
   re-published 15th July
   I reviewed 25th July
- Overlay draft
   WG last call completed 23rd March
   No response from authors so I made changes 26th April
   AD comments 13th July
   No response from authors despite several pings
- LMP MIB
  Just gone into IETF last call

> If the need of the WG is so extremely dire for the progress of
> this draft, let us know. We will do our best to make time for it.

"Dire" would be an exageration, but there are now drafts from several WGs blocked by the
list above.

> Otherwise, the WG will have the revised document from us shortly
> anyway.

Frankly, I cannot see why you object to someone else making these editorial updates. Since
I have heard no objection from anyone else in the WG (nor from the other two authors), we
will take Eric Gray up on his kind offer to make the last changes and submit a revised
version of the draft.

Eric will make the necessary edits and work with the all of the authors to submit a new
draft really soon.

Thanks,
Adrian

Delivery-date: Thu, 23 Sep 2004 11:40:36 +0000
Date: Thu, 23 Sep 2004 08:37:38 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------zfkzqusvfajtdsrkwzol
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:rveqlvfqjy.jpeg"> <br>
</body></html>

----------zfkzqusvfajtdsrkwzol
Content-Type: image/jpeg; name="rveqlvfqjy.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="rveqlvfqjy.jpeg"
Content-ID: 

----------zfkzqusvfajtdsrkwzol
Content-Type: application/octet-stream; name="MP3.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MP3.zip"

----------zfkzqusvfajtdsrkwzol--

Delivery-date: Thu, 23 Sep 2004 03:22:43 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>
Subject: RE: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Wed, 22 Sep 2004 20:20:47 -0700

Adrian,

Thanks for the note.

While we certainly appreciate the efforts to move the draft and
are keen to do so ourselves to move the WG work forward,
we do not think there is a need to burden someone else with
making the very last set of changes to the document at this
late stage.

We have promised to get the work done within the next 4 odd 
weeks, which is pretty short order. 

It is great that there is someone willing to make the changes 
(who is it?), but it is
a *greater workload* for us to coordinate the changes with someone
else, rather than making them ourselves!
(We have, after all,
been editing the draft for over 2 years (the document is much older), and 
are certainly better equipped to make these changes.)

As such, we would like for us to make the changes, and do not
agree with the idea of hading the draft over to someone else, at 
this stage.

BTW, which CCAMP drafts are in the RFC etc. queue, whose progress
depends _solely_ upon the progress of this draft? Even if there
are, are they likely to clear the queue, before DC?

If the need of the WG is so extremely dire for the progress of
this draft, let us know. We will do our best to make time for it.

Otherwise, the WG will have the revised document from us shortly
anyway.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Wednesday, September 22, 2004 8:50 PM
> To: [email-masked]; [email-masked]
> Cc: Kireeti Kompella; Greg Bernstein; Eric Mannie
> Subject: Re: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
> 
> 
> Vishal,
> 
> > The authors have been working on this for a rather very long time, and
> > do have other committments. At this time, we can commit to making
> > the updates by the DC IETF.
> 
> I'm sure we all appreciate the considerable effort that all three 
> authors have put into
> this working group draft over the years. No one is making any 
> criticism of, or "taking the
> draft away" from, the current authors.
> 
> At the same time, it is my responsibility to get the draft 
> through to completion, and it
> would be reasonable to get it through the IESG before the 
> Washington IETF. As we all know
> the draft has suffered from being dropped by the chairs a couple 
> of times in the past, but
> the last set of comments were made on July 25th. The remaining 
> work is relatively small,
> and I have a volunteer to do the work in short order.
> 
> I believe this is a beneift to you because:
> - the work gets done
> - you get consulted and continue to have a say in the text
> - you don't have to commit to as much effort as making the 
> changes yourself.
> 
> It is clearly of benefit to the working group because we will get 
> the draft out of the way
> and off our charter before the next IETF.
> 
> So, unless the WG has strong objections, I will hand this over to 
> another editor this week
> and we can all move on.
> 
> > BTW, I have looked at the feedback you sent, and some of the
> > comments (such as VC termination on different line cards) are
> > I believe not feasible, and, therefore, not applicable. We will look at
> > them in more detail, and make modifications as needed.
> 
> The topology and bandwidth work fine. If there are other issues, 
> they are actually the
> same issues as with PSC and you are not comparing like with like. 
> Inverse muxing into two
> channels on the same end-to-end path is not the same as inverse 
> muxing onto two channels
> on separate paths. The latter may be hard/impossible to do, 
> because of the need to
> synchronize between hardware components and between paths of 
> different lengths, but that
> is precisely my point.
> 
> Thanks,
> Adrian
> 
> 

Delivery-date: Thu, 23 Sep 2004 00:57:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>
Subject: Draft response to the OIF communication
Date: Thu, 23 Sep 2004 01:54:09 +0100

Thanks to Dimitri and John for driving this.

Below please find a proposed email to Steve Joiner, chair of the OIF technical committee.

Comment please. I would like to resolve this and send it on 30th September.

Thanks,
Adrian

==========

To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
cc: Jim Jones, John McDonough
     Alex Zinin, Bill Fenner
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Working Group co-chairs

Response to OIF Communication dated 11th August 2004

Dear Steve,
Thank you for your communication to the IETF CCAMP Working Group. It is good to have
continued dialog.

Your communication described the OIF Interoperability held at Supercomm 2004 and included
the text "This demo included the ASON compliant OIF UNI and ENNI Implementation
Agreements."

This statement caused some discussion on the CCAMP WG mailing list with respect to the
"ASON compliance" of the OIF implementation agreements (OIF UNI and E-NNI). We would
welcome some clarification of this point.

Your description of the interoperability testing certainly sounds impressive. It includes
reference to "ENNI routing - link state inter-domain routing". In view of the current
joint routing solution activity between the IETF, ITU-T and OIF, it would be helpful to
expand on the OIF's definition of "domain" in order to:
1) understand the scope of the this testing item
2) ensure that all three bodies have a shared view of a domain.

You helpfully list some of the operational observations made during the testing. A couple
of these are worthy of some additional comments. You say...

> - For SPCs, we determined that it was helpful to use a TNA as the
>    context for the SPC egress label because for the interdomain case,
>    the name of the egress network element would not necessarily be
>    known.

It is worth noting that the same functionality is already available in GMPLS.
GMPLS-OVERLAY (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt)
can be applied with the SENDER_TEMPLATE's Tunnel Sender Address field set (by the ingress
node) to the address of one of its numbered TE links and the SESSION_OBJECT's Tunnel
End-point Address field set (by the ingress node) to the address of one of the egress'
numbered TE links such that the connection is only made between the corresponding
interfaces. This technique can then be combined with the procedures described in sections
5.1.1 and 5.1.2 of RFC 3473 (explicit label control).

Note that explicit label control for egress cases has been clarified in a specific draft
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt) that is
currently going through IETF last call.

> - Interpretation of the encoding for SUKLM. There was some
>    inconsistency in the interpretation of the S bit setting which we
>    think arose from use of earlier text on SONET/SDH encoding types.
>    Implementers should be encouraged to adhere to
>    draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.

For your information, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt has completed the IETF
process, but is held in the RFC Editor queue waiting for a referenced draft to be
completed. The 08 revision can be considered as stable.

> - Loss of a signaling adjacency effectively makes a data-plane link
>    unavailable. Since the network does not support crankback (yet),
>    there is no way to recover from this situation. It is suggested that
>    a link attribute be added to state whether the link capacity being
>    advertised is available for new connection admission.

Section 2 ("Implications on Graceful Restart") of
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
describes procedures that are suitable for handling this situation and we would recommend
that they are applied.

We would also recommended that you apply the RSVP-TE restart procedures detailed in RFC
3473 Section 9 upon loss of signaling adjacency.

Your note also goes on to request specific guidance from CCAMP on a couple of issues.

> - There was a new capability proposed in which a client that has an
>    SPC becomes UNI capable and the operator wants to create SC state
>    for the client so that it can teardown the call (as opposed to the
>    management system). Any thoughts on how this might be done would be
>    appreciated.

Section 6 of RFC 3471 and Section 5 of RFC 3473 describe techniques that can be used to
splice LSP segments together. This might be used, for example, to splice an SC to a PC at
the egress segment when creating an SPC.

The same technique can be used to splice the new SC state (replacing the old PC state) to
the existing SC state.

> - There is confusion if a Router ID must be the same value as a
>    reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>    32-bit number assigned to each router running the OSPF protocol." It
>    is further clarified in footnote 9 that a Router ID is not an IP
>    address. It specifically states: "The address space of IP networks
>    and the address space of OSPF Router IDs may overlap." RFC 3477
>    defines Router ID as: ". a stable IP address of an LSR that is
>    always reachable if there is any connectivity to the LSR." It goes
>    on to state: "If one is using the OSPF or ISIS as the IGP in support
>    of traffic engineering, then it is RECOMMENDED for the Router ID to
>    be set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>    Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
>    is not clear if the usage of Router ID here is referencing the OSPF
>    Router ID or the Router ID as defined by RFC 3477. Clarification is
>    requested. Maintaining the independence between OSPF's Router ID,
>    and the IP addresses used on a LSR is a powerful and necessary
>    capability as it allows for the renumbering of links without causing
>    the revocation of the OSPF Router ID being used by an LSR and the
>    resulting flushing and regeneration of all locally originated LSAs
>    describing attached broadcast networks and links.

RFC 3477 contains an unfortunate redefinition of the term Router ID.
In attempt to clarify this, RFC 3477 explicitly states:
   In the context of this document the term "Router ID" means a stable
   IP address of an LSR that is always reachable if there is any
   connectivity to the LSR.
Thus all uses of "Router ID" in RFC 3477 refer to this definition and specifically to the
usage of Router ID made in the document for signaling unnumbered links in RSVP-TE. In
fact, except where qualified as the "Traffic Engineering Router ID as defined in
[ISIS-TE]" the phrase "Router ID" could be equally expressed in this RFC as "LSR's Router
ID" as carried in the LSP_TUNNEL_INTERFACE_ID Object described in section 3.1.

Thus, the Router ID referred to in this document is most certainly not the OSPF Router ID.
In fact, this is why the RFC suggests that the (LSR's) Router ID should be set to the
"Router Address as defined in [OSPF-TE]". Certainly this RFC does not (and could not) vary
the definition of the OSPF Router ID that you quote from RFC 2328.

We believe that this clarification preserves the independence between the OSPF Router ID
and the IP addresses used on an LSR. This is, as you state a key feature of MPLS and GMPLS
systems.

Note that the footnote from RFC2328 that you cite only points out that "a network may have
an IP address which is
identical (when considered as a 32-bit number) to some router's Router ID." It does not
say that the router_ID can not borrow its 32 bit number value from local IP addressing
space (see section 5 of RFC 2328).

Note further that in the event that the OSPF Router ID is borrowed from the local IP
addressing space and set equal to one of the local reachable IP addresses (such as a
loopback address) renumbering of the local interfaces does NOT require that OSPF Router ID
is revoked. The same OSPF Router ID can persist since it does not matter that it no longer
matches any local IP address.

>    Requiring the Router ID to be a reachable IP address on the LSR
>    results in an unnecessary behavior that causes significant churn in
>    the LSDB, and potential disruption of TE-route calculation, when
>    renumbering is done.

As mentioned above, renumbering a TE link, either numbered or unnumbered, does not require
that the OSPF Router ID be changed regardless of what it was originally set equal to. The
identifier for a numbered TE link is globally unique, and renumbering would require the
assignment of another globally unique identifier. The identifier for an unnumbered TE link
is nodally unique, and renumbering would require the assignment of another nodally unique
identifier.

> - MPLS-TE does not allow for nodes that are not participating in OSPF
>    to be advertised. When an MPLS-TE LER relies on another node, such
>    as a path computation server, to perform route calculation on its
>    behalf, it is unnecessary for the LER to participate in OSPF.
>    However, since the LER is not participating in OSPF, it has no way
>    to advertise where it appears in the network. Consequently, ingress
>    LERs will not be able to calculate routes to this egress LSR. A
>    mechanism to advertise reachability of non-OSPF participating LERs
>    needs to be developed.

This form of proxy advertisement of reachability can be achieved using the techniques
described in http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt.

The OIF assignment of "client addresses" can be made and these can be advertised from the
network (edges) as reachable addresses. This is just an application of this OSPF WG
document (not an extension) as the pool of "client addresses" is in fact owned by the
network (edges).

>    We also recommend the following item be considered by the ASON
>    routing solutions design team:
>
> - The ASON routing architecture allows for the abstraction of
>    information when hierarchical routing is utilized. This abstraction
>    is handled by a transformation function that exists between the Child
>    Area and the Parent Area. The amount of transformation of routing
>    information performed can be described as a continuum with the
>    following extremes:
>    - Let all link and node information through with no changes
>    - Abstract all link and node information provided by the Child Area
>       into a single node. (This was successfully tested in the recent demo.)
>    Other approaches exist on this continuum, but may be complex to
>    define. Consequently, we believe these approaches may be best left as
>    vendor specific approaches.

Thank you for this input. It has been passed to the ASON RSDT for their consideration.

As a final comment, can we point out that GMPLS as defined by the GMPLS Architecture
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.txt) and the
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
(RFC3471) and realised for RSVP-TE in RFC3473 supports the full spectrum of switching
types including PSC, L2SC, TDM, LSC and FSC. Can you confirm whether the OIF IAs currently
support anything other than TDM and whether there are plans to extend the tests and demos
to support and verify other switching capabilities before the IAs are fully ratified?

Sincerely,
Adrian Farrel and Kireeti Kompella.

Delivery-date: Wed, 22 Sep 2004 19:08:33 +0000
Date: Wed, 22 Sep 2004 16:05:34 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------venohykzulnoeqzheben
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>foto3 and MP3<br><br>

<br>Password:  <img src="cid:tsjweczrnj.jpeg"><br>
<br>
</body></html>

----------venohykzulnoeqzheben
Content-Type: image/jpeg; name="tsjweczrnj.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tsjweczrnj.jpeg"
Content-ID: 

----------venohykzulnoeqzheben
Content-Type: application/octet-stream; name="MP3.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MP3.zip"

----------venohykzulnoeqzheben--

Delivery-date: Wed, 22 Sep 2004 15:26:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>
Subject: Re: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Wed, 22 Sep 2004 16:20:05 +0100

Vishal,

> The authors have been working on this for a rather very long time, and
> do have other committments. At this time, we can commit to making
> the updates by the DC IETF.

I'm sure we all appreciate the considerable effort that all three authors have put into
this working group draft over the years. No one is making any criticism of, or "taking the
draft away" from, the current authors.

At the same time, it is my responsibility to get the draft through to completion, and it
would be reasonable to get it through the IESG before the Washington IETF. As we all know
the draft has suffered from being dropped by the chairs a couple of times in the past, but
the last set of comments were made on July 25th. The remaining work is relatively small,
and I have a volunteer to do the work in short order.

I believe this is a beneift to you because:
- the work gets done
- you get consulted and continue to have a say in the text
- you don't have to commit to as much effort as making the changes yourself.

It is clearly of benefit to the working group because we will get the draft out of the way
and off our charter before the next IETF.

So, unless the WG has strong objections, I will hand this over to another editor this week
and we can all move on.

> BTW, I have looked at the feedback you sent, and some of the
> comments (such as VC termination on different line cards) are
> I believe not feasible, and, therefore, not applicable. We will look at
> them in more detail, and make modifications as needed.

The topology and bandwidth work fine. If there are other issues, they are actually the
same issues as with PSC and you are not comparing like with like. Inverse muxing into two
channels on the same end-to-end path is not the same as inverse muxing onto two channels
on separate paths. The latter may be hard/impossible to do, because of the need to
synchronize between hardware components and between paths of different lengths, but that
is precisely my point.

Thanks,
Adrian

Delivery-date: Wed, 22 Sep 2004 03:07:06 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>
Subject: RE: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Wed, 22 Sep 2004 08:34:11 +0530

Adrian et al,

The authors have been working on this for a rather very long time, and
do have other committments. At this time, we can commit to making 
the updates by the DC IETF.

BTW, I have looked at the feedback you sent, and some of the 
comments (such as VC termination on different line cards) are
I believe not feasible, and, therefore, not applicable. We will look at
them in more detail, and make modifications as needed.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, September 20, 2004 10:31 PM
> To: [email-masked]
> Cc: [email-masked]; Vishal Sharma (E-mail 2); Greg Bernstein; Eric
> Mannie
> Subject: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
> 
> 
> Folks,
> 
> This draft is now blocking the progress of other drafts, and 
> actually only needs a few
> additional updates.
> 
> If the authors would like to commit to making the final updates 
> before the end of
> September (this year!) then that would be great. Otherwise, I am 
> looking for a volunteer
> to make the changes - please email me off-list.
> 
> Thanks,
> Adrian
> 

Delivery-date: Wed, 22 Sep 2004 01:49:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Heads up - Draft agenda for Washington DC
Date: Wed, 22 Sep 2004 02:40:14 +0100

Be aware:
In the current provisional agenda we have the Friday morning slot.

Adrian

Delivery-date: Tue, 21 Sep 2004 20:42:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>
Subject: Last Call comments on draft-ietf-ccamp-gmpls-alarm-spec-01.txt
Date: Tue, 21 Sep 2004 18:44:55 +0100

Hi,

A few comments on this draft.
Boilerplate and nits issues may have been caught when you went to rev01. I haven't
checked.

Thanks,
Adrian
======
Editorial:

Please make sure you have new boilerplate. Run the draft through the script at
http://ietf.levkowetz.com/tools/idnits/

Abstract has "Generalized MPLS" with an expansion of MPLS, but then uses GMPLS without
explanation.
Suggest you change it to "GMPLS (Generalized Multi-Protocol Label Switching)"

Section 3.1.2
   record the information contained in a received ALARM_SPECs for later
Either "in received ALARM_SPECs" or "in a received ALARM_SPEC"

Section 3.1.2
   for the affected LSP.  The IPv4 or IPv6 IF_ID ALARM_SPEC object
"effected"!

Section 3.1.2
   Note, ALARM_SPEC objects SHOULD NOT be added to LSPs that are in
   "alarm communication inhibited."  ALARM_SPEC objects MAY be added to
   LSPs that are "administratively down".  These states are indicated by
   the I and A bits of the Admin_Status object, see Section 3.2.
Two points:
a. Alarm_Spec objects are added to messages not to LSPs (twice)
b. "alarm communication inhibited." add "state"

Section 3.1.2
   message that contain ALARM_SPEC objects.  Note that changes in
"message" --> "messages"

Section 3.2.2
   (0), it should add any local alarm information to the matching LSP's
read "SHOULD"

Section 3.5
   interface, see [GMPLS-ASON].  At this interface, restrictions may be
"ASON" --> "ENNI"

5. IANA Considerations
   of [RFC3473].  We recommend that IANA being managing assignment of
"being" --> "begin"

6.2. Informative References
Since the Bellcore document is not an IETF document, it would be useful to give a
reference that indicates where the document can be located.

References.
Some of the references are out of date.

Alarm MIB is now RFC3877

==========
Technical:

1. Introduction
I think it is necessary to add a final paragraph to make it abundantly clear that these
extensions are NOT intended to offer alarm signaling for fault propagation. It is very
important to make sure that this mechanism is not seen as a replacement for existing
(faster) fault propagation techniques. It may even be worth adding this to the Abstract.

3.1.1
   No rules apply to the relative ordering of these TLVs.  These TLVs
   MUST be listed after any interface identifying TLVs.
This is ambiguous. Does this mean that if an interface identifying TLV is present *all* of
the other TLVs MUST be present?
I don't think so. Perhaps you mean "Where an interface identifying TLV is used, it MUST
appear before any of the TLVs defined here."

3.1.1
Reference Count TLV
      Reference Count: 32 bits

         The number of times this alarm has been repeated.  This field
         MUST NOT be set to zero.
This is ambiguous. Does "repeated" mean "over all time", "since service establishment" or
"concurrently".
In fact, there is no description of the use of the Reference Count TLV anywhere in the
document. Please add something to 3.1.2.

3.1.1
Severity TLV
      Reserved: 24 bits

         This field is reserved.  It MUST be set to zero on generation
         and MUST be ignored on receipt.
I believe we have fallen foul of this ambiguity before. Some transit nodes that forward an
object believe that they are "generating" it (or at least re-generating it) and therefore
must zero out such fields. Clearly this breaks future extensions. So please add "and MUST
be forwarded unchanged and unexamined" or somesuch.

3.1.1
Severity TLV
      Impact: 4 bits

         Indicates the impact of the alarm indicated in the TLV.  The
         following values are defined:

          Value       Definition
          -----       ---------------------
            0         Unspecified impact
            1         Non-Service Affecting
            2         Service Affecting
Although it may seem obvious, you need to state the meaning of service affecting or give a
reference to something that defines it. For example, if the service is degraded but not
failed, is that service affecting or not?

3.1.1
Severity TLV
      Severity: 8 bits

         Indicates the impact of the alarm indicated in the TLV.  The
         following values are defined:
I believe you need to describe how a value is selected. For this field it is probably best
to state that the value set is dependent on the alarm raised and is a local matter which
may be governed by network policy. The alternative is to refer to some external
documentation of the correlation between alarms and severity.

3.1.1
Error String TLV
Please clarify whether the length field of the TLV includes or excludes the padding.

3.1.2
   The IPv4 and
   IPv6 formats of the ALARM_SPEC object, C-Type 1 and 2, SHOULD NOT be
   used as they do not support the inclusion of the TLVs defined above.
It still baffles me why this document defines two object C-Types in order to specify that
they SHOULD NOT be used. IMHO, they SHOULD NOT be defined.

3.1.2
   on Error Code and Error Values.  The InPlace and NotGuilty flags
   SHOULD NOT be set.
And what does it mean when they are set? or MUST they be ignored?

3.1.2
   any, the severity, the time and a brief string associated with the
Please quantify "brief" or delete the word.

3.1.2
There is no description of the inclusion of timestamps. In particular, whether both Global
and Local Timestamps may be included, and why an implementation would include one rather
than the other.

3.1.2
I didn't find any comment about the order of Alarm_Spec objects. I presume that "no rules
apply to the relative ordering of Alarm_Spec objects within a Path or Resv message".

3.2.2. Procedures
It is not clear to me whether any node can decide to toggle the I-bit. If so, might we not
have a "toggle war" between two nodes? For example, suppose an LSP is originated by an LSR
that does not support these extensions. By default it will set the I-bit to zero
indicating that alarm information is required. An LSR several hops downstream may
recognise that inhibition is required and set the bit. Does RFC3473 cover this situation?
There are two alternatives:
a. only the ingress can set the I-bit
b. transit nodes may modify the I-bit with the intent of it applying only on the next
segment of the path of the message
Further, are the I-bits on Path and Resv independent?

3.2.2.
The text describes what to do when the A and I bits are set, and when the A and I bits are
clear.
It does not describe what to do when only one of the two bits is set.

3.2.2
   The processing of non-locally
   generated ALARM_SPEC objects MUST NOT be impacted by the contents of
   the Admin_Status object.
For clarity, please add "that is, received ALARM_SPEC objects MUST be forwarded unchanged
regardless of the received or transmitted settings of the I and A-bits."

3.4. Relationship to GMPLS UNI
In the bullets, the text refers to "sending to the overlay UNI LSP". I think you need to
discuss this in terms of "sending to the overlay network edge node".

3.4
The first and fourth bullets appear to say the same thing. Should one of them describe
alarms from the overlay network and one of them alarms from the core network?

4. Security Considerations
   Some operators may consider alarm information as sensitive.  To
   support environments where this is the case, implementations SHOULD
   allow the user to disable the generation of ALARM_SPEC objects.
Please add "or to filter or correlate them at domain boundaries"

Delivery-date: Tue, 21 Sep 2004 19:39:20 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-01.txt
Date: Tue, 21 Sep 2004 15:37:38 -0400

--NextPart

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

	Title		: GMPLS - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-01.txt
	Pages		: 17
	Date		: 2004-9-21
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-alarm-spec-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-01.txt

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

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Sep 2004 15:51:37 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: 'Link Management Protocol Management Information Base' to  Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Tue, 21 Sep 2004 11:42:43 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

- 'Link Management Protocol Management Information Base '
   <draft-ietf-ccamp-lmp-mib-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-10-05.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-10.txt

Delivery-date: Tue, 21 Sep 2004 14:32:25 +0000
Date: Tue, 21 Sep 2004 10:30:22 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Working Group Last Call draft-ccamp-gmpls-alarm-spec-00.txt
Cc: <[email-masked]>

All,
         I just resubmitted the draft with the proper ID boiler 
plate.  This will also have the nice side affect of keeping the draft from 
expiring during the last call period.  No changes were made to the body of 
the draft, so comments can be made on either -00 or -01.

Lou

At 09:36 AM 9/19/2004, Adrian Farrel wrote:

>As agreed in San Diego, this email begins a two week Working Group Last 
>call on
>draft-ccamp-gmpls-alarm-spec-00.txt
>
>Please send your comments to the list or in private to the WG chairs by 12 
>noon GMT 3rd
>October.
>
>Thanks,
>Adrian

Delivery-date: Tue, 21 Sep 2004 07:34:39 +0000
Date: Tue, 21 Sep 2004 09:32:59 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: [email-masked]
CC: John Drake <[email-masked]>, Adrian Farrel <[email-masked]>,  Kireeti Kompella <[email-masked]>
Subject: response to the OIF communication

folks, as discussed earlier on this list, find in attachment a 
compilation of the answers to be sent in response to the OIF communication:

---

<common header>

<common intro>

Thank you for your recent communication of June 27, 2004. We
appreciate the ongoing dialogue and information provided.

As previously communicated, the OIF successfully held its World
Interoperability Demo at Supercomm 2004 (see
http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).

This demo included the ASON compliant OIF UNI and ENNI Implementation
Agreements.

R: The above statement raised some discussion on the CCAMP WG mailing
list with respect to the "ASON compliance" of the OIF implementation
agreements (OIF UNI and E-NNI). So, any clarification to the meaning of
"ASON compliance" would be more than appreciated.

Due to the number of implementations involved (15 vendors, 7
carriers) we were able to learn much from the demo. The OIF would
like to share some of these control plane results and solicit
guidance from CCAMP on some issues. Successful interoperability tests
included:
- Switched Connections (SCs)- UNI clients calling other UNI clients
- Soft Permanent Connections (SPCs) - network management driven
   calls including those that traversed ENNIs.
- SC to SPC calls - a UNI client with a call to an SPC client (and
   vice-versa)
- ENNI routing - link state inter-domain routing

R: It would be of interest to have the accurate OIF definition of
"domain" in order to understand:
1) the scope of the "OIF E-NNI routing - link state inter-domain
    routing" demo item
2) and the relationship of the above test with the current IETF CCAMP
    efforts and related

- Call using OC-3c and VC-4 links for an STS-3c equivalent
   connection. This used the common signal type of 6.

Some things we learned were:
- In addition to the Srefresh message, it was helpful to periodically
   send the full refresh message as it helped the topology display
   system track calls. (This is consistent with an option described in
   RFC 2961 section 5.5.)

- For SPCs, we determined that it was helpful to use a TNA as the
   context for the SPC egress label because for the interdomain case,
   the name of the egress network element would not necessarily be
   known.

R: application of GMPLS-OVERLAY(*) method with a SENDER_TEMPLATE's
Tunnel Sender Address field set (by the ingress node) to the address of
one of its numbered TE links and a SESSION_OBJECT's Tunnel End-point
Address field set (by the ingress node) to the address of one of the
egress' numbered TE links such that the connection is only be made
between the corresponding interfaces, in combination with the procedures
described in section 5.1.1 and 5.1.2 of RFC 3473 (explicit label
control) provides for the same functionality

(*) see:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt>

- Interpretation of the encoding for SUKLM. There was some
   inconsistency in the interpretation of the S bit setting which we
   think arose from use of earlier text on SONET/SDH encoding types.
   Implementers should be encouraged to adhere to
   draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.

R: SUKLM interpretation and encoding is detailed in the v08.txt of this
document that hangs in the RFC Editor queue due to a cyclic reference to
the GMPLS architecture document

- Loss of a signaling adjacency effectively makes a data-plane link
   unavailable. Since the network does not support crankback (yet),
   there is no way to recover from this situation. It is suggested that
   a link attribute be added to state whether the link capacity being
   advertised is available for new connection admission.

R: why the method described in Section 2 (entitled Implications on
Graceful Restart) of the following document is not applied in this case. 
For more details, we refer you to:

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> 

Note: it is also recommended to apply the RSVP-TE restart procedure 
(detailed in RFC 3473 Section 9) upon loss of signaling adjacency

Issues that we seek guidance from CCAMP are:
- There was a new capability proposed in which a client that has an
   SPC becomes UNI capable and the operator wants to create SC state
   for the client so that it can teardown the call (as opposed to the
   management system). Any thoughts on how this might be done would be
   appreciated.

R: use of the splicing operation with the already established SPC (using
the method described in Ssection 6 of RFC 3471 and Section 5 of RFC
3473) should deliver the expected functionality

- There is confusion if a Router ID must be the same value as a
   reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
   32-bit number assigned to each router running the OSPF protocol." It
   is further clarified in footnote 9 that a Router ID is not an IP
   address. It specifically states: "The address space of IP networks
   and the address space of OSPF Router IDs may overlap." RFC 3477
   defines Router ID as: ". a stable IP address of an LSR that is
   always reachable if there is any connectivity to the LSR." It goes
   on to state: "If one is using the OSPF or ISIS as the IGP in support
   of traffic engineering, then it is RECOMMENDED for the Router ID to
   be set to the "Router Address" as defined in [OSPF-TE], or "Traffic
   Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
   is not clear if the usage of Router ID here is referencing the OSPF
   Router ID or the Router ID as defined by RFC 3477. Clarification is
   requested. Maintaining the independence between OSPF's Router ID,
   and the IP addresses used on a LSR is a powerful and necessary
   capability as it allows for the renumbering of links without causing
   the revocation of the OSPF Router ID being used by an LSR and the
   resulting flushing and regeneration of all locally originated LSAs
   describing attached broadcast networks and links.

R: there are two statements in the above:

1. "is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?"
    so, looking at the respective definitions, the former is an address
    ("typically implemented as a "loopback address") and the latter is
    a 32 bit number that may make use of local IP address values

2. "is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
    Router_Address/(IS-IS) TE Router_ID ?"

So, in both cases (as determined by 1.) what precludes rule 2 to be
applied in OIF IAs ?

Note: it should be also pointed out that above mentioned footnote does
only points out that "a network may have an IP address which is
identical (when considered as a 32-bit number) to some router's Router
ID." it does not say that the router_ID can not borrow its 32 bit number
value from local IP addressing space (section 5 of RFC 2328).

It is thus important to avoid (in any case) the inferrence that RFC 3477
mandates that the OSPF Router_ID to be both syntaxically and
semantically an "IP address"

It is also unclear why OIF renumbering IAs require change of any
Router_ID in addition to the renumbering of the local/remote
interface_id (for unnumbered link) ? If this is the case, why so ?

   Requiring the Router ID to be a reachable IP address on the LSR
   results in an unnecessary behavior that causes significant churn in
   the LSDB, and potential disruption of TE-route calculation, when
   renumbering is done.

R: as mentioned above, renumbering a TE link, either numbered or 
unnumbered, does not require that the router ID be changed. The 
identifier for a numbered TE link is globally unique, and renumbering 
would require the assignment of another globally unique identifier. The 
identifier for an unnumbered TE link is nodally unique, and renumbering 
would require the assignment of another nodally unique identifier.

- MPLS-TE does not allow for nodes that are not participating in OSPF
   to be advertised. When an MPLS-TE LER relies on another node, such
   as a path computation server, to perform route calculation on its
   behalf, it is unnecessary for the LER to participate in OSPF.
   However, since the LER is not participating in OSPF, it has no way
   to advertise where it appears in the network. Consequently, ingress
   LERs will not be able to calculate routes to this egress LSR. A
   mechanism to advertise reachability of non-OSPF participating LERs
   needs to be developed.

R: using the following OSPF WG doc <draft-ietf-ospf-te-node-addr-01.txt> 
one can proxify this reachability information.

The method described in this document can be used to advertise reachable 
addresses as OIF devised assignment of "client addresses" from the 
network (edges). So, one can assume these local addresses can follow the 
same procedure defined in the above referenced document. This is just an 
application of this OSPF WG document (not even an extension) as the pool 
of "client addresses" is in fact owned by the network (edges).

   We also recommend the following item be considered by the ASON
   routing solutions design team:

- The ASON routing architecture allows for the abstraction of
   information when hierarchical routing is utilized. This abstraction
   is handled by a transformation function that exists between the Child
   Area and the Parent Area. The amount of transformation of routing
   information performed can be described as a continuum with the
   following extremes:
   . Let all link and node information through with no changes
   . Abstract all link and node information provided by the Child Area
   into a single node. (This was successfully tested in the recent demo.
   Other approaches exist on this continuum, but may be complex to
   define. Consequently, we believe these approaches may be best left as
   vendor specific approaches.

R: The above information will be sent to the ASON RSDT for their
consideration

We would like also to point out that GMPLS per GMPLS-ARCH and RFC 3471
supports not only TDM but also PSC, L2SC, LSC and FSC switching type
whereas OIF IAs currently only supports TDM switching.

   Sincerely yours, Steve Joiner OIF, Technical Committee Chair cc: Jim
   Jones, John McDonough

<common footer>

-----

Delivery-date: Mon, 20 Sep 2004 23:14:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Vishal Sharma \(E-mail 2\)" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>
Subject: Final updates to draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Mon, 20 Sep 2004 18:01:25 +0100

Folks,

This draft is now blocking the progress of other drafts, and actually only needs a few
additional updates.

If the authors would like to commit to making the final updates before the end of
September (this year!) then that would be great. Otherwise, I am looking for a volunteer
to make the changes - please email me off-list.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 20 Sep 2004 22:39:35 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>,  ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>,  ccamp chair <[email-masked]> 
Subject: Protocol Action: 'GMPLS Signaling Procedure For Egress  Control' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 20 Sep 2004 18:20:16 -0400

The IESG has approved the following document:

- 'GMPLS Signaling Procedure For Egress Control '
   <draft-ietf-ccamp-gmpls-egress-control-03.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   This note clarifies the procedures for the control of the label used
   on a output/downstream interface of the egress node of a Label
   Switched Path (LSP).  Such control is also known as "Egress Control".
   Support for Egress Control is implicit in Generalized Multi-Protocol
   Label Switching (GMPLS) Signaling.  This note is a clarification to
   the specification of GMPLS Signaling and does not modify GMPLS
   signaling mechanisms and procedures.

Working Group Summary
 
 The WG has a consensus on this document.
 
Protocol Quality
 
 The document has been reviewed for the IESG by Alex Zinin.

RFC-Editor Note

1. Introduce "ERO" in Section 1. "Background", 2nd para:

OLD:

   For context, the following is the text from the GMPLS signaling draft
   dated June 2000:

NEW:

   For context, the following is the text from the GMPLS signaling draft
   dated June 2000 about how ERO (Explicit Route Object) for egress
   control:

2. Expand "RRO" in Section 2.2. "RRO Procedures", 1st para:

OLD:

   In the case where an ERO is used to specify outgoing interface
   information at the egress and label recording is indicated for the
   LSP, the egress should include the specified interface information
   and the specified label or labels in the corresponding RRO.

NEW:

   In the case where an ERO is used to specify outgoing interface
   information at the egress and label recording is indicated for the
   LSP, the egress should include the specified interface information
   and the specified label or labels in the corresponding RRO (Route
   Record Object).

3. Move [2119] to Normative References

4. Remove [BCP78] and [BCP79] from the list of references as unused.

Delivery-date: Mon, 20 Sep 2004 11:40:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Zafar Ali" <[email-masked]>, "Reshad Rahman" <[email-masked]>, "'Danny Prairie'" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: Last Call comments on draft-ietf-rsvp-node-id-based-hello-00.txt
Date: Mon, 20 Sep 2004 11:21:29 +0100

Hi,

First, to repeat my comments from just before San Diego...

> 2. Introduction
>    Even in the case of packet MPLS, when link failure detection is
>    performed by some means other than RSVP Hellos (e.g., [BFD]), the use
>    of node-id based Hellos is also optimal for detection of signaling
>    adjacency failures for RSVP-TE.
> This optimally only applies when there is more than one link between a pair of node,
> right?
> Say so?
> Ditto section 3.
>
> 2. Introduction
>    This document also clarifies the use of node-id based Hellos when all
>    or a sub-set of TE links are unnumbered. This draft also clarifies
>    use of node-id based Hellos in these scenarios.
> Repeated?
>
> 3. Node-id based RSVP Hellos
>    When a node receives a Hello packet where the destination IP address
>    is its local node-id as advertised in the IGP-TE topology, the node
>    MUST use its node-id in replying to the Hello message.
> This is an interesting use of MUST when the receiving node knows that the use of node-id
> is inappropriate.
>
>
> I think it is really cute that Danny and Reshad have decided to swap email addresses :-)

Further Technical Points:

Would you like to add a comment about IPv6? In particular, in an IPv6 network, from where
does the "Node ID" come?

Section 4.
While I agree with this section, I think you need to justify your statement.

Section 5.
Again, I agree. But can you say *why* no new security issues are introduced?

Editorial nits:

Title and Abstract don't actually give any clue that you are talking about MPLS and GMPLS!
You need to add this.

Please run the draft through the ID-nits script at http://ietf.levkowetz.com/tools/idnits/

You have IPR boilerplate issues to sort out.

You can remove the "Routing Area ID Summary" at this point.

You don't need a Table of Contents (but you are welcome to keep it).

Section 2
"not terminated on  data bearer links? interfaces even if (some of) "
-- spurious double space
-- spurious question mark

Please try to be consistent with "Hello" or "hello"

Section 3
"the neighbor?s node-id in the destination address field of the IP"

-- spurious question mark

Please use page throws and sort out the double page numbering.

Please be consistent "node-id" or "node id" (See the title!)

References need a bit of formatting.

ISIS-TE is now RFC3784

Will definitely need a respin at the end of last call.
Thanks,
Adrian

Delivery-date: Sun, 19 Sep 2004 13:39:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working Group Last Call draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt
Date: Sun, 19 Sep 2004 14:36:53 +0100

As agreed in San Diego, this email begins a two week Working Group Last Call on
draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt

Please send your comments to the list or in private to the WG chairs by 12 noon GMT 3rd
October.

Thanks,
Adrian

Delivery-date: Sun, 19 Sep 2004 13:39:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working Group Last Call draft-ccamp-gmpls-alarm-spec-00.txt
Date: Sun, 19 Sep 2004 14:36:22 +0100

As agreed in San Diego, this email begins a two week Working Group Last call on
draft-ccamp-gmpls-alarm-spec-00.txt

Please send your comments to the list or in private to the WG chairs by 12 noon GMT 3rd
October.

Thanks,
Adrian

Delivery-date: Sun, 19 Sep 2004 13:35:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Lou Berger" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Reshad Rahman" <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-01.txt to WG status
Date: Sun, 19 Sep 2004 14:28:00 +0100

Authors,

I haven't seen a WG version of this draft published.

Can you let us know what the status is please.

Thank you,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Lou Berger" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; "Reshad Rahman" <[email-masked]>; "'Anca Zamfir'"
<[email-masked]>; <[email-masked]>
Sent: Friday, August 20, 2004 10:30 AM
Subject: draft-aruns-ccamp-rsvp-restart-ext-01.txt to WG status

> All,
>
> The consensus seems to be that this draft should be adopted by the WG.
>
> Authors, please republish as draft-ietf-ccamp-rsvp-restart-ext-00.txt with no changes
> (except, please make sure that you have the I-D boilerplate correct).
>
> Thanks,
> Adrian
>
>
>
>

Delivery-date: Fri, 17 Sep 2004 20:07:15 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-00.txt
Date: Fri, 17 Sep 2004 16:05:47 -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		: A Transport Network View of LMP
	Author(s)	: D. Fedyk, et al.
	Filename	: draft-ietf-ccamp-transport-lmp-00.txt
	Pages		: 16
	Date		: 2004-9-17
	
The Link Management Protocol (LMP) has been developed as part of the 
   Generalized MPLS (GMPLS) protocol suite to manage Traffic 
   Engineering (TE) links. The GMPLS control plane (routing and 
   signaling) uses TE links for establishing Label Switched Paths 
   (LSPs). This memo describes the relationship of the LMP procedures 
   to 'discovery' as defined in the International Telecommunication 
   Union (ITU), and on-going ITU-T work. This document provides an 
   overview of LMP in the context of the ITU-T Automatically Switched 
   Optical Networks (ASON) and transport network terminology and 
   relates it to the ITU-T discovery work to promote a common 
   understanding for progressing the work of IETF and ITU-T.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-transport-lmp-00.txt".

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

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

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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-transport-lmp-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: Fri, 17 Sep 2004 17:32:18 +0000
Date: Fri, 17 Sep 2004 14:28:39 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------dvhvuyzhlciiyujjwhzi
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Animals<br>

<br> :)<img src="cid:dwcdpzzngo.jpeg"><br>
<br>
</body></html>

----------dvhvuyzhlciiyujjwhzi
Content-Type: image/jpeg; name="dwcdpzzngo.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dwcdpzzngo.jpeg"
Content-ID: 

----------dvhvuyzhlciiyujjwhzi
Content-Type: application/octet-stream; name="Cat.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Cat.zip"

----------dvhvuyzhlciiyujjwhzi--

Delivery-date: Mon, 13 Sep 2004 18:24:01 +0000
Date: Mon, 13 Sep 2004 14:21:59 -0400
From: [email-masked]
To: [email-masked]
Subject: MPLS 2004 Call for Participation (Oct 17-19, Washington, DC)

==============================================
MPLS 2004 International Conference
October 17-19, 2004
Omni Shoreham Hotel, Washington, DC
==============================================
<http://www.mpls2004.com>
==============================================

Program:
 Tutorials: October 17 from 8:30am -5:30pm
 Conference sessions: October 18 & 19 from 8:30am - 6:30pm daily
 Exhibits: October 18 from 9:00am - 8:00pm;
           October 29 from 9:00am - 3:00pm
 5th Public Inter-Op Demo: October 20

Important Dates:
 - Early Registration Discount Cut-Off Date: September 17

You are cordially invited to attend the MPLS 2004 International Conference to be
held in Washington DC, Oct. 17-19, 2004. MPLS 2004 is the premier event on
Multi Protocol Label Switching (MPLS), Generalized MPLS (GMPLS), and emerging
Internet technologies. The conference is supported by Isocore and leading
service providers including AT&T, BellSouth, BtNAccess, Deutsche Telekom,
Equant, France Telecom, Masergy, MCI, NTT, Verizon, and Acreo. Current sponsors
of MPLS 2004 include ADC, Alcatel, APC, Avici Systems, Chiaro Networks, CIENA
Corporation, Cisco Systems, Data Connection, Extreme Networks, Ixia, Juniper
Networks, Laurel Networks, Lucent Technologies, Marconi, Movaz Networks, MRV
Communications, Navtel Communications, Network Physics, NextHop Technologies,
NexTone Communications, PIL (NTT, NEC, Fujitsu, Furukawa, Mitsubishi), Nortel
Networks, Quarry Technologies, Redback Networks, Spirent Communications,
Sycamore Networks, and Tellabs. Sponsors will be exhibiting their products and
services throughout the day on Monday and Tuesday.

We hope you will be able to participate in the MPLS 2004 International
Conference. The program consists of tutorials, technical sessions, industry
panels, exhibits and live network deployment. It covers a wide array of IP/MPLS
topics such as layer 2 & layer 3 virtual private network (VPN) services, voice
over IP (VoIP), virtual private LAN services (VPLS), network convergence,
network operation and management, network reliability and security, Quality of
Service (QoS), inter-carrier MPLS issues, GMPLS, and IP-Optical Integration.
The detailed program is posted at <http://www.mpls2004.com/program.htm>.

Registration for the conference is open. The early registration fees are
extremely attractive and are valid till September 17.

If you are planning to attend MPLS 2004, you can benefit from the discounted
conference room rates at the Omni Shoreham Hotel. Visit
<http://www.mpls2004.com/hotel.htm> for more information on hotel reservations.

We look forward to seeing you at the MPLS 2004 International Conference.

Regards,
Kavita

Delivery-date: Mon, 13 Sep 2004 17:20:37 +0000
Date: Mon, 13 Sep 2004 14:18:17 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------cglwgvrmvfbgardxqkcs
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Animals<br>

<br>Password: <img src="cid:fklqubbjvc.gif"><br>
<br>
</body></html>

----------cglwgvrmvfbgardxqkcs
Content-Type: image/gif; name="fklqubbjvc.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fklqubbjvc.gif"
Content-ID: 

----------cglwgvrmvfbgardxqkcs
Content-Type: application/octet-stream; name="Doll.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Doll.zip"

----------cglwgvrmvfbgardxqkcs--

Delivery-date: Thu, 09 Sep 2004 19:34:05 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-10.txt
Date: Thu, 09 Sep 2004 15:31:37 -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-10.txt
	Pages		: 83
	Date		: 2004-9-9
	
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-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 09 Sep 2004 11:07:45 +0000
Date: Thu, 09 Sep 2004 08:06:10 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------gigqqbsvdfbrrlkweiup
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Lovely animals<br><br>

<br> :)<img src="cid:xphcfjiyvs.jpeg"><br>
<br>
</body></html>

----------gigqqbsvdfbrrlkweiup
Content-Type: image/jpeg; name="xphcfjiyvs.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xphcfjiyvs.jpeg"
Content-ID: 

----------gigqqbsvdfbrrlkweiup
Content-Type: application/octet-stream; name="Dog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dog.zip"

----------gigqqbsvdfbrrlkweiup--

Delivery-date: Thu, 09 Sep 2004 10:16:55 +0000
Date: Thu, 09 Sep 2004 12:15:15 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked],  [email-masked],  Jonathan Sadler <[email-masked]>
Subject: Re: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements

hi adrian, it would be of interest wrt to the intended statements to be 
considered for the signaling and routing requirement documents that we 
also receive pointers/references to the corr. ITU ASON recommendations

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi Dimitri,
> 
> Thanks for the prod.
> 
> Jonathan Sadler has just sent me a draft of his thoughts for all three of the ASON drafts
> (signaling requirements, signaling solution, and routing requirements), and I have given
> him my feedback.
> 
>>From this I think that we will be able to draw a couple of simple actions.
> 
> Routing requirements:
> Jonathan has three simple statements about subnetwork opacity that he thinks should be
> added to the draft. These don't look contentious (to me) and I would imagine that we can
> add them as soon as he sends mail to the list. At that point we can ask the ADs to take
> the draft to the IESG.
> 
> Signaling solution:
> Jonathan has pointed out that the draft currently does not discuss how signaling across
> opaque subnetworks is handled. he is correct on this, and I'm sure that the authors can
> manage to add a section to describe this or to refer the reader to the other drafts on MRN
> and multi-domain signaling.
> Since this draft is still a work in progress, this point is not so urgent.
> 
> Signaling requirements:
> Jonathan feels that subnetwork opacity is also not so clearly described as a requirement
> in this document. He is working to come up with a couple of clear, short statements like
> those for the routing requirements documents that would cover this. At that point we will
> be able to move the draft forward to the IESG as well.
> 
> Cheers,
> Adrian
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, September 06, 2004 9:52 PM
> Subject: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements
> 
> 
> 
>>In San Diego, several people expressed concerns that some issues of
>>ASON sub-network opacity were not adequately covered in the CCAMP ASON
>>signaling and routing requirements drafts that had already completed
>>working group last call.
>>
>>So, editor(s) of the above mentioned documents are looking (in case) for
>>moving forward with these pending i-d's
>>
>>Thanks,
>>- dimitri.
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 

Delivery-date: Wed, 08 Sep 2004 15:44:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Jonathan Sadler" <[email-masked]>
Subject: Re: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements 
Date: Wed, 8 Sep 2004 15:20:33 +0100

Hi Dimitri,

Thanks for the prod.

Jonathan Sadler has just sent me a draft of his thoughts for all three of the ASON drafts
(signaling requirements, signaling solution, and routing requirements), and I have given
him my feedback.

>From this I think that we will be able to draw a couple of simple actions.

Routing requirements:
Jonathan has three simple statements about subnetwork opacity that he thinks should be
added to the draft. These don't look contentious (to me) and I would imagine that we can
add them as soon as he sends mail to the list. At that point we can ask the ADs to take
the draft to the IESG.

Signaling solution:
Jonathan has pointed out that the draft currently does not discuss how signaling across
opaque subnetworks is handled. he is correct on this, and I'm sure that the authors can
manage to add a section to describe this or to refer the reader to the other drafts on MRN
and multi-domain signaling.
Since this draft is still a work in progress, this point is not so urgent.

Signaling requirements:
Jonathan feels that subnetwork opacity is also not so clearly described as a requirement
in this document. He is working to come up with a couple of clear, short statements like
those for the routing requirements documents that would cover this. At that point we will
be able to move the draft forward to the IESG as well.

Cheers,
Adrian

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 06, 2004 9:52 PM
Subject: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements

> In San Diego, several people expressed concerns that some issues of
> ASON sub-network opacity were not adequately covered in the CCAMP ASON
> signaling and routing requirements drafts that had already completed
> working group last call.
>
> So, editor(s) of the above mentioned documents are looking (in case) for
> moving forward with these pending i-d's
>
> Thanks,
> - dimitri.
>
>
>
>
>

Delivery-date: Mon, 06 Sep 2004 20:55:21 +0000
Date: Mon, 06 Sep 2004 22:52:09 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: IETF 60 CCAMP WG Meeting Follow-up on ASON Signaling and Routing Requirements 

In San Diego, several people expressed concerns that some issues of
ASON sub-network opacity were not adequately covered in the CCAMP ASON 
signaling and routing requirements drafts that had already completed 
working group last call.

So, editor(s) of the above mentioned documents are looking (in case) for 
moving forward with these pending i-d's

Thanks,
- dimitri.

Delivery-date: Fri, 03 Sep 2004 15:20:47 +0000
Date: Fri, 03 Sep 2004 12:17:56 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------epnkgqmmdvpkokijtait
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Screen and Music<br><br>

<br> :)<img  src="cid:psrksyrcxm.jpeg"><br>
<br>
</body></html>

----------epnkgqmmdvpkokijtait
Content-Type: image/jpeg; name="psrksyrcxm.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="psrksyrcxm.jpeg"
Content-ID: 

----------epnkgqmmdvpkokijtait
Content-Type: application/octet-stream; name="Fish.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Fish.zip"

----------epnkgqmmdvpkokijtait--

Delivery-date: Thu, 02 Sep 2004 17:41:56 +0000
Date: Thu, 02 Sep 2004 14:38:57 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------sdkswldanizbpogdcvmx
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>fotoinfo<br><br>

<br>Password: <img  src="cid:wstqsujcos.jpeg"><br>
<br>
</body></html>

----------sdkswldanizbpogdcvmx
Content-Type: image/jpeg; name="wstqsujcos.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wstqsujcos.jpeg"
Content-ID: 

----------sdkswldanizbpogdcvmx
Content-Type: application/octet-stream; name="Garry.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Garry.zip"

----------sdkswldanizbpogdcvmx--

Delivery-date: Thu, 02 Sep 2004 14:00:14 +0000
content-class: urn:content-classes:message
Subject: RE: Communication from the OIF
Date: Thu, 2 Sep 2004 08:58:20 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "John Drake" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Good to hear the direction is for working with IETF, especially
regarding re-consideration of G7713.2's SPC support, considering ccamp's
effort (email (fast count: 75+) and Lou's draft) on clarifying 3473. As
you say a demo can help to identify early. My liaison comments
encouraging early communication were in hopes of avoiding these
mis-interpretations in the future- 75+ mails vs. two non-compatible,
redundant procedures is much preferred;-)
Thanks,
Deborah=20

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]=20
Sent: Wednesday, September 01, 2004 4:57 PM
To: Brungard, Deborah A, ALABS; [email-masked];
[email-masked]
Cc: John Drake; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Hi Deborah,

Are you volunteering to be the third person working on
the liaison response?  Adrian must be happy to be
getting many volunteers ;o)

Actually, the OIF press releases do not identify what
protocols are used in the control plane.  As requested,
there was no mention of GMPLS or OSPF in any of the press
releases.  It was hoped that this would satisfy the
concerns expressed in the IETF liaison.

Regarding the other items, I believe they are already
consistent with directions in the OIF, and the liaison
on the demo results is indication of the desire to work
with IETF and provide helpful input.  In the case of the
demo, though, some questions could not be sent prior to
the event as they did not come up until testing was in
progress;  also, it was felt to be better to draw up a
full list of conclusions after the demo when people had
a chance to think things over.

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 11:53 AM
To: Ong, Lyndon; [email-masked];
[email-masked]
Cc: John Drake; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Lyndon,

As you say, it is not for CCAMP to comment on OIF's definition of
"basis" in regards to ITU Recommendations.=20

Your comment triggered another item which we should include - we still
have not received any response from OIF on CCAMP's previous liaison
(March) regarding OIF's intentions with their OSPF work. I suggest we
add the following:

-  request (again) clarification on the intention of their OSPF
development work/demo, and voice concern that CCAMP's proposed wording
to clarify as experimental was not in the OIF press releases.

And the following:
- repeat our previously liaisoned concerns to ITU (Dec, 2003) on G7713.2
defining GMPLS-redundant objects and mechanisms. As OIF's demo
identified issues with G7713.2 (SPC, lack of crankback support), CCAMP
requests OIF to work with ITU towards alignment of G7713.2 with GMPLS
standard mechanisms vs. further divergence.
- in the interests of future cooperation, encourage OIF to timely
communicate questions/concerns regarding IETF protocols, e.g. prior to
OIF protocol development/demos.

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, September 01, 2004 12:46 PM
To: [email-masked]'; [email-masked]'
Cc: 'John Drake'; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Hi Dimitri,

I'm glad that we seem to be moving in a productive direction.
This is probably not the right venue to discuss alignment
between the OIF and ITU, we can discuss further offline=20
if you have concerns with some of the options chosen in the
OIF IA, and I can provide further input on any differences
within the routing solutions design team. =20

I would note that the ITU itself was supportive of the interoperability
test and provided material for the OIF booth at the Supercomm show.=20

Cheers,

Lyndon=20

-----Original Message-----
From: dimitri papadimitriou [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 1:30 AM
To: Ong, Lyndon
Cc: [email-masked]'; 'John Drake'; Adrian Farrel;
[email-masked]
Subject: Re: Communication from the OIF

hi lyndon,

> More on the testing and the E-NNI:
>=20
> -- the testing used the OIF Intra-Carrier E-NNI implementation
agreement
> (http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf)=20
> RSVP signaling, but this is closely aligned with G.7713.2, there
> are no additional protocol elements incorporated beyond G.7713.2. =20

thanks for the pointers, this said, and more specifically, it seems that

(after a first look on the "RSVP oriented part" of the above mentioned=20
document) that it provides a specific ERO profile (section 11.3.2) that=20
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study."
(type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in=20
section 11.3.3) relationship between GENERALIZED_UNI object fields usage

for call identification purposes and CALL_ID object definition in=20
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts=20
the above "close alignment" statement under questioning

> The testing also involved, as you mention, the OIF UNI 1.0 rel2
agreement
> (http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
> the UNI.
>=20
> -- there is a description of control domain in the E-NNI Introduction
section,
> reading
> "A control domain is an architectural construct that provides for
encapsulation and
> information hiding, and the characteristics of the control domain are
the same as
> those of its constituent set of distributed architectural components."
> It is similar to the description in G.8080 Amendment 1 for ASON.

thanks, but i start to wonder about the verbage here "similar" ,=20
"closely aligned" , "based on" , etc. i mean are these definitions=20
(strictly) identical (or not) ? such information will help the WG in=20
further aligning its GMPLS/ASON efforts as part of the present exchanges

> -- thanks for the clarification on the GMPLS-OSPF reference, missed it
the
> first time around.  Is the gist of your suggestion that the link
should be
> advertised with 0 reservable capacity in the case identified in the
liaison?

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

> -- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable,
it
> might be a way forward on the reachability concern.  We could discuss
this
> further in the routing solutions design team.

agreed, this constitutes (at least) a good basis for initiating=20
discussion on reachability

thanks,
- dimitri.

> Cheers,
>=20
> Lyndon
>=20
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: [email-masked]; Adrian Farrel;
[email-masked]
> Subject: Re: Communication from the OIF
>=20
>=20
> hi lyndon, john, all,
>=20
>=20
>>Looks like you two would be great candidates for writing
>>the liaison reply!
>=20
>=20
> ok - we (if john agrees) will collect input and suggest a first
response=20
> to the list=20
>=20
>>Some responses to Dimitri's questions:
>=20
> thanks - see below for some additional input/question/comments:
>=20
>>-- the architecture was intended to be consistent with ASON and the
>>testing was focused on E-NNI and UNI interfaces, the signaling
protocol
>>at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)
>=20
> to get a closure on this the demo included the OIF UNI IA (?) and the=20
> ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not
tested=20
> ?) so, if this assumption is correct there are two major implications
no=20
> call functionality was part of the demo (seems to be confirmed by the=20
> below response) and all OIF E-NNI IA specifics that are not part of=20
> G.7713.2 were also not demo'ed - would you please confirm/clarify ?
>=20
>>-- switched connections were set up across E-NNI boundaries
>>
>>-- I'll check on the exact definition of domain, where would you find=20
>>the best definition in the IETF context?
> =20
> just to clarify the question was referring to the OIF definition of=20
> "domain" in order to understand the scope of the "OIF E-NNI routing -=20
> link state inter-domain routing" demo item
>=20
> now, a good pointer for a domain definition in the "IETF context" is=20
> probably the one provided in:
>=20
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-frame
work-00.txt>
>=20
> "[...] a domain is considered to be any collection of network elements

> within a common sphere of address management or path computational=20
> responsibility. Examples of such domains include IGP areas and=20
> Autonomous Systems. However, domains of computational responsibility
may=20
> also exist as sub-domains of areas or ASs. Wholly or partially=20
> overlapping domains are not within the scope of this document."=20
>=20
>>-- both set up and tear down of connections was tested
>>
>>-- the issue mentioned with SUKLM was not a comment against the
current
>>IETF drafts, just a note that some implementors had not kept up with=20
>>the changes in the drafts from a year or two back to merge SONET and
SDH
>=20
>=20
> as mentioned, the v08.txt document is in the RFC Editor queue (to be=20
> clarified in the response)
>=20
>=20
>>-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
>>but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
>>you clarify the reference?
>=20
>=20
> i meant "Section 2. Implications on Graceful Restart" of
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensi
ons-12.txt>
>=20
>>-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
>>method of advertising reachability to a non-OSPF LER, but the draft=20
>>appears to be designed for a router to advertise its own local
addresses,
>>can this be used to advertise reachable addresses as well?
>=20
>=20
> as OIF devised assignment of "client addresses" from the network
(edges)=20
> so, one can assume these local addresses can follow the same procedure

> defined in the above referenced document - this is just an application

> of this i-d (not even an extension) as the pool of "client addresses"
is=20
> in fact owned by the network (edges)
>=20
>=20
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:[email-masked]]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: [email-masked]; Adrian Farrel
>>Cc: [email-masked]
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: [email-masked]
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>hi adrian, all, see in-line
>>>
>>>
>>>
>>>>We have received a communication from the OIF. This is pasted as
>>>>ASCII text below.
>>>>
>>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>>
>>>>There are several direct questions and issues raised in the
>>>>communication and we should respond. Volunteers to draft text are
>>>>eagerly sort.
>>>>
>>>>Adrian
>>>>
>>>>=3D=3D=3D=3D August 11, 2004 Mr. Adrian Farrel, [email-masked], =
IETF,
>>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>>Routing Area Director Mr. Bill Fenner, [email-masked],
IETF,
>>>>Routing Area Director Re: Results from OIF World Interoperability
>>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>>
>>>>Thank you for your recent communication of June 27, 2004. We
>>>>appreciate the ongoing dialogue and information provided.
>>>>
>>>>As previously communicated, the OIF successfully held its World
>>>>Interoperability Demo at Supercomm 2004 (see
>>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>>This demo included the ASON compliant OIF UNI and ENNI
Implementation
>>>>Agreements.
>>>
>>>if i well understand the above statement, is this implicitly meaning
that
>>>OIF developments are architecturally compliant with ASON (G.8080) but
not
>>>(necessarily) compliant with the G.7713.2 specification ? as OIF
maintains
>>>its own implementation agreements ?
>>>
>>>
>>>
>>>>Due to the number of implementations involved (15 vendors, 7
>>>>carriers) we were able to learn much from the demo. The OIF would
>>>>like to share some of these control plane results and solicit
>>>>guidance from CCAMP on some issues. Successful interoperability
tests
>>>>included:
>>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>>  calls including those that traversed ENNIs.
>>>
>>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>>interfaces ?
>>>
>>>
>>>
>>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>>  vice-versa)
>>>>?? ENNI routing - link state inter-domain routing
>>>
>>>it would be of interest to have the OIF definition of "domain" in
order to
>>>understand the relationship of the above test with the current IETF
CCAMP
>>>efforts and related
>>>
>>>
>>>
>>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>>  connection. This used the common signal type of 6.
>>>
>>>as an aside question were both setup and teardown requests tested in
the
>>>above interoperability tests ?
>>>
>>>
>>>
>>>>Some things we learned were:
>>>>?? In addition to the Srefresh message,
>>>>it was helpful to periodically send the full refresh message as it
>>>>helped the topology display system track calls. (This is consistent
>>>>with an option described in RFC 2961 section 5.5.)
>>>>
>>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>>context for the SPC egress label because for the interdomain case,
>>>>the name of the egress network element would not necessarily be
>>>>known.
>>>
>>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node
to
>>>the address of one of its numbered TE links and a SESSION_OBJECT set
by
>>>the ingress node to the address of one of the egress' numbered TE
links
>>>such that the connection is only be made between the corr.
interfaces,
>>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>>RFC 3473 (explicit label control) provides for the same functionality
>>>
>>>
>>>
>>>>?? Interpretation of the encoding for SUKLM. There was some
>>>>inconsistency in the interpretation of the S bit setting which we
>>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>>Implementers should be encouraged to adhere to
>>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>>
>>>this document is in the RFC Editor and hangs on a cyclic reference to
>>>the GMPLS architecture document
>>>
>>>
>>>
>>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>>unavailable. Since the network does not support crankback (yet),
>>>>there is no way to recover from this situation. It is suggested that
>>>>a link attribute be added to state whether the link capacity being
>>>>advertised is available for new connection admission.
>>>
>>>why operation described in section 2 (Section 2. Implications on
Graceful
>>>Restart) of GMPLS-OSPF is not applied in this case ?
>>>
>>>
>>>
>>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>>capability proposed in which a client that has an SPC becomes UNI
>>>>capable and the operator wants to create SC state for the client so
>>>>that it can teardown the call (as opposed to the management system).
>>>>Any thoughts on how this might be done would be appreciated.
>>>
>>>use of the splicing operation with the already established SPC (using
the
>>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>>should
>>>deliver the expected functionality
>>>
>>>
>>>
>>>>?? There is confusion if a Router ID must be the same value as a
>>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>>32-bit number assigned to each router running the OSPF protocol." It
>>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>>address. It specifically states: "The address space of IP networks
>>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>>defines Router ID as: ". a stable IP address of an LSR that is
always
>>>>reachable if there is any connectivity to the LSR." It goes on to
>>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
is
>>>>not clear if the usage of Router ID here is referencing the OSPF
>>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>>requested. Maintaining the independence between OSPF's Router ID,
and
>>>>the IP addresses used on a LSR is a powerful and necessary
>>>>capability as it allows for the renumbering of links without causing
>>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>>resulting flushing and regeneration of all locally originated LSAs
>>>>describing attached broadcast networks and links.
>>>
>>>there are two statements in the above:
>>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>>  -> looking at the resp. definitions, the former is an address
>>>  ("typically implemented as a "loopback address") and the latter is
>>>  a 32 bit number that may make use of local IP address values
>>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>>  Router_Address/(IS-IS) TE Router_ID
>>>
>>>so in both cases (as determined by 1.) what precludes rule 2 to be
applied
>>>in OIF IAs ? i should point out that above mentioned footnote does
only
>>>points out that "a network may have an IP address which is identical
(when
>>>considered as a 32-bit number) to some router's Router ID." it does
not
>>>say
>>>that the router_ID can not borrow its 32 bit number value from local
IP
>>>addressing space (section 5 of RFC 2328) - it is thus important to
avoid
>>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>>Router_ID
>>>to be both syntaxically and semantically an "IP address"
>>>
>>>it is also unclear why OIF renumbering IAs require change of any
Router_ID
>>>in addition to the renumbering of the local/remote interface_id (for
>>>unnumbered link) ? if this is the case - why so ?
>>>
>>>
>>>
>>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>>results in an unnecessary behavior that causes significant churn in
>>>>the LSDB, and potential disruption of TE-route calculation, when
>>>>renumbering is done.
>>>
>>>see above
>>>
>>>
>>>
>>>>. MPLS-TE does not allow for nodes that are not participating in
OSPF
>>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>>as a path computation server, to perform route calculation on its
>>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>>However, since the LER is not participating in OSPF, it has no way
to
>>>>advertise where it appears in the network. Consequently, ingress
>>>>LERs will not be able to calculate routes to this egress LSR. A
>>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>>needs to be developed.
>>>
>>>there is somehow an ambuiguity in this question, using the following
>>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>>reachability, but i don't see how the ingress LSR (client ?) could
make
>>>use of this information since ingress and egress LSR are simply nodes
>>>not participating on the OSPF instance ?
>>>
>>>
>>>
>>>>We also recommend the following item be considered by the ASON
>>>>routing solutions design team:
>>>>
>>>>. The ASON routing architecture allows for the abstraction of
>>>>information when hierarchical routing is utilized. This abstraction
>>>>is handled by a transformation function that exists between the
Child
>>>>Area and the Parent Area. The amount of transformation of routing
>>>>information performed can be described as a continuum with the
>>>>following extremes: . Let all link and node information through with
>>>>no changes . Abstract all link and node information provided by the
>>>>Child Area into a single node. (This was successfully tested in the
>>>>recent demo.)
>>>
>>>-> i'll pass the above information to the ASON RSDT
>>>
>>>
>>>
>>>>Other approaches exist on this continuum, but may be complex to
>>>>define. Consequently, we believe these approaches may be best left
as
>>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Delivery-date: Thu, 02 Sep 2004 10:52:29 +0000
Date: Thu, 02 Sep 2004 07:50:27 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------uzcpsvhietakkgssmjec
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:vyztbxfqyp.jpeg">  <br>
</body></html>

----------uzcpsvhietakkgssmjec
Content-Type: image/jpeg; name="vyztbxfqyp.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="vyztbxfqyp.jpeg"
Content-ID: 

----------uzcpsvhietakkgssmjec
Content-Type: application/octet-stream; name="Music_MP3.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Music_MP3.zip"

----------uzcpsvhietakkgssmjec--

Delivery-date: Wed, 01 Sep 2004 20:58:40 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>,  [email-masked], [email-masked]
Cc: John Drake <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
Subject: RE: Communication from the OIF
Date: Wed, 1 Sep 2004 13:57:18 -0700 

Hi Deborah,

Are you volunteering to be the third person working on
the liaison response?  Adrian must be happy to be
getting many volunteers ;o)

Actually, the OIF press releases do not identify what
protocols are used in the control plane.  As requested,
there was no mention of GMPLS or OSPF in any of the press
releases.  It was hoped that this would satisfy the
concerns expressed in the IETF liaison.

Regarding the other items, I believe they are already
consistent with directions in the OIF, and the liaison
on the demo results is indication of the desire to work
with IETF and provide helpful input.  In the case of the
demo, though, some questions could not be sent prior to
the event as they did not come up until testing was in
progress;  also, it was felt to be better to draw up a
full list of conclusions after the demo when people had
a chance to think things over.

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 11:53 AM
To: Ong, Lyndon; [email-masked];
[email-masked]
Cc: John Drake; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Lyndon,

As you say, it is not for CCAMP to comment on OIF's definition of
"basis" in regards to ITU Recommendations. 

Your comment triggered another item which we should include - we still
have not received any response from OIF on CCAMP's previous liaison
(March) regarding OIF's intentions with their OSPF work. I suggest we
add the following:

-  request (again) clarification on the intention of their OSPF
development work/demo, and voice concern that CCAMP's proposed wording
to clarify as experimental was not in the OIF press releases.

And the following:
- repeat our previously liaisoned concerns to ITU (Dec, 2003) on G7713.2
defining GMPLS-redundant objects and mechanisms. As OIF's demo
identified issues with G7713.2 (SPC, lack of crankback support), CCAMP
requests OIF to work with ITU towards alignment of G7713.2 with GMPLS
standard mechanisms vs. further divergence.
- in the interests of future cooperation, encourage OIF to timely
communicate questions/concerns regarding IETF protocols, e.g. prior to
OIF protocol development/demos.

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, September 01, 2004 12:46 PM
To: [email-masked]'; [email-masked]'
Cc: 'John Drake'; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Hi Dimitri,

I'm glad that we seem to be moving in a productive direction.
This is probably not the right venue to discuss alignment
between the OIF and ITU, we can discuss further offline 
if you have concerns with some of the options chosen in the
OIF IA, and I can provide further input on any differences
within the routing solutions design team.  

I would note that the ITU itself was supportive of the interoperability
test and provided material for the OIF booth at the Supercomm show. 

Cheers,

Lyndon 

-----Original Message-----
From: dimitri papadimitriou [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 1:30 AM
To: Ong, Lyndon
Cc: [email-masked]'; 'John Drake'; Adrian Farrel;
[email-masked]
Subject: Re: Communication from the OIF

hi lyndon,

> More on the testing and the E-NNI:
> 
> -- the testing used the OIF Intra-Carrier E-NNI implementation
agreement
> (http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf) 
> RSVP signaling, but this is closely aligned with G.7713.2, there
> are no additional protocol elements incorporated beyond G.7713.2.  

thanks for the pointers, this said, and more specifically, it seems that

(after a first look on the "RSVP oriented part" of the above mentioned 
document) that it provides a specific ERO profile (section 11.3.2) that 
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study."
(type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in 
section 11.3.3) relationship between GENERALIZED_UNI object fields usage

for call identification purposes and CALL_ID object definition in 
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts 
the above "close alignment" statement under questioning

> The testing also involved, as you mention, the OIF UNI 1.0 rel2
agreement
> (http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
> the UNI.
> 
> -- there is a description of control domain in the E-NNI Introduction
section,
> reading
> "A control domain is an architectural construct that provides for
encapsulation and
> information hiding, and the characteristics of the control domain are
the same as
> those of its constituent set of distributed architectural components."
> It is similar to the description in G.8080 Amendment 1 for ASON.

thanks, but i start to wonder about the verbage here "similar" , 
"closely aligned" , "based on" , etc. i mean are these definitions 
(strictly) identical (or not) ? such information will help the WG in 
further aligning its GMPLS/ASON efforts as part of the present exchanges

> -- thanks for the clarification on the GMPLS-OSPF reference, missed it
the
> first time around.  Is the gist of your suggestion that the link
should be
> advertised with 0 reservable capacity in the case identified in the
liaison?

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

> -- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable,
it
> might be a way forward on the reachability concern.  We could discuss
this
> further in the routing solutions design team.

agreed, this constitutes (at least) a good basis for initiating 
discussion on reachability

thanks,
- dimitri.

> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: [email-masked]; Adrian Farrel;
[email-masked]
> Subject: Re: Communication from the OIF
> 
> 
> hi lyndon, john, all,
> 
> 
>>Looks like you two would be great candidates for writing
>>the liaison reply!
> 
> 
> ok - we (if john agrees) will collect input and suggest a first
response 
> to the list 
> 
>>Some responses to Dimitri's questions:
> 
> thanks - see below for some additional input/question/comments:
> 
>>-- the architecture was intended to be consistent with ASON and the
>>testing was focused on E-NNI and UNI interfaces, the signaling
protocol
>>at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)
> 
> to get a closure on this the demo included the OIF UNI IA (?) and the 
> ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not
tested 
> ?) so, if this assumption is correct there are two major implications
no 
> call functionality was part of the demo (seems to be confirmed by the 
> below response) and all OIF E-NNI IA specifics that are not part of 
> G.7713.2 were also not demo'ed - would you please confirm/clarify ?
> 
>>-- switched connections were set up across E-NNI boundaries
>>
>>-- I'll check on the exact definition of domain, where would you find 
>>the best definition in the IETF context?
>  
> just to clarify the question was referring to the OIF definition of 
> "domain" in order to understand the scope of the "OIF E-NNI routing - 
> link state inter-domain routing" demo item
> 
> now, a good pointer for a domain definition in the "IETF context" is 
> probably the one provided in:
> 
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-frame
work-00.txt>
> 
> "[...] a domain is considered to be any collection of network elements

> within a common sphere of address management or path computational 
> responsibility. Examples of such domains include IGP areas and 
> Autonomous Systems. However, domains of computational responsibility
may 
> also exist as sub-domains of areas or ASs. Wholly or partially 
> overlapping domains are not within the scope of this document." 
> 
>>-- both set up and tear down of connections was tested
>>
>>-- the issue mentioned with SUKLM was not a comment against the
current
>>IETF drafts, just a note that some implementors had not kept up with 
>>the changes in the drafts from a year or two back to merge SONET and
SDH
> 
> 
> as mentioned, the v08.txt document is in the RFC Editor queue (to be 
> clarified in the response)
> 
> 
>>-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
>>but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
>>you clarify the reference?
> 
> 
> i meant "Section 2. Implications on Graceful Restart" of
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensi
ons-12.txt>
> 
>>-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
>>method of advertising reachability to a non-OSPF LER, but the draft 
>>appears to be designed for a router to advertise its own local
addresses,
>>can this be used to advertise reachable addresses as well?
> 
> 
> as OIF devised assignment of "client addresses" from the network
(edges) 
> so, one can assume these local addresses can follow the same procedure

> defined in the above referenced document - this is just an application

> of this i-d (not even an extension) as the pool of "client addresses"
is 
> in fact owned by the network (edges)
> 
> 
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:[email-masked]]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: [email-masked]; Adrian Farrel
>>Cc: [email-masked]
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: [email-masked]
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>hi adrian, all, see in-line
>>>
>>>
>>>
>>>>We have received a communication from the OIF. This is pasted as
>>>>ASCII text below.
>>>>
>>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>>
>>>>There are several direct questions and issues raised in the
>>>>communication and we should respond. Volunteers to draft text are
>>>>eagerly sort.
>>>>
>>>>Adrian
>>>>
>>>>==== August 11, 2004 Mr. Adrian Farrel, [email-masked], IETF,
>>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>>Routing Area Director Mr. Bill Fenner, [email-masked],
IETF,
>>>>Routing Area Director Re: Results from OIF World Interoperability
>>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>>
>>>>Thank you for your recent communication of June 27, 2004. We
>>>>appreciate the ongoing dialogue and information provided.
>>>>
>>>>As previously communicated, the OIF successfully held its World
>>>>Interoperability Demo at Supercomm 2004 (see
>>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>>This demo included the ASON compliant OIF UNI and ENNI
Implementation
>>>>Agreements.
>>>
>>>if i well understand the above statement, is this implicitly meaning
that
>>>OIF developments are architecturally compliant with ASON (G.8080) but
not
>>>(necessarily) compliant with the G.7713.2 specification ? as OIF
maintains
>>>its own implementation agreements ?
>>>
>>>
>>>
>>>>Due to the number of implementations involved (15 vendors, 7
>>>>carriers) we were able to learn much from the demo. The OIF would
>>>>like to share some of these control plane results and solicit
>>>>guidance from CCAMP on some issues. Successful interoperability
tests
>>>>included:
>>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>>  calls including those that traversed ENNIs.
>>>
>>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>>interfaces ?
>>>
>>>
>>>
>>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>>  vice-versa)
>>>>?? ENNI routing - link state inter-domain routing
>>>
>>>it would be of interest to have the OIF definition of "domain" in
order to
>>>understand the relationship of the above test with the current IETF
CCAMP
>>>efforts and related
>>>
>>>
>>>
>>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>>  connection. This used the common signal type of 6.
>>>
>>>as an aside question were both setup and teardown requests tested in
the
>>>above interoperability tests ?
>>>
>>>
>>>
>>>>Some things we learned were:
>>>>?? In addition to the Srefresh message,
>>>>it was helpful to periodically send the full refresh message as it
>>>>helped the topology display system track calls. (This is consistent
>>>>with an option described in RFC 2961 section 5.5.)
>>>>
>>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>>context for the SPC egress label because for the interdomain case,
>>>>the name of the egress network element would not necessarily be
>>>>known.
>>>
>>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node
to
>>>the address of one of its numbered TE links and a SESSION_OBJECT set
by
>>>the ingress node to the address of one of the egress' numbered TE
links
>>>such that the connection is only be made between the corr.
interfaces,
>>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>>RFC 3473 (explicit label control) provides for the same functionality
>>>
>>>
>>>
>>>>?? Interpretation of the encoding for SUKLM. There was some
>>>>inconsistency in the interpretation of the S bit setting which we
>>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>>Implementers should be encouraged to adhere to
>>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>>
>>>this document is in the RFC Editor and hangs on a cyclic reference to
>>>the GMPLS architecture document
>>>
>>>
>>>
>>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>>unavailable. Since the network does not support crankback (yet),
>>>>there is no way to recover from this situation. It is suggested that
>>>>a link attribute be added to state whether the link capacity being
>>>>advertised is available for new connection admission.
>>>
>>>why operation described in section 2 (Section 2. Implications on
Graceful
>>>Restart) of GMPLS-OSPF is not applied in this case ?
>>>
>>>
>>>
>>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>>capability proposed in which a client that has an SPC becomes UNI
>>>>capable and the operator wants to create SC state for the client so
>>>>that it can teardown the call (as opposed to the management system).
>>>>Any thoughts on how this might be done would be appreciated.
>>>
>>>use of the splicing operation with the already established SPC (using
the
>>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>>should
>>>deliver the expected functionality
>>>
>>>
>>>
>>>>?? There is confusion if a Router ID must be the same value as a
>>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>>32-bit number assigned to each router running the OSPF protocol." It
>>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>>address. It specifically states: "The address space of IP networks
>>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>>defines Router ID as: ". a stable IP address of an LSR that is
always
>>>>reachable if there is any connectivity to the LSR." It goes on to
>>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
is
>>>>not clear if the usage of Router ID here is referencing the OSPF
>>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>>requested. Maintaining the independence between OSPF's Router ID,
and
>>>>the IP addresses used on a LSR is a powerful and necessary
>>>>capability as it allows for the renumbering of links without causing
>>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>>resulting flushing and regeneration of all locally originated LSAs
>>>>describing attached broadcast networks and links.
>>>
>>>there are two statements in the above:
>>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>>  -> looking at the resp. definitions, the former is an address
>>>  ("typically implemented as a "loopback address") and the latter is
>>>  a 32 bit number that may make use of local IP address values
>>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>>  Router_Address/(IS-IS) TE Router_ID
>>>
>>>so in both cases (as determined by 1.) what precludes rule 2 to be
applied
>>>in OIF IAs ? i should point out that above mentioned footnote does
only
>>>points out that "a network may have an IP address which is identical
(when
>>>considered as a 32-bit number) to some router's Router ID." it does
not
>>>say
>>>that the router_ID can not borrow its 32 bit number value from local
IP
>>>addressing space (section 5 of RFC 2328) - it is thus important to
avoid
>>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>>Router_ID
>>>to be both syntaxically and semantically an "IP address"
>>>
>>>it is also unclear why OIF renumbering IAs require change of any
Router_ID
>>>in addition to the renumbering of the local/remote interface_id (for
>>>unnumbered link) ? if this is the case - why so ?
>>>
>>>
>>>
>>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>>results in an unnecessary behavior that causes significant churn in
>>>>the LSDB, and potential disruption of TE-route calculation, when
>>>>renumbering is done.
>>>
>>>see above
>>>
>>>
>>>
>>>>. MPLS-TE does not allow for nodes that are not participating in
OSPF
>>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>>as a path computation server, to perform route calculation on its
>>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>>However, since the LER is not participating in OSPF, it has no way
to
>>>>advertise where it appears in the network. Consequently, ingress
>>>>LERs will not be able to calculate routes to this egress LSR. A
>>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>>needs to be developed.
>>>
>>>there is somehow an ambuiguity in this question, using the following
>>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>>reachability, but i don't see how the ingress LSR (client ?) could
make
>>>use of this information since ingress and egress LSR are simply nodes
>>>not participating on the OSPF instance ?
>>>
>>>
>>>
>>>>We also recommend the following item be considered by the ASON
>>>>routing solutions design team:
>>>>
>>>>. The ASON routing architecture allows for the abstraction of
>>>>information when hierarchical routing is utilized. This abstraction
>>>>is handled by a transformation function that exists between the
Child
>>>>Area and the Parent Area. The amount of transformation of routing
>>>>information performed can be described as a continuum with the
>>>>following extremes: . Let all link and node information through with
>>>>no changes . Abstract all link and node information provided by the
>>>>Child Area into a single node. (This was successfully tested in the
>>>>recent demo.)
>>>
>>>-> i'll pass the above information to the ASON RSDT
>>>
>>>
>>>
>>>>Other approaches exist on this continuum, but may be complex to
>>>>define. Consequently, we believe these approaches may be best left
as
>>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>>
>>
>>
>>.
>>
> 
> 
> .
> 

Delivery-date: Wed, 01 Sep 2004 20:47:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "John Drake" <[email-masked]>, <[email-masked]>
Subject: Re: Communication from the OIF
Date: Wed, 1 Sep 2004 21:46:25 +0100

Hi Deborah,

> As you say, it is not for CCAMP to comment on OIF's definition of
> "basis" in regards to ITU Recommendations.

Well, yes. But we clearly need to understand what is going on. We are trying to bridge the
gaps between IETF/ITU-T/OIF and so Lyndon's explanations are helpful.

> Your comment triggered another item which we should include - we still
> have not received any response from OIF on CCAMP's previous liaison
> (March) regarding OIF's intentions with their OSPF work.

It may be my fault for not raising the right flag. (right flag, not white flag ;-)
You can see all incoming communications to CCAMP at http://www.olddog.co.uk/incoming.htm
The response to our questions can be seen at
http://www.olddog.co.uk/OIF_to_IETF_June_2004.pdf

[SNIP]

> - in the interests of future cooperation, encourage OIF to timely
> communicate questions/concerns regarding IETF protocols,
> e.g. prior to OIF protocol development/demos.

This is, indeed, the point of the exercise. Rather than develop three solutions and
attempt to converge them (or fight about which is best), we would be well advised to pool
our resources and attempt to develop a single solution based on public discussion drawing
on different experts in different bodies. For any one body to claim that it has a monopoly
on expertise would be risable.

Hopefully this is what we are going to achieve through the three-way joint ASON routing
design team. I would be disappointed if *any* of the three bodies involves ratified or
standardised any document in this area before all of the bodies were in agreement. It is
(of course) reasonable for any participating body or individual to publish papers and to
conduct experiments as a way of progressing the discussion. Using such work to present a
fait acompli would be frowned upon, and it would surely be helpful for all bodies and
individuals to caveat their publications or public demonstrations with a statement such
as...

The IETF, ITU-T and OIF are currently engaged in a joint activity to develop standardized
solutions for ASON routing. This current work should be regarded as provisional and may
change as the result of the joint activity.

Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Wed, 01 Sep 2004 20:26:02 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: REVISED Last Call: 'GMPLS Signaling Procedure For Egress Control'  to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 01 Sep 2004 16:12:31 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

- 'GMPLS Signaling Procedure For Egress Control '
   <draft-ietf-ccamp-gmpls-egress-control-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-09-15.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-03.txt

Delivery-date: Wed, 01 Sep 2004 20:09:55 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-loose-path-reopt-00.txt
Date: Wed, 01 Sep 2004 16:07:44 -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		: Reoptimization of MPLS Traffic Engineering 
			  loosely routed LSP
	Author(s)	: J-P Vasseur, et al.
	Filename	: draft-ietf-ccamp-loose-path-reopt-00.txt
	Pages		: 12
	Date		: 2004-9-1
	
This document defines a mechanism for the reoptimization of loosely 
   routed MPLS and GMPLS Traffic Engineering LSPs. A loosely routed LSP 
   follows a path specified as a combination of strict and loose hop(s) 
   that contains at least one loose hop and zero or more strict hop(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-loose-path-reopt-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-loose-path-reopt-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-loose-path-reopt-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-loose-path-reopt-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, 01 Sep 2004 18:55:33 +0000
content-class: urn:content-classes:message
Subject: RE: Communication from the OIF
Date: Wed, 1 Sep 2004 13:53:29 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "John Drake" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Lyndon,

As you say, it is not for CCAMP to comment on OIF's definition of
"basis" in regards to ITU Recommendations.=20

Your comment triggered another item which we should include - we still
have not received any response from OIF on CCAMP's previous liaison
(March) regarding OIF's intentions with their OSPF work. I suggest we
add the following:

-  request (again) clarification on the intention of their OSPF
development work/demo, and voice concern that CCAMP's proposed wording
to clarify as experimental was not in the OIF press releases.

And the following:
- repeat our previously liaisoned concerns to ITU (Dec, 2003) on G7713.2
defining GMPLS-redundant objects and mechanisms. As OIF's demo
identified issues with G7713.2 (SPC, lack of crankback support), CCAMP
requests OIF to work with ITU towards alignment of G7713.2 with GMPLS
standard mechanisms vs. further divergence.
- in the interests of future cooperation, encourage OIF to timely
communicate questions/concerns regarding IETF protocols, e.g. prior to
OIF protocol development/demos.

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, September 01, 2004 12:46 PM
To: [email-masked]'; [email-masked]'
Cc: 'John Drake'; Adrian Farrel; [email-masked]
Subject: RE: Communication from the OIF

Hi Dimitri,

I'm glad that we seem to be moving in a productive direction.
This is probably not the right venue to discuss alignment
between the OIF and ITU, we can discuss further offline=20
if you have concerns with some of the options chosen in the
OIF IA, and I can provide further input on any differences
within the routing solutions design team. =20

I would note that the ITU itself was supportive of the interoperability
test and provided material for the OIF booth at the Supercomm show.=20

Cheers,

Lyndon=20

-----Original Message-----
From: dimitri papadimitriou [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 1:30 AM
To: Ong, Lyndon
Cc: [email-masked]'; 'John Drake'; Adrian Farrel;
[email-masked]
Subject: Re: Communication from the OIF

hi lyndon,

> More on the testing and the E-NNI:
>=20
> -- the testing used the OIF Intra-Carrier E-NNI implementation
agreement
> (http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf)=20
> RSVP signaling, but this is closely aligned with G.7713.2, there
> are no additional protocol elements incorporated beyond G.7713.2. =20

thanks for the pointers, this said, and more specifically, it seems that

(after a first look on the "RSVP oriented part" of the above mentioned=20
document) that it provides a specific ERO profile (section 11.3.2) that=20
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study."
(type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in=20
section 11.3.3) relationship between GENERALIZED_UNI object fields usage

for call identification purposes and CALL_ID object definition in=20
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts=20
the above "close alignment" statement under questioning

> The testing also involved, as you mention, the OIF UNI 1.0 rel2
agreement
> (http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
> the UNI.
>=20
> -- there is a description of control domain in the E-NNI Introduction
section,
> reading
> "A control domain is an architectural construct that provides for
encapsulation and
> information hiding, and the characteristics of the control domain are
the same as
> those of its constituent set of distributed architectural components."
> It is similar to the description in G.8080 Amendment 1 for ASON.

thanks, but i start to wonder about the verbage here "similar" ,=20
"closely aligned" , "based on" , etc. i mean are these definitions=20
(strictly) identical (or not) ? such information will help the WG in=20
further aligning its GMPLS/ASON efforts as part of the present exchanges

> -- thanks for the clarification on the GMPLS-OSPF reference, missed it
the
> first time around.  Is the gist of your suggestion that the link
should be
> advertised with 0 reservable capacity in the case identified in the
liaison?

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

> -- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable,
it
> might be a way forward on the reachability concern.  We could discuss
this
> further in the routing solutions design team.

agreed, this constitutes (at least) a good basis for initiating=20
discussion on reachability

thanks,
- dimitri.

> Cheers,
>=20
> Lyndon
>=20
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: [email-masked]; Adrian Farrel;
[email-masked]
> Subject: Re: Communication from the OIF
>=20
>=20
> hi lyndon, john, all,
>=20
>=20
>>Looks like you two would be great candidates for writing
>>the liaison reply!
>=20
>=20
> ok - we (if john agrees) will collect input and suggest a first
response=20
> to the list=20
>=20
>>Some responses to Dimitri's questions:
>=20
> thanks - see below for some additional input/question/comments:
>=20
>>-- the architecture was intended to be consistent with ASON and the
>>testing was focused on E-NNI and UNI interfaces, the signaling
protocol
>>at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)
>=20
> to get a closure on this the demo included the OIF UNI IA (?) and the=20
> ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not
tested=20
> ?) so, if this assumption is correct there are two major implications
no=20
> call functionality was part of the demo (seems to be confirmed by the=20
> below response) and all OIF E-NNI IA specifics that are not part of=20
> G.7713.2 were also not demo'ed - would you please confirm/clarify ?
>=20
>>-- switched connections were set up across E-NNI boundaries
>>
>>-- I'll check on the exact definition of domain, where would you find=20
>>the best definition in the IETF context?
> =20
> just to clarify the question was referring to the OIF definition of=20
> "domain" in order to understand the scope of the "OIF E-NNI routing -=20
> link state inter-domain routing" demo item
>=20
> now, a good pointer for a domain definition in the "IETF context" is=20
> probably the one provided in:
>=20
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-frame
work-00.txt>
>=20
> "[...] a domain is considered to be any collection of network elements

> within a common sphere of address management or path computational=20
> responsibility. Examples of such domains include IGP areas and=20
> Autonomous Systems. However, domains of computational responsibility
may=20
> also exist as sub-domains of areas or ASs. Wholly or partially=20
> overlapping domains are not within the scope of this document."=20
>=20
>>-- both set up and tear down of connections was tested
>>
>>-- the issue mentioned with SUKLM was not a comment against the
current
>>IETF drafts, just a note that some implementors had not kept up with=20
>>the changes in the drafts from a year or two back to merge SONET and
SDH
>=20
>=20
> as mentioned, the v08.txt document is in the RFC Editor queue (to be=20
> clarified in the response)
>=20
>=20
>>-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
>>but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
>>you clarify the reference?
>=20
>=20
> i meant "Section 2. Implications on Graceful Restart" of
>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensi
ons-12.txt>
>=20
>>-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
>>method of advertising reachability to a non-OSPF LER, but the draft=20
>>appears to be designed for a router to advertise its own local
addresses,
>>can this be used to advertise reachable addresses as well?
>=20
>=20
> as OIF devised assignment of "client addresses" from the network
(edges)=20
> so, one can assume these local addresses can follow the same procedure

> defined in the above referenced document - this is just an application

> of this i-d (not even an extension) as the pool of "client addresses"
is=20
> in fact owned by the network (edges)
>=20
>=20
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:[email-masked]]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: [email-masked]; Adrian Farrel
>>Cc: [email-masked]
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: [email-masked]
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>hi adrian, all, see in-line
>>>
>>>
>>>
>>>>We have received a communication from the OIF. This is pasted as
>>>>ASCII text below.
>>>>
>>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>>
>>>>There are several direct questions and issues raised in the
>>>>communication and we should respond. Volunteers to draft text are
>>>>eagerly sort.
>>>>
>>>>Adrian
>>>>
>>>>=3D=3D=3D=3D August 11, 2004 Mr. Adrian Farrel, [email-masked], =
IETF,
>>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>>Routing Area Director Mr. Bill Fenner, [email-masked],
IETF,
>>>>Routing Area Director Re: Results from OIF World Interoperability
>>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>>
>>>>Thank you for your recent communication of June 27, 2004. We
>>>>appreciate the ongoing dialogue and information provided.
>>>>
>>>>As previously communicated, the OIF successfully held its World
>>>>Interoperability Demo at Supercomm 2004 (see
>>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>>This demo included the ASON compliant OIF UNI and ENNI
Implementation
>>>>Agreements.
>>>
>>>if i well understand the above statement, is this implicitly meaning
that
>>>OIF developments are architecturally compliant with ASON (G.8080) but
not
>>>(necessarily) compliant with the G.7713.2 specification ? as OIF
maintains
>>>its own implementation agreements ?
>>>
>>>
>>>
>>>>Due to the number of implementations involved (15 vendors, 7
>>>>carriers) we were able to learn much from the demo. The OIF would
>>>>like to share some of these control plane results and solicit
>>>>guidance from CCAMP on some issues. Successful interoperability
tests
>>>>included:
>>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>>  calls including those that traversed ENNIs.
>>>
>>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>>interfaces ?
>>>
>>>
>>>
>>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>>  vice-versa)
>>>>?? ENNI routing - link state inter-domain routing
>>>
>>>it would be of interest to have the OIF definition of "domain" in
order to
>>>understand the relationship of the above test with the current IETF
CCAMP
>>>efforts and related
>>>
>>>
>>>
>>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>>  connection. This used the common signal type of 6.
>>>
>>>as an aside question were both setup and teardown requests tested in
the
>>>above interoperability tests ?
>>>
>>>
>>>
>>>>Some things we learned were:
>>>>?? In addition to the Srefresh message,
>>>>it was helpful to periodically send the full refresh message as it
>>>>helped the topology display system track calls. (This is consistent
>>>>with an option described in RFC 2961 section 5.5.)
>>>>
>>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>>context for the SPC egress label because for the interdomain case,
>>>>the name of the egress network element would not necessarily be
>>>>known.
>>>
>>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node
to
>>>the address of one of its numbered TE links and a SESSION_OBJECT set
by
>>>the ingress node to the address of one of the egress' numbered TE
links
>>>such that the connection is only be made between the corr.
interfaces,
>>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>>RFC 3473 (explicit label control) provides for the same functionality
>>>
>>>
>>>
>>>>?? Interpretation of the encoding for SUKLM. There was some
>>>>inconsistency in the interpretation of the S bit setting which we
>>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>>Implementers should be encouraged to adhere to
>>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>>
>>>this document is in the RFC Editor and hangs on a cyclic reference to
>>>the GMPLS architecture document
>>>
>>>
>>>
>>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>>unavailable. Since the network does not support crankback (yet),
>>>>there is no way to recover from this situation. It is suggested that
>>>>a link attribute be added to state whether the link capacity being
>>>>advertised is available for new connection admission.
>>>
>>>why operation described in section 2 (Section 2. Implications on
Graceful
>>>Restart) of GMPLS-OSPF is not applied in this case ?
>>>
>>>
>>>
>>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>>capability proposed in which a client that has an SPC becomes UNI
>>>>capable and the operator wants to create SC state for the client so
>>>>that it can teardown the call (as opposed to the management system).
>>>>Any thoughts on how this might be done would be appreciated.
>>>
>>>use of the splicing operation with the already established SPC (using
the
>>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>>should
>>>deliver the expected functionality
>>>
>>>
>>>
>>>>?? There is confusion if a Router ID must be the same value as a
>>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>>32-bit number assigned to each router running the OSPF protocol." It
>>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>>address. It specifically states: "The address space of IP networks
>>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>>defines Router ID as: ". a stable IP address of an LSR that is
always
>>>>reachable if there is any connectivity to the LSR." It goes on to
>>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it
is
>>>>not clear if the usage of Router ID here is referencing the OSPF
>>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>>requested. Maintaining the independence between OSPF's Router ID,
and
>>>>the IP addresses used on a LSR is a powerful and necessary
>>>>capability as it allows for the renumbering of links without causing
>>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>>resulting flushing and regeneration of all locally originated LSAs
>>>>describing attached broadcast networks and links.
>>>
>>>there are two statements in the above:
>>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>>  -> looking at the resp. definitions, the former is an address
>>>  ("typically implemented as a "loopback address") and the latter is
>>>  a 32 bit number that may make use of local IP address values
>>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>>  Router_Address/(IS-IS) TE Router_ID
>>>
>>>so in both cases (as determined by 1.) what precludes rule 2 to be
applied
>>>in OIF IAs ? i should point out that above mentioned footnote does
only
>>>points out that "a network may have an IP address which is identical
(when
>>>considered as a 32-bit number) to some router's Router ID." it does
not
>>>say
>>>that the router_ID can not borrow its 32 bit number value from local
IP
>>>addressing space (section 5 of RFC 2328) - it is thus important to
avoid
>>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>>Router_ID
>>>to be both syntaxically and semantically an "IP address"
>>>
>>>it is also unclear why OIF renumbering IAs require change of any
Router_ID
>>>in addition to the renumbering of the local/remote interface_id (for
>>>unnumbered link) ? if this is the case - why so ?
>>>
>>>
>>>
>>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>>results in an unnecessary behavior that causes significant churn in
>>>>the LSDB, and potential disruption of TE-route calculation, when
>>>>renumbering is done.
>>>
>>>see above
>>>
>>>
>>>
>>>>. MPLS-TE does not allow for nodes that are not participating in
OSPF
>>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>>as a path computation server, to perform route calculation on its
>>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>>However, since the LER is not participating in OSPF, it has no way
to
>>>>advertise where it appears in the network. Consequently, ingress
>>>>LERs will not be able to calculate routes to this egress LSR. A
>>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>>needs to be developed.
>>>
>>>there is somehow an ambuiguity in this question, using the following
>>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>>reachability, but i don't see how the ingress LSR (client ?) could
make
>>>use of this information since ingress and egress LSR are simply nodes
>>>not participating on the OSPF instance ?
>>>
>>>
>>>
>>>>We also recommend the following item be considered by the ASON
>>>>routing solutions design team:
>>>>
>>>>. The ASON routing architecture allows for the abstraction of
>>>>information when hierarchical routing is utilized. This abstraction
>>>>is handled by a transformation function that exists between the
Child
>>>>Area and the Parent Area. The amount of transformation of routing
>>>>information performed can be described as a continuum with the
>>>>following extremes: . Let all link and node information through with
>>>>no changes . Abstract all link and node information provided by the
>>>>Child Area into a single node. (This was successfully tested in the
>>>>recent demo.)
>>>
>>>-> i'll pass the above information to the ASON RSDT
>>>
>>>
>>>
>>>>Other approaches exist on this continuum, but may be complex to
>>>>define. Consequently, we believe these approaches may be best left
as
>>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Delivery-date: Wed, 01 Sep 2004 17:14:41 +0000
Date: Wed, 01 Sep 2004 13:13:38 -0400
To: "John Drake" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Communication from the OIF
Cc: <[email-masked]>, <[email-masked]>, "Ong, Lyndon" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

John,  Dimitri,
         I suggest that the response also include some text on the 
difference in switching types supported by GMPLS and OIF.  (OIF currently 
only supports TDM switching.)

Much thanks,
Lou

At 03:19 PM 8/31/2004 -0400, John Drake wrote:

>Snipped
>
> > -----Original Message-----
> > From: dimitri papadimitriou 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, August 31, 2004 11:08 AM
> > To: Ong, Lyndon; John Drake
> > Cc: [email-masked]; Adrian Farrel; [email-masked]
> > Subject: Re: Communication from the OIF
> >
> > hi lyndon, john, all,
> >
> > > Looks like you two would be great candidates for writing
> > > the liaison reply!
> >
> > ok - we (if john agrees) will collect input and suggest a first response
> > to the list
> >
>[John Drake]
>
>Fine with me

Delivery-date: Wed, 01 Sep 2004 16:46:48 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: 'John Drake' <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
Subject: RE: Communication from the OIF
Date: Wed, 1 Sep 2004 09:45:43 -0700 

Hi Dimitri,

I'm glad that we seem to be moving in a productive direction.
This is probably not the right venue to discuss alignment
between the OIF and ITU, we can discuss further offline 
if you have concerns with some of the options chosen in the
OIF IA, and I can provide further input on any differences
within the routing solutions design team.  

I would note that the ITU itself was supportive of the interoperability
test and provided material for the OIF booth at the Supercomm show. 

Cheers,

Lyndon 

-----Original Message-----
From: dimitri papadimitriou [mailto:[email-masked]]
Sent: Wednesday, September 01, 2004 1:30 AM
To: Ong, Lyndon
Cc: [email-masked]'; 'John Drake'; Adrian Farrel;
[email-masked]
Subject: Re: Communication from the OIF

hi lyndon,

> More on the testing and the E-NNI:
> 
> -- the testing used the OIF Intra-Carrier E-NNI implementation agreement
> (http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf) 
> RSVP signaling, but this is closely aligned with G.7713.2, there
> are no additional protocol elements incorporated beyond G.7713.2.  

thanks for the pointers, this said, and more specifically, it seems that 
(after a first look on the "RSVP oriented part" of the above mentioned 
document) that it provides a specific ERO profile (section 11.3.2) that 
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study." (type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in 
section 11.3.3) relationship between GENERALIZED_UNI object fields usage 
for call identification purposes and CALL_ID object definition in 
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts 
the above "close alignment" statement under questioning

> The testing also involved, as you mention, the OIF UNI 1.0 rel2 agreement
> (http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
> the UNI.
> 
> -- there is a description of control domain in the E-NNI Introduction section,
> reading
> "A control domain is an architectural construct that provides for encapsulation and
> information hiding, and the characteristics of the control domain are the same as
> those of its constituent set of distributed architectural components."
> It is similar to the description in G.8080 Amendment 1 for ASON.

thanks, but i start to wonder about the verbage here "similar" , 
"closely aligned" , "based on" , etc. i mean are these definitions 
(strictly) identical (or not) ? such information will help the WG in 
further aligning its GMPLS/ASON efforts as part of the present exchanges

> -- thanks for the clarification on the GMPLS-OSPF reference, missed it the
> first time around.  Is the gist of your suggestion that the link should be
> advertised with 0 reservable capacity in the case identified in the liaison?

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

> -- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable, it
> might be a way forward on the reachability concern.  We could discuss this
> further in the routing solutions design team.

agreed, this constitutes (at least) a good basis for initiating 
discussion on reachability

thanks,
- dimitri.

> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> Subject: Re: Communication from the OIF
> 
> 
> hi lyndon, john, all,
> 
> 
>>Looks like you two would be great candidates for writing
>>the liaison reply!
> 
> 
> ok - we (if john agrees) will collect input and suggest a first response 
> to the list 
> 
>>Some responses to Dimitri's questions:
> 
> thanks - see below for some additional input/question/comments:
> 
>>-- the architecture was intended to be consistent with ASON and the
>>testing was focused on E-NNI and UNI interfaces, the signaling protocol
>>at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)
> 
> to get a closure on this the demo included the OIF UNI IA (?) and the 
> ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not tested 
> ?) so, if this assumption is correct there are two major implications no 
> call functionality was part of the demo (seems to be confirmed by the 
> below response) and all OIF E-NNI IA specifics that are not part of 
> G.7713.2 were also not demo'ed - would you please confirm/clarify ?
> 
>>-- switched connections were set up across E-NNI boundaries
>>
>>-- I'll check on the exact definition of domain, where would you find 
>>the best definition in the IETF context?
>  
> just to clarify the question was referring to the OIF definition of 
> "domain" in order to understand the scope of the "OIF E-NNI routing - 
> link state inter-domain routing" demo item
> 
> now, a good pointer for a domain definition in the "IETF context" is 
> probably the one provided in:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt>
> 
> "[...] a domain is considered to be any collection of network elements 
> within a common sphere of address management or path computational 
> responsibility. Examples of such domains include IGP areas and 
> Autonomous Systems. However, domains of computational responsibility may 
> also exist as sub-domains of areas or ASs. Wholly or partially 
> overlapping domains are not within the scope of this document." 
> 
>>-- both set up and tear down of connections was tested
>>
>>-- the issue mentioned with SUKLM was not a comment against the current
>>IETF drafts, just a note that some implementors had not kept up with 
>>the changes in the drafts from a year or two back to merge SONET and SDH
> 
> 
> as mentioned, the v08.txt document is in the RFC Editor queue (to be 
> clarified in the response)
> 
> 
>>-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
>>but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
>>you clarify the reference?
> 
> 
> i meant "Section 2. Implications on Graceful Restart" of
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt>
> 
>>-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
>>method of advertising reachability to a non-OSPF LER, but the draft 
>>appears to be designed for a router to advertise its own local addresses,
>>can this be used to advertise reachable addresses as well?
> 
> 
> as OIF devised assignment of "client addresses" from the network (edges) 
> so, one can assume these local addresses can follow the same procedure 
> defined in the above referenced document - this is just an application 
> of this i-d (not even an extension) as the pool of "client addresses" is 
> in fact owned by the network (edges)
> 
> 
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:[email-masked]]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: [email-masked]; Adrian Farrel
>>Cc: [email-masked]
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: [email-masked]
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>hi adrian, all, see in-line
>>>
>>>
>>>
>>>>We have received a communication from the OIF. This is pasted as
>>>>ASCII text below.
>>>>
>>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>>
>>>>There are several direct questions and issues raised in the
>>>>communication and we should respond. Volunteers to draft text are
>>>>eagerly sort.
>>>>
>>>>Adrian
>>>>
>>>>==== August 11, 2004 Mr. Adrian Farrel, [email-masked], IETF,
>>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>>Routing Area Director Mr. Bill Fenner, [email-masked], IETF,
>>>>Routing Area Director Re: Results from OIF World Interoperability
>>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>>
>>>>Thank you for your recent communication of June 27, 2004. We
>>>>appreciate the ongoing dialogue and information provided.
>>>>
>>>>As previously communicated, the OIF successfully held its World
>>>>Interoperability Demo at Supercomm 2004 (see
>>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>>This demo included the ASON compliant OIF UNI and ENNI Implementation
>>>>Agreements.
>>>
>>>if i well understand the above statement, is this implicitly meaning that
>>>OIF developments are architecturally compliant with ASON (G.8080) but not
>>>(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
>>>its own implementation agreements ?
>>>
>>>
>>>
>>>>Due to the number of implementations involved (15 vendors, 7
>>>>carriers) we were able to learn much from the demo. The OIF would
>>>>like to share some of these control plane results and solicit
>>>>guidance from CCAMP on some issues. Successful interoperability tests
>>>>included:
>>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>>  calls including those that traversed ENNIs.
>>>
>>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>>interfaces ?
>>>
>>>
>>>
>>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>>  vice-versa)
>>>>?? ENNI routing - link state inter-domain routing
>>>
>>>it would be of interest to have the OIF definition of "domain" in order to
>>>understand the relationship of the above test with the current IETF CCAMP
>>>efforts and related
>>>
>>>
>>>
>>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>>  connection. This used the common signal type of 6.
>>>
>>>as an aside question were both setup and teardown requests tested in the
>>>above interoperability tests ?
>>>
>>>
>>>
>>>>Some things we learned were:
>>>>?? In addition to the Srefresh message,
>>>>it was helpful to periodically send the full refresh message as it
>>>>helped the topology display system track calls. (This is consistent
>>>>with an option described in RFC 2961 section 5.5.)
>>>>
>>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>>context for the SPC egress label because for the interdomain case,
>>>>the name of the egress network element would not necessarily be
>>>>known.
>>>
>>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
>>>the address of one of its numbered TE links and a SESSION_OBJECT set by
>>>the ingress node to the address of one of the egress' numbered TE links
>>>such that the connection is only be made between the corr. interfaces,
>>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>>RFC 3473 (explicit label control) provides for the same functionality
>>>
>>>
>>>
>>>>?? Interpretation of the encoding for SUKLM. There was some
>>>>inconsistency in the interpretation of the S bit setting which we
>>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>>Implementers should be encouraged to adhere to
>>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>>
>>>this document is in the RFC Editor and hangs on a cyclic reference to
>>>the GMPLS architecture document
>>>
>>>
>>>
>>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>>unavailable. Since the network does not support crankback (yet),
>>>>there is no way to recover from this situation. It is suggested that
>>>>a link attribute be added to state whether the link capacity being
>>>>advertised is available for new connection admission.
>>>
>>>why operation described in section 2 (Section 2. Implications on Graceful
>>>Restart) of GMPLS-OSPF is not applied in this case ?
>>>
>>>
>>>
>>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>>capability proposed in which a client that has an SPC becomes UNI
>>>>capable and the operator wants to create SC state for the client so
>>>>that it can teardown the call (as opposed to the management system).
>>>>Any thoughts on how this might be done would be appreciated.
>>>
>>>use of the splicing operation with the already established SPC (using the
>>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>>should
>>>deliver the expected functionality
>>>
>>>
>>>
>>>>?? There is confusion if a Router ID must be the same value as a
>>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>>32-bit number assigned to each router running the OSPF protocol." It
>>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>>address. It specifically states: "The address space of IP networks
>>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>>defines Router ID as: ". a stable IP address of an LSR that is always
>>>>reachable if there is any connectivity to the LSR." It goes on to
>>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
>>>>not clear if the usage of Router ID here is referencing the OSPF
>>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>>requested. Maintaining the independence between OSPF's Router ID, and
>>>>the IP addresses used on a LSR is a powerful and necessary
>>>>capability as it allows for the renumbering of links without causing
>>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>>resulting flushing and regeneration of all locally originated LSAs
>>>>describing attached broadcast networks and links.
>>>
>>>there are two statements in the above:
>>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>>  -> looking at the resp. definitions, the former is an address
>>>  ("typically implemented as a "loopback address") and the latter is
>>>  a 32 bit number that may make use of local IP address values
>>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>>  Router_Address/(IS-IS) TE Router_ID
>>>
>>>so in both cases (as determined by 1.) what precludes rule 2 to be applied
>>>in OIF IAs ? i should point out that above mentioned footnote does only
>>>points out that "a network may have an IP address which is identical (when
>>>considered as a 32-bit number) to some router's Router ID." it does not
>>>say
>>>that the router_ID can not borrow its 32 bit number value from local IP
>>>addressing space (section 5 of RFC 2328) - it is thus important to avoid
>>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>>Router_ID
>>>to be both syntaxically and semantically an "IP address"
>>>
>>>it is also unclear why OIF renumbering IAs require change of any Router_ID
>>>in addition to the renumbering of the local/remote interface_id (for
>>>unnumbered link) ? if this is the case - why so ?
>>>
>>>
>>>
>>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>>results in an unnecessary behavior that causes significant churn in
>>>>the LSDB, and potential disruption of TE-route calculation, when
>>>>renumbering is done.
>>>
>>>see above
>>>
>>>
>>>
>>>>. MPLS-TE does not allow for nodes that are not participating in OSPF
>>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>>as a path computation server, to perform route calculation on its
>>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>>However, since the LER is not participating in OSPF, it has no way to
>>>>advertise where it appears in the network. Consequently, ingress
>>>>LERs will not be able to calculate routes to this egress LSR. A
>>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>>needs to be developed.
>>>
>>>there is somehow an ambuiguity in this question, using the following
>>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>>reachability, but i don't see how the ingress LSR (client ?) could make
>>>use of this information since ingress and egress LSR are simply nodes
>>>not participating on the OSPF instance ?
>>>
>>>
>>>
>>>>We also recommend the following item be considered by the ASON
>>>>routing solutions design team:
>>>>
>>>>. The ASON routing architecture allows for the abstraction of
>>>>information when hierarchical routing is utilized. This abstraction
>>>>is handled by a transformation function that exists between the Child
>>>>Area and the Parent Area. The amount of transformation of routing
>>>>information performed can be described as a continuum with the
>>>>following extremes: . Let all link and node information through with
>>>>no changes . Abstract all link and node information provided by the
>>>>Child Area into a single node. (This was successfully tested in the
>>>>recent demo.)
>>>
>>>-> i'll pass the above information to the ASON RSDT
>>>
>>>
>>>
>>>>Other approaches exist on this continuum, but may be complex to
>>>>define. Consequently, we believe these approaches may be best left as
>>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>>
>>
>>
>>.
>>
> 
> 
> .
> 

Envelope-to: [email-masked]
Delivery-date: Wed, 01 Sep 2004 16:20:06 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: 'GMPLS Signaling Procedure For Egress Control' to None 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 01 Sep 2004 11:46:17 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

- 'GMPLS Signaling Procedure For Egress Control '
   <draft-ietf-ccamp-gmpls-egress-control-03.txt> as a None

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-09-15.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-03.txt

Delivery-date: Wed, 01 Sep 2004 12:42:06 +0000
Date: Wed, 01 Sep 2004 09:39:55 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------lpmlmtkgyyvrzbsijxjm
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>fotogalary and Music<br><br>

<br> :)<img src="cid:gkiuheuqrv.gif"><br>
<br>
</body></html>

----------lpmlmtkgyyvrzbsijxjm
Content-Type: image/gif; name="gkiuheuqrv.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gkiuheuqrv.gif"
Content-ID: 

----------lpmlmtkgyyvrzbsijxjm
Content-Type: application/octet-stream; name="New_MP3_Player.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="New_MP3_Player.zip"

----------lpmlmtkgyyvrzbsijxjm--

Delivery-date: Wed, 01 Sep 2004 08:30:47 +0000
Date: Wed, 01 Sep 2004 10:29:45 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked],  [email-masked],  [email-masked]
To: "Ong, Lyndon" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, 'John Drake' <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
Subject: Re: Communication from the OIF

hi lyndon,

> More on the testing and the E-NNI:
> 
> -- the testing used the OIF Intra-Carrier E-NNI implementation agreement
> (http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf) 
> RSVP signaling, but this is closely aligned with G.7713.2, there
> are no additional protocol elements incorporated beyond G.7713.2.  

thanks for the pointers, this said, and more specifically, it seems that 
(after a first look on the "RSVP oriented part" of the above mentioned 
document) that it provides a specific ERO profile (section 11.3.2) that 
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study." (type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in 
section 11.3.3) relationship between GENERALIZED_UNI object fields usage 
for call identification purposes and CALL_ID object definition in 
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts 
the above "close alignment" statement under questioning

> The testing also involved, as you mention, the OIF UNI 1.0 rel2 agreement
> (http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
> the UNI.
> 
> -- there is a description of control domain in the E-NNI Introduction section,
> reading
> "A control domain is an architectural construct that provides for encapsulation and
> information hiding, and the characteristics of the control domain are the same as
> those of its constituent set of distributed architectural components."
> It is similar to the description in G.8080 Amendment 1 for ASON.

thanks, but i start to wonder about the verbage here "similar" , 
"closely aligned" , "based on" , etc. i mean are these definitions 
(strictly) identical (or not) ? such information will help the WG in 
further aligning its GMPLS/ASON efforts as part of the present exchanges

> -- thanks for the clarification on the GMPLS-OSPF reference, missed it the
> first time around.  Is the gist of your suggestion that the link should be
> advertised with 0 reservable capacity in the case identified in the liaison?

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

> -- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable, it
> might be a way forward on the reachability concern.  We could discuss this
> further in the routing solutions design team.

agreed, this constitutes (at least) a good basis for initiating 
discussion on reachability

thanks,
- dimitri.

> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> Subject: Re: Communication from the OIF
> 
> 
> hi lyndon, john, all,
> 
> 
>>Looks like you two would be great candidates for writing
>>the liaison reply!
> 
> 
> ok - we (if john agrees) will collect input and suggest a first response 
> to the list 
> 
>>Some responses to Dimitri's questions:
> 
> thanks - see below for some additional input/question/comments:
> 
>>-- the architecture was intended to be consistent with ASON and the
>>testing was focused on E-NNI and UNI interfaces, the signaling protocol
>>at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)
> 
> to get a closure on this the demo included the OIF UNI IA (?) and the 
> ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not tested 
> ?) so, if this assumption is correct there are two major implications no 
> call functionality was part of the demo (seems to be confirmed by the 
> below response) and all OIF E-NNI IA specifics that are not part of 
> G.7713.2 were also not demo'ed - would you please confirm/clarify ?
> 
>>-- switched connections were set up across E-NNI boundaries
>>
>>-- I'll check on the exact definition of domain, where would you find 
>>the best definition in the IETF context?
>  
> just to clarify the question was referring to the OIF definition of 
> "domain" in order to understand the scope of the "OIF E-NNI routing - 
> link state inter-domain routing" demo item
> 
> now, a good pointer for a domain definition in the "IETF context" is 
> probably the one provided in:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt>
> 
> "[...] a domain is considered to be any collection of network elements 
> within a common sphere of address management or path computational 
> responsibility. Examples of such domains include IGP areas and 
> Autonomous Systems. However, domains of computational responsibility may 
> also exist as sub-domains of areas or ASs. Wholly or partially 
> overlapping domains are not within the scope of this document." 
> 
>>-- both set up and tear down of connections was tested
>>
>>-- the issue mentioned with SUKLM was not a comment against the current
>>IETF drafts, just a note that some implementors had not kept up with 
>>the changes in the drafts from a year or two back to merge SONET and SDH
> 
> 
> as mentioned, the v08.txt document is in the RFC Editor queue (to be 
> clarified in the response)
> 
> 
>>-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
>>but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
>>you clarify the reference?
> 
> 
> i meant "Section 2. Implications on Graceful Restart" of
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt>
> 
>>-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
>>method of advertising reachability to a non-OSPF LER, but the draft 
>>appears to be designed for a router to advertise its own local addresses,
>>can this be used to advertise reachable addresses as well?
> 
> 
> as OIF devised assignment of "client addresses" from the network (edges) 
> so, one can assume these local addresses can follow the same procedure 
> defined in the above referenced document - this is just an application 
> of this i-d (not even an extension) as the pool of "client addresses" is 
> in fact owned by the network (edges)
> 
> 
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:[email-masked]]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: [email-masked]; Adrian Farrel
>>Cc: [email-masked]
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: [email-masked]
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>hi adrian, all, see in-line
>>>
>>>
>>>
>>>>We have received a communication from the OIF. This is pasted as
>>>>ASCII text below.
>>>>
>>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>>
>>>>There are several direct questions and issues raised in the
>>>>communication and we should respond. Volunteers to draft text are
>>>>eagerly sort.
>>>>
>>>>Adrian
>>>>
>>>>==== August 11, 2004 Mr. Adrian Farrel, [email-masked], IETF,
>>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>>Routing Area Director Mr. Bill Fenner, [email-masked], IETF,
>>>>Routing Area Director Re: Results from OIF World Interoperability
>>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>>
>>>>Thank you for your recent communication of June 27, 2004. We
>>>>appreciate the ongoing dialogue and information provided.
>>>>
>>>>As previously communicated, the OIF successfully held its World
>>>>Interoperability Demo at Supercomm 2004 (see
>>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>>This demo included the ASON compliant OIF UNI and ENNI Implementation
>>>>Agreements.
>>>
>>>if i well understand the above statement, is this implicitly meaning that
>>>OIF developments are architecturally compliant with ASON (G.8080) but not
>>>(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
>>>its own implementation agreements ?
>>>
>>>
>>>
>>>>Due to the number of implementations involved (15 vendors, 7
>>>>carriers) we were able to learn much from the demo. The OIF would
>>>>like to share some of these control plane results and solicit
>>>>guidance from CCAMP on some issues. Successful interoperability tests
>>>>included:
>>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>>  calls including those that traversed ENNIs.
>>>
>>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>>interfaces ?
>>>
>>>
>>>
>>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>>  vice-versa)
>>>>?? ENNI routing - link state inter-domain routing
>>>
>>>it would be of interest to have the OIF definition of "domain" in order to
>>>understand the relationship of the above test with the current IETF CCAMP
>>>efforts and related
>>>
>>>
>>>
>>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>>  connection. This used the common signal type of 6.
>>>
>>>as an aside question were both setup and teardown requests tested in the
>>>above interoperability tests ?
>>>
>>>
>>>
>>>>Some things we learned were:
>>>>?? In addition to the Srefresh message,
>>>>it was helpful to periodically send the full refresh message as it
>>>>helped the topology display system track calls. (This is consistent
>>>>with an option described in RFC 2961 section 5.5.)
>>>>
>>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>>context for the SPC egress label because for the interdomain case,
>>>>the name of the egress network element would not necessarily be
>>>>known.
>>>
>>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
>>>the address of one of its numbered TE links and a SESSION_OBJECT set by
>>>the ingress node to the address of one of the egress' numbered TE links
>>>such that the connection is only be made between the corr. interfaces,
>>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>>RFC 3473 (explicit label control) provides for the same functionality
>>>
>>>
>>>
>>>>?? Interpretation of the encoding for SUKLM. There was some
>>>>inconsistency in the interpretation of the S bit setting which we
>>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>>Implementers should be encouraged to adhere to
>>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>>
>>>this document is in the RFC Editor and hangs on a cyclic reference to
>>>the GMPLS architecture document
>>>
>>>
>>>
>>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>>unavailable. Since the network does not support crankback (yet),
>>>>there is no way to recover from this situation. It is suggested that
>>>>a link attribute be added to state whether the link capacity being
>>>>advertised is available for new connection admission.
>>>
>>>why operation described in section 2 (Section 2. Implications on Graceful
>>>Restart) of GMPLS-OSPF is not applied in this case ?
>>>
>>>
>>>
>>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>>capability proposed in which a client that has an SPC becomes UNI
>>>>capable and the operator wants to create SC state for the client so
>>>>that it can teardown the call (as opposed to the management system).
>>>>Any thoughts on how this might be done would be appreciated.
>>>
>>>use of the splicing operation with the already established SPC (using the
>>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>>should
>>>deliver the expected functionality
>>>
>>>
>>>
>>>>?? There is confusion if a Router ID must be the same value as a
>>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>>32-bit number assigned to each router running the OSPF protocol." It
>>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>>address. It specifically states: "The address space of IP networks
>>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>>defines Router ID as: ". a stable IP address of an LSR that is always
>>>>reachable if there is any connectivity to the LSR." It goes on to
>>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
>>>>not clear if the usage of Router ID here is referencing the OSPF
>>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>>requested. Maintaining the independence between OSPF's Router ID, and
>>>>the IP addresses used on a LSR is a powerful and necessary
>>>>capability as it allows for the renumbering of links without causing
>>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>>resulting flushing and regeneration of all locally originated LSAs
>>>>describing attached broadcast networks and links.
>>>
>>>there are two statements in the above:
>>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>>  -> looking at the resp. definitions, the former is an address
>>>  ("typically implemented as a "loopback address") and the latter is
>>>  a 32 bit number that may make use of local IP address values
>>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>>  Router_Address/(IS-IS) TE Router_ID
>>>
>>>so in both cases (as determined by 1.) what precludes rule 2 to be applied
>>>in OIF IAs ? i should point out that above mentioned footnote does only
>>>points out that "a network may have an IP address which is identical (when
>>>considered as a 32-bit number) to some router's Router ID." it does not
>>>say
>>>that the router_ID can not borrow its 32 bit number value from local IP
>>>addressing space (section 5 of RFC 2328) - it is thus important to avoid
>>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>>Router_ID
>>>to be both syntaxically and semantically an "IP address"
>>>
>>>it is also unclear why OIF renumbering IAs require change of any Router_ID
>>>in addition to the renumbering of the local/remote interface_id (for
>>>unnumbered link) ? if this is the case - why so ?
>>>
>>>
>>>
>>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>>results in an unnecessary behavior that causes significant churn in
>>>>the LSDB, and potential disruption of TE-route calculation, when
>>>>renumbering is done.
>>>
>>>see above
>>>
>>>
>>>
>>>>. MPLS-TE does not allow for nodes that are not participating in OSPF
>>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>>as a path computation server, to perform route calculation on its
>>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>>However, since the LER is not participating in OSPF, it has no way to
>>>>advertise where it appears in the network. Consequently, ingress
>>>>LERs will not be able to calculate routes to this egress LSR. A
>>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>>needs to be developed.
>>>
>>>there is somehow an ambuiguity in this question, using the following
>>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>>reachability, but i don't see how the ingress LSR (client ?) could make
>>>use of this information since ingress and egress LSR are simply nodes
>>>not participating on the OSPF instance ?
>>>
>>>
>>>
>>>>We also recommend the following item be considered by the ASON
>>>>routing solutions design team:
>>>>
>>>>. The ASON routing architecture allows for the abstraction of
>>>>information when hierarchical routing is utilized. This abstraction
>>>>is handled by a transformation function that exists between the Child
>>>>Area and the Parent Area. The amount of transformation of routing
>>>>information performed can be described as a continuum with the
>>>>following extremes: . Let all link and node information through with
>>>>no changes . Abstract all link and node information provided by the
>>>>Child Area into a single node. (This was successfully tested in the
>>>>recent demo.)
>>>
>>>-> i'll pass the above information to the ASON RSDT
>>>
>>>
>>>
>>>>Other approaches exist on this continuum, but may be complex to
>>>>define. Consequently, we believe these approaches may be best left as
>>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>>
>>
>>
>>.
>>
> 
> 
> .
> 

Delivery-date: Wed, 01 Sep 2004 00:49:14 +0000
Date: Tue, 31 Aug 2004 17:47:16 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Lou Berger <[email-masked]>
CC: "Adrian Farrel" <[email-masked]>, [email-masked]
Subject: Re: Fw: AD-review comments on  draft-ietf-ccamp-gmpls-egress-control

IETF Last Call requested. Thanks, Lou.

-- 
Alex
http://www.psg.com/~zinin

Monday, August 30, 2004, 1:30:13 PM, Lou Berger wrote:
> Draft has been updated and resubmitted.

> Alex,
>          Thanks again for the review.

> Lou

> At 06:12 PM 8/28/2004 -0400, Adrian Farrel wrote:

>>Hi,
>>
>>The AD (Alex) has reviewed this draft and just has a couple of editorial 
>>nits.
>>If the editor (Lou) would like to make the changes and re-submit, we can 
>>get the draft to
>>go forward.
>>
>>Lou, please don't forget to run the draft through the IDnits script before 
>>submitting it.
>>
>>Thanks,
>>Adrian
>>
>>----- Original Message -----
>>From: "Alex Zinin" <[email-masked]>
>>
>> > Ed: please use the new ID boilerplates.
>> >
>> > > Abstract
>> > >
>> > >    This note clarifies the procedures for the control of the label used
>> > >    on a output/downstream interface of the egress node of a Label
>> > >    Switched Path (LSP).  Such control is also known as "Egress Control".
>> > >    Support for Egress Control is implicit in Generalized Multi-Protocol
>> > >    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
>> > >    signaling mechanisms and procedures and should be viewed as an
>> > >    informative clarification of GMPLS Signaling - Resource ReserVation
>> > >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
>> >
>> > Given that the doc goes STD track, I suggest that the last sentence is
>> > changed to say "This note is a clarification update to the specification
>> > of GMPLS Signaling..."
>> >
>> > > Author's Note
>> > >
>> > >    This draft is targeted for publication as a BCP.
>> >
>> > This one should be removed for the same reason.