Subject: FW: draft-etf-ccamp-lmp-test-sonet-sdh-00.txt
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Date: Sat, 30 Nov 2002 17:15:01 +0100

Mmm... I thought I had posted this to the ccamp list...
Oh well, here it is... a bit belated.

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: maandag 18 november 2002 9:54
To: Steve Trowbridge (E-mail); Kireeti Kompella (E-mail); Ron Bonica
(E-mail)
Subject: draft-etf-ccamp-lmp-test-sonet-sdh-00.txt

Steve, since you seem to be the liason during todays CCAMP
meeting, pls do check with appropriate ITU-T SGs to find out
if they see any problems with this document and it going for
standards tarck. Sooner is better than later please.
Could you at least try to get back to us by Jan 1st, at least
with the status?

At the same time, if any WG member has comment on this (supportive
comments are fine too), pls post them to the list.

WG members who spoke up at the WG session, pls post your comments
to the list as well. That will help to drive faster to WG concensus

Thanks,
Bert 

Delivery-date: Fri, 29 Nov 2002 04:19:47 -0800
Date: Fri, 29 Nov 2002 13:19:30 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: John Drake <[email-masked]>
Cc: "Ong, Lyndon" <[email-masked]>, "'Ron Bonica'" <[email-masked]>, [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

john, the point is probably that from a * protocol *
viewpoint i didn't hear any compelling argument during
the meeting (or on the mailing list), so if there are 
any gmpls signalling or other protocol issues that seems 
unclear for the ccamp community it would be very good 
to settle them asap in order to move forward with this 
i-d

imho, this is the only reason why kireeti asked to move 
the discussion to the list

thanks,
- dimitri.

John Drake wrote:
> 
> My count was 27 yes, 3 no to the question of whether the overlay I-D should
> become a working group draft
> 
> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 4:25 PM
> To: 'Ron Bonica'; [email-masked]
> Cc: [email-masked]
> Subject: RE: IETF 55 - CCAMP Minutes
> 
> Hi Ron,
> 
> Just adding some more notes on George's overlay presentation -
> 
> The question was raised on the difference between this
> and the OIF UNI work, George responded that the OIF UNI
> is aimed at public service providers with a separate
> address space, while this is not.  George also noted
> that the current addressing in Session and Sender_Template
> objects may be overly constrained for overlay.
> 
> IMHO, I'm not sure I would say a vast majority supported
> it, the vast majority was generally pretty quiet at the meeting.
> 
> Cheers,
> 
> Lyndon Ong
> 
> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 7:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: IETF 55 - CCAMP Minutes
> 
> Thanks!
> 
> I will add this to the minutes.
> 
>                   Ron
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Sunday, November 24, 2002 10:12 PM
> > To: Ron Bonica
> > Cc: [email-masked]
> > Subject: Re: IETF 55 - CCAMP Minutes
> >
> >
> > hi ron, all
> >
> > i do not see the report on the gmpls for overlay networks
> > what i have is as follows (may be others can correct me
> > or complete this):
> >
> > G.Swallow: discussed the application of gmpls for overlay
> > networks, ending with a proposal for making this a
> > wg i-d (proposed standard) see for more details:
> > http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
> >
> > K.Kompella: asked for people in favor/opposed: the result
> > was that only a few people (2 or 3) were opposed whilst
> > the vast majority were in favor
> >
> > S.Throwbridge: asked whether the proposal was aligned with
> > the carrier requirements (without more details)
> >
> > K.Kompella: let's bring it to the mailing list.
> >
> > also some comments:
> >
> > "> Dmitri: Could you comment on applicability of incompatibility with
> > other
> > > documents."
> >
> > "Can you comment on backward compatibility with the other lmp
> > documents ?"
> >
> > thanks,
> > - dimitri.
> >
> > Ron Bonica wrote:
> > >
> > > Folks,
> > >
> > > CCAMP WG minutes follow. Slides are attached. Please comment on
> > the minutes
> > > within two weeks so that we can make any required corrections
> > and enter them
> > > into the record.
> > >
> > >                                            Ron
> > >
> > > P.S. Kireeti's presentation provides a snapshot of WG status. I
> > will make
> > > sure that the ID tracker stays up to date so we will always
> > have a current
> > > picture of WG status.
> > >
> > > ===============================
> > >
> > > IETF 54 CCAMP Meeting Minutes
> > > ==============================
> > >
> > > Schedule rearranged due to technical difficulties.....
> > >
> > > Kireeti:  Can someone come up here and sing during the break? *)
> > >
> > > 0935 - 0950
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
> > >                 Lang
> > >
> > > Provided summary of updates to LMP draft.  See his slides for details.
> > > Thinks we are ready for IESG last call. Summary of updates to
> > LMP WDM draft.
> > > See slides for details. Ready for WG last call.
> > >
> > > Bonica: initiate last call on list after meeting.
> > >
> > > LMP Test Sonet SDH draft. See slides for details. After
> > changes, we should
> > > solicit
> > > comments from list. We would like a WG last call thereafter.
> > Get a feel from
> > > the room?
> > >
> > > Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> > >
> > > Bert: The base LMP document was intended for proposed standard. We got
> > > pushback
> > > from ITU people stating that we should not be working on some
> > of this stuff,
> > > so we
> > > split it out to a separate document. Are we intending on prop
> > standard for
> > > this stuff?
> > >
> > > Kireeti: Yes, prop. Standards stuff.
> > >
> > > Bert: Are we on our proper turf? I would like ITU people to
> > speak up on this
> > > as well
> > > as review it. I don't want discussion during last call, want
> > resolution now.
> > >
> > > Speaker 1: Question RE: LMP. After this meeting I intend to
> > start a draft.
> > > After reading LMP specification, I believe it has mandatory
> > configuration.
> > > Are there security considerations.
> > >
> > > Lang: Yes, security considerations are mandatory.
> > >
> > > Speaker 1: I would like security to be optional.
> > >
> > > Bert: Security considerations may not be optional.  We can have some as
> > > optional,
> > > but some mandatory security options are required.
> > >
> > > Kireeti: It is mandatory to define security - how to run LMP in a secure
> > > mode.
> > > It is not mandatory to run LMP in a secure mode. Can you?
> > >
> > > Lang: That is correct, it can be run un-secure.  Ipsec is
> > defined for LMP.
> > > If you do not want to run IPSec, you can run it without.
> > >
> > > Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> > > consistent with ITU
> > > T.50 requirement. Printable ASCII characters in particular might be an
> > > issue.
> > >
> > > Bert: Please pose question to mailing list.
> > >
> > > Ron: That way we will have record of conversation.
> > >
> > > Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
> > Will there
> > > be any
> > > additional alignment with this?
> > >
> > > Lang: I think the 7714.1 document is more closely related to bootstrap
> > > document, and
> > > I would lke to discuss this in next part of presentation.
> > >
> > > Lyndon: This is now taking LMP and LMP-WDM that are tech
> > specific. Are there
> > > any non-tech
> > > specific things that cannot be applied to both.
> > >
> > > Lang: The whole document can be applied to both.
> > >
> > > Kireeti: Is there any objection in ITU from letting IETF have
> > this document
> > > or will
> > > we dribble out requirements one by one?
> > >
> > > ITU leason: I cannot speak for all ITUT, but we need to socialize this
> > > within the ITU.
> > > There is work going on with regard to discovery in ITU 7714
> > that might need
> > > to be aligned.
> > > However, I will try to get discussion going on rapidly.
> > >
> > > Dmitry P:  There may be issues with the way the messages are encoded.
> > >
> > > Kireeti:  We are not talking about discovery; test messages.
> > Documents were
> > > separated
> > > so that we can work issues doc-by-doc.  Good to get ruling for each
> > > document. The
> > > typical issues with using J0 etc... has rules for how to use this.  Make
> > > clear that
> > > that some issues are about before service starts.
> > >
> > > Speaker 5: 7714 issue: if they do the same thing, then why define two
> > > documents for this?
> > >
> > > Lang: There may be overlap between next document, but not here.
> > >
> > > Speaker 5: Need to be clear about what the overlaps are.
> > >
> > > Lang: Bootstrap document (next doc), the intro describes why
> > the doc exists.
> > > Prev. document is defined in LMP base document. If you disagree, let me
> > > know.
> > >
> > > LMP Bootstrap document. See slides for details. This is not WG document.
> > > Would like
> > > technical comments on list.
> > >
> > > Dmitri: Could you comment on applicability of incompatibility with other
> > > documents.
> > >
> > > Lang: The point to make is the information exchanged is the
> > same as that for
> > > the LMP
> > > protocol. There is no new information exchanged.
> > >
> > > Kireeti: We need to continue this on the list (ITU input) on how we move
> > > these documents
> > > forward.
> > >
> > > Kireeti - CCAMP 55 WG status.
> > >
> > > Kireeti: Is there any problem with sending GMPLS framework to IESG as
> > > informational.
> > >
> > > Bert: I reviewed this doc a while back, and question is that
> > non-standard
> > > extensions are
> > > detailed here. This seems strange to publish a document that
> > suggests a way
> > > of signaling
> > > things without a document being somewhere that details the specifics
> > > somewhere.
> > >
> > > Dmitri: We have been looking for comments RE: pointers/document
> > to fulfill
> > > your query. I
> > > think it is unfair to continue without filling these
> > requirements. When I
> > > sent comments
> > > on the list, I asked people to provide pointers. If people would like to
> > > continue, please
> > > send pointers ASAP.
> > >
> > > Kireeti: As a fallback, what are we going to do if no docs are received.
> > >
> > > Bert: Throw it into the garbage.
> > >
> > > Kireeti: Unless we get pointers, this goes in the can.
> > >
> > > Kireeti: One thing has been asked about is changes to the
> > charter. We want
> > > to make
> > > changes to the charter. Please send us suggestions. Few additions:
> > > inter-area (within AS
> > > domain),  Protection/restoration, optical VPN.  This will be discussed
> > > partially during
> > > SUB-IP meeting, but approval of charter changes come from IESG.
> > >
> > > JPV: Question about the charter. Will signaling between
> > computation server
> > > and client are
> > > part of the charter, or do we need to add?
> > >
> > > Kireeti: The current charter does not explicitly have this.
> > This is part of
> > > the charter
> > > extensions we are asking for.
> > >
> > > JPV: This can be used in other areas.
> > >
> > > Kireeti: Don't go there. If it is in the charter it is, if not
> > then no. Need
> > > to make sure
> > > this is in the charter.
> > >
> > > Ron: I will send out an update on the charter additions
> > (proposed) to the
> > > mailing list.
> > >
> > > Ashok - Interoperability draft.
> > >
> > > Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> > > issues for RSVP.
> > >
> > > Bert: These are separate documents. Do this in RSVP.
> > >
> > > Lou:  Spec. requires TSPEC. Lets talk about this offline.
> > >
> > > Kireeti: Okay. I want to talk about some implementation
> > recommendations. How
> > > are these
> > > published?
> > >
> > > Bert: Implementation recommendations are fine to either publish
> > as BCP or
> > > Informational.
> > > I am worried about the limited set of specifications/issues and
> > that they
> > > are captured.
> > >
> > > Kireeti: Generic RSVP things are already specified (according
> > to Lou). Lets
> > > talk about
> > > this offline to see where changes are required. Define what
> > issues are, how
> > > are they
> > > specified. Do this offline.  Should we add recommendations to
> > implementation
> > > survey as an
> > > appendix?
> > >
> > > Bert: Whichever.
> > >
> > > Lou: These look like guidelines to implementations. This is usually done
> > > outside of spec.
> > > done as BCP/Info.
> > >
> > > Kireeti: Question is where to put it.
> > >
> > > Lou: Seems like this is not a BCP.
> > >
> > > Kireeti: Too early to say that these include "best" practices. Looks
> > > informational.
> > > Need to talk with Lou about remaining issues.
> > >
> > > Tom Nadeau did a presentation on the discussions
> > > regarding the GMPLS MIBs at the Sat MIB Meeting.
> > >
> > > * how Saturday meeting affects the GMPLS MIBs?
> > >
> > > * issues for CCAMP: how to represent SONET (i.e.
> > > longer) labels
> > >
> > > * proposed solution on label/index given
> > >   Tom asked for feedback from the working group
> > >    on this proposed solution
> > >
> > >    type field + octet string
> > >
> > >    goal is to support longer labels
> > >
> > > * Comment by Kireeti to rename
> > >   Link Bundling MIB to TE-LINK-MIB.
> > >
> > > (No questions on presentation).
> > >
> > > Nadeau: MIB overview presentation
> > >
> > > Dora: MIB discussion. 2 issues.
> > >
> > > Tom: SNMP is just another management interface, and like any
> > other tool, it
> > > needs to be
> > > used appropriately. Otherwise, you will have scalability and
> > provisioning
> > > issues.
> > >
> > > Kireeti: Lets have a discussion on the list for all of these things.
> > >
> > > Bert: Discussion going on in IESG/SNMP community. Been hearing
> > that people
> > > do not want to
> > > use SNMP for configuration.   However, I will defer to the WG
> > for guidance
> > > on this. We
> > > need discussion on this issue, in particular from operators.
> > > Kireeti: We should take this to the mailing list.
> > >
> > > Protection/Restoration Team:
> > >
> > > Kireeti: I suggest that you kick off a discussion so that
> > people can pick on
> > > points that
> > > might be controversial. We need to do this before we make this a WG
> > > document.  We need to
> > > take this into account.
> > >
> > > Dmitri:  We took existing protocols and analysed them.   What I
> > have said is
> > > a
> > > consolidation. I think we are fine with the scope. We need to
> > focus on the
> > > validation.
> > >
> > > Kireeti: We need to make sure there is a consensus on your cut
> > off that it
> > > was reasonable.
> > >
> > > Bonica: Tunnel trace draft. See slides.  Is the requirements
> > draft ready for
> > > WG last call.
> > >
> > > Monique:  How is this going to relate to LSP Ping?
> > >
> > > Ron: When you discover a tunnel, GTTP invokes LSP ping.  There
> > is one open
> > > item: if the
> > > LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> > >
> > > Kireeti: Are there any comments from anyone else?  The
> > requirements document
> > > is a WG
> > > document. Can we have a show of hands for support of GTTP
> > proposed solution
> > > as WG
> > > document?  We have a small consensus in favor of this. Go back
> > to mailing
> > > list to confirm.
> > >
> > > Dmitri: Draft.
> > >
> > > Dmitri: When you increase the scope of what GMPLS may cover. We need to
> > > handle the
> > > limited complexity here. This is what we have worked on.   We
> > need to handle
> > > optical/PSTN.
> > >
> > > Kireeti: Lets not make this a WG document until discussion on the list.
> > >
> > > ===========================================
> > > Ronald P. Bonica       Ph: 703 886 1681
> > > vBNS Engineering       page: 1 888 268 8021
> > > Ashburn, Va.
> > > ===========================================
> > > "We are not on Earth to guard a museum, but
> > > to cultivate a flourishing garden of life."
> > >                 -- Angelo Giuseppe Roncalli
> > >
> > >
> > ------------------------------------------------------------------------
> > >                  Name: IETF55.zip
> > >    IETF55.zip    Type: Zip Compressed Data
> > (application/x-zip-compressed)
> > >              Encoding: base64
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 27 Nov 2002 19:04:17 -0800
From: John Drake <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, 'Ron Bonica' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes
Date: Wed, 27 Nov 2002 19:00:37 -0800

My count was 27 yes, 3 no to the question of whether the overlay I-D should
become a working group draft

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]
Sent: Monday, November 25, 2002 4:25 PM
To: 'Ron Bonica'; [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes

Hi Ron,

Just adding some more notes on George's overlay presentation -

The question was raised on the difference between this
and the OIF UNI work, George responded that the OIF UNI
is aimed at public service providers with a separate
address space, while this is not.  George also noted 
that the current addressing in Session and Sender_Template
objects may be overly constrained for overlay.

IMHO, I'm not sure I would say a vast majority supported
it, the vast majority was generally pretty quiet at the meeting.

Cheers,

Lyndon Ong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: Sunday, November 24, 2002 7:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes

Thanks!

I will add this to the minutes.

                  Ron

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 10:12 PM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: IETF 55 - CCAMP Minutes
>
>
> hi ron, all
>
> i do not see the report on the gmpls for overlay networks
> what i have is as follows (may be others can correct me
> or complete this):
>
> G.Swallow: discussed the application of gmpls for overlay
> networks, ending with a proposal for making this a
> wg i-d (proposed standard) see for more details:
> http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
>
> K.Kompella: asked for people in favor/opposed: the result
> was that only a few people (2 or 3) were opposed whilst
> the vast majority were in favor
>
> S.Throwbridge: asked whether the proposal was aligned with
> the carrier requirements (without more details)
>
> K.Kompella: let's bring it to the mailing list.
>
> also some comments:
>
> "> Dmitri: Could you comment on applicability of incompatibility with
> other
> > documents."
>
> "Can you comment on backward compatibility with the other lmp
> documents ?"
>
> thanks,
> - dimitri.
>
> Ron Bonica wrote:
> >
> > Folks,
> >
> > CCAMP WG minutes follow. Slides are attached. Please comment on
> the minutes
> > within two weeks so that we can make any required corrections
> and enter them
> > into the record.
> >
> >                                            Ron
> >
> > P.S. Kireeti's presentation provides a snapshot of WG status. I
> will make
> > sure that the ID tracker stays up to date so we will always
> have a current
> > picture of WG status.
> >
> > ===============================
> >
> > IETF 54 CCAMP Meeting Minutes
> > ==============================
> >
> > Schedule rearranged due to technical difficulties.....
> >
> > Kireeti:  Can someone come up here and sing during the break? *)
> >
> > 0935 - 0950
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
> >                 Lang
> >
> > Provided summary of updates to LMP draft.  See his slides for details.
> > Thinks we are ready for IESG last call. Summary of updates to
> LMP WDM draft.
> > See slides for details. Ready for WG last call.
> >
> > Bonica: initiate last call on list after meeting.
> >
> > LMP Test Sonet SDH draft. See slides for details. After
> changes, we should
> > solicit
> > comments from list. We would like a WG last call thereafter.
> Get a feel from
> > the room?
> >
> > Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> >
> > Bert: The base LMP document was intended for proposed standard. We got
> > pushback
> > from ITU people stating that we should not be working on some
> of this stuff,
> > so we
> > split it out to a separate document. Are we intending on prop
> standard for
> > this stuff?
> >
> > Kireeti: Yes, prop. Standards stuff.
> >
> > Bert: Are we on our proper turf? I would like ITU people to
> speak up on this
> > as well
> > as review it. I don't want discussion during last call, want
> resolution now.
> >
> > Speaker 1: Question RE: LMP. After this meeting I intend to
> start a draft.
> > After reading LMP specification, I believe it has mandatory
> configuration.
> > Are there security considerations.
> >
> > Lang: Yes, security considerations are mandatory.
> >
> > Speaker 1: I would like security to be optional.
> >
> > Bert: Security considerations may not be optional.  We can have some as
> > optional,
> > but some mandatory security options are required.
> >
> > Kireeti: It is mandatory to define security - how to run LMP in a secure
> > mode.
> > It is not mandatory to run LMP in a secure mode. Can you?
> >
> > Lang: That is correct, it can be run un-secure.  Ipsec is
> defined for LMP.
> > If you do not want to run IPSec, you can run it without.
> >
> > Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> > consistent with ITU
> > T.50 requirement. Printable ASCII characters in particular might be an
> > issue.
> >
> > Bert: Please pose question to mailing list.
> >
> > Ron: That way we will have record of conversation.
> >
> > Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
> Will there
> > be any
> > additional alignment with this?
> >
> > Lang: I think the 7714.1 document is more closely related to bootstrap
> > document, and
> > I would lke to discuss this in next part of presentation.
> >
> > Lyndon: This is now taking LMP and LMP-WDM that are tech
> specific. Are there
> > any non-tech
> > specific things that cannot be applied to both.
> >
> > Lang: The whole document can be applied to both.
> >
> > Kireeti: Is there any objection in ITU from letting IETF have
> this document
> > or will
> > we dribble out requirements one by one?
> >
> > ITU leason: I cannot speak for all ITUT, but we need to socialize this
> > within the ITU.
> > There is work going on with regard to discovery in ITU 7714
> that might need
> > to be aligned.
> > However, I will try to get discussion going on rapidly.
> >
> > Dmitry P:  There may be issues with the way the messages are encoded.
> >
> > Kireeti:  We are not talking about discovery; test messages.
> Documents were
> > separated
> > so that we can work issues doc-by-doc.  Good to get ruling for each
> > document. The
> > typical issues with using J0 etc... has rules for how to use this.  Make
> > clear that
> > that some issues are about before service starts.
> >
> > Speaker 5: 7714 issue: if they do the same thing, then why define two
> > documents for this?
> >
> > Lang: There may be overlap between next document, but not here.
> >
> > Speaker 5: Need to be clear about what the overlaps are.
> >
> > Lang: Bootstrap document (next doc), the intro describes why
> the doc exists.
> > Prev. document is defined in LMP base document. If you disagree, let me
> > know.
> >
> > LMP Bootstrap document. See slides for details. This is not WG document.
> > Would like
> > technical comments on list.
> >
> > Dmitri: Could you comment on applicability of incompatibility with other
> > documents.
> >
> > Lang: The point to make is the information exchanged is the
> same as that for
> > the LMP
> > protocol. There is no new information exchanged.
> >
> > Kireeti: We need to continue this on the list (ITU input) on how we move
> > these documents
> > forward.
> >
> > Kireeti - CCAMP 55 WG status.
> >
> > Kireeti: Is there any problem with sending GMPLS framework to IESG as
> > informational.
> >
> > Bert: I reviewed this doc a while back, and question is that
> non-standard
> > extensions are
> > detailed here. This seems strange to publish a document that
> suggests a way
> > of signaling
> > things without a document being somewhere that details the specifics
> > somewhere.
> >
> > Dmitri: We have been looking for comments RE: pointers/document
> to fulfill
> > your query. I
> > think it is unfair to continue without filling these
> requirements. When I
> > sent comments
> > on the list, I asked people to provide pointers. If people would like to
> > continue, please
> > send pointers ASAP.
> >
> > Kireeti: As a fallback, what are we going to do if no docs are received.
> >
> > Bert: Throw it into the garbage.
> >
> > Kireeti: Unless we get pointers, this goes in the can.
> >
> > Kireeti: One thing has been asked about is changes to the
> charter. We want
> > to make
> > changes to the charter. Please send us suggestions. Few additions:
> > inter-area (within AS
> > domain),  Protection/restoration, optical VPN.  This will be discussed
> > partially during
> > SUB-IP meeting, but approval of charter changes come from IESG.
> >
> > JPV: Question about the charter. Will signaling between
> computation server
> > and client are
> > part of the charter, or do we need to add?
> >
> > Kireeti: The current charter does not explicitly have this.
> This is part of
> > the charter
> > extensions we are asking for.
> >
> > JPV: This can be used in other areas.
> >
> > Kireeti: Don't go there. If it is in the charter it is, if not
> then no. Need
> > to make sure
> > this is in the charter.
> >
> > Ron: I will send out an update on the charter additions
> (proposed) to the
> > mailing list.
> >
> > Ashok - Interoperability draft.
> >
> > Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> > issues for RSVP.
> >
> > Bert: These are separate documents. Do this in RSVP.
> >
> > Lou:  Spec. requires TSPEC. Lets talk about this offline.
> >
> > Kireeti: Okay. I want to talk about some implementation
> recommendations. How
> > are these
> > published?
> >
> > Bert: Implementation recommendations are fine to either publish
> as BCP or
> > Informational.
> > I am worried about the limited set of specifications/issues and
> that they
> > are captured.
> >
> > Kireeti: Generic RSVP things are already specified (according
> to Lou). Lets
> > talk about
> > this offline to see where changes are required. Define what
> issues are, how
> > are they
> > specified. Do this offline.  Should we add recommendations to
> implementation
> > survey as an
> > appendix?
> >
> > Bert: Whichever.
> >
> > Lou: These look like guidelines to implementations. This is usually done
> > outside of spec.
> > done as BCP/Info.
> >
> > Kireeti: Question is where to put it.
> >
> > Lou: Seems like this is not a BCP.
> >
> > Kireeti: Too early to say that these include "best" practices. Looks
> > informational.
> > Need to talk with Lou about remaining issues.
> >
> > Tom Nadeau did a presentation on the discussions
> > regarding the GMPLS MIBs at the Sat MIB Meeting.
> >
> > * how Saturday meeting affects the GMPLS MIBs?
> >
> > * issues for CCAMP: how to represent SONET (i.e.
> > longer) labels
> >
> > * proposed solution on label/index given
> >   Tom asked for feedback from the working group
> >    on this proposed solution
> >
> >    type field + octet string
> >
> >    goal is to support longer labels
> >
> > * Comment by Kireeti to rename
> >   Link Bundling MIB to TE-LINK-MIB.
> >
> > (No questions on presentation).
> >
> > Nadeau: MIB overview presentation
> >
> > Dora: MIB discussion. 2 issues.
> >
> > Tom: SNMP is just another management interface, and like any
> other tool, it
> > needs to be
> > used appropriately. Otherwise, you will have scalability and
> provisioning
> > issues.
> >
> > Kireeti: Lets have a discussion on the list for all of these things.
> >
> > Bert: Discussion going on in IESG/SNMP community. Been hearing
> that people
> > do not want to
> > use SNMP for configuration.   However, I will defer to the WG
> for guidance
> > on this. We
> > need discussion on this issue, in particular from operators.
> > Kireeti: We should take this to the mailing list.
> >
> > Protection/Restoration Team:
> >
> > Kireeti: I suggest that you kick off a discussion so that
> people can pick on
> > points that
> > might be controversial. We need to do this before we make this a WG
> > document.  We need to
> > take this into account.
> >
> > Dmitri:  We took existing protocols and analysed them.   What I
> have said is
> > a
> > consolidation. I think we are fine with the scope. We need to
> focus on the
> > validation.
> >
> > Kireeti: We need to make sure there is a consensus on your cut
> off that it
> > was reasonable.
> >
> > Bonica: Tunnel trace draft. See slides.  Is the requirements
> draft ready for
> > WG last call.
> >
> > Monique:  How is this going to relate to LSP Ping?
> >
> > Ron: When you discover a tunnel, GTTP invokes LSP ping.  There
> is one open
> > item: if the
> > LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> >
> > Kireeti: Are there any comments from anyone else?  The
> requirements document
> > is a WG
> > document. Can we have a show of hands for support of GTTP
> proposed solution
> > as WG
> > document?  We have a small consensus in favor of this. Go back
> to mailing
> > list to confirm.
> >
> > Dmitri: Draft.
> >
> > Dmitri: When you increase the scope of what GMPLS may cover. We need to
> > handle the
> > limited complexity here. This is what we have worked on.   We
> need to handle
> > optical/PSTN.
> >
> > Kireeti: Lets not make this a WG document until discussion on the list.
> >
> > ===========================================
> > Ronald P. Bonica       Ph: 703 886 1681
> > vBNS Engineering       page: 1 888 268 8021
> > Ashburn, Va.
> > ===========================================
> > "We are not on Earth to guard a museum, but
> > to cultivate a flourishing garden of life."
> >                 -- Angelo Giuseppe Roncalli
> >
> >
> ------------------------------------------------------------------------
> >                  Name: IETF55.zip
> >    IETF55.zip    Type: Zip Compressed Data
> (application/x-zip-compressed)
> >              Encoding: base64
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 26 Nov 2002 10:27:10 -0800
From: Jonathan Lang <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>, Peter Wery <[email-masked]>
Cc: "Razdan, Rajender" <[email-masked]>, John Drake <[email-masked]>, [email-masked],  "'Brungard, Deborah A, ALASO '" <[email-masked]>, [email-masked]
Subject: RE: J0/J1 encoding issues
Date: Tue, 26 Nov 2002 10:26:14 -0800

Stephen,

<snip>
> 
> I did think it more expeditious to refer people to the OIF
> communication which already contained the desired document rather
> than going through the mechanics of generating a new one.
agreed.

> After
> all, I think the majority of key participants are OIF memebers
> as well.
I have access to the OIF website, but I can't speak for others.

> 
> I will copy Kam Lam, the Rapporteur of Q.14/15 on this email so
> that he is aware of your interest. The next meeting of Q.14/15 is
> not until our full Study Group 15 meeting from 20-31 January in
> Geneva, but it is also possible for communication statements to
> be formulated and approved via email correspondence when necessary
> between meetings.
thanks.

-Jonathan

> Regards,
> Steve
> 
> Jonathan Lang wrote:
> > 
> > Stephen,
> >   May I suggest that you add routing & discovery to the
> > communication/liaison statement to the IETF. Since most of 
> the OIF work is
> > based on protocols developed in the IETF, it seems odd that IETF
> > participants need to go through the OIF to see these documents.
> > 
> > Thanks,
> > Jonathan
> > 
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Tuesday, November 26, 2002 9:30 AM
> > > To: Razdan, Rajender
> > > Cc: Jonathan Lang; John Drake; 
> [email-masked]; 'Brungard,
> > > Deborah A, ALASO '; [email-masked]
> > > Subject: Re: J0/J1 encoding issues
> > >
> > >
> > > All,
> > > There are some rules about distributing ITU-T documents
> > > outside of ITU-T.
> > > Generally, the only way to distribute draft text to non-ITU-T
> > > members is by
> > > sending them via communication/liaison statements to
> > > organizations outside
> > > of ITU-T.
> > >
> > > G.7714.1 has not been officially communicated to IETF ccamp,
> > > but it has
> > > been communicated to OIF in which many of you 
> participate. To obtain a
> > > copy of the document from the communication statement to 
> OIF, start by
> > > pointing your browser to:
> > > ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> > > /COMMUNICATIONS/index.html
> > >
> > > From there, choose the link for Optical Internetworking 
> Forum (OIF).
> > > Acknowledge the ITU-T copyright.
> > > Choose the communication statement dated 11 October 2002 entitled:
> > > "Signaling, Routing, and Discovery work in Q.14/15".
> > >
> > > There are links in this communication for the download of
> > > several documents,
> > > the last of which is the latest draft of G.7714.1.
> > > Regards,
> > > Steve Trowbridge
> > > Vice-Chairman, ITU-T Study Group 15
> > >
> > > "Razdan, Rajender" wrote:
> > > >
> > > > [ post by non-subscriber.  with the massive amount of spam,
> > > it is easy to
> > > >   miss and therefore delete mis-posts.  so fix subscription
> > > addresses! ]
> > > >
> > > > Jonathan,
> > > >
> > > >     I welcome the idea of making the draft of G.7714.1 
> more freely
> > > > available. I don't know, however, if there are any ITU 
> rules about
> > > > distributing draft documents. One possibility, which I 
> have often
> > > > seen used in the past, is to send the latest version as a
> > > contribution
> > > > to a T1X1.5 meeting. These contributions are freely 
> available to the
> > > > public. Noting that we do have an upcoming T1X1.5 
> meeting, I'll go
> > > > ahead and do that.
> > > >
> > > > Cheers,
> > > > Rajender Razdan
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: Monday, November 25, 2002 10:28 PM
> > > > To: Razdan, Rajender; John Drake; [email-masked]
> > > > Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > Rajender,
> > > >   May I suggest that the authors of the G.7714.1 draft make
> > > it available to
> > > > the wider community. As it is still a draft with most of
> > > the discussion
> > > > amongst authors and not on a public mailing list, most
> > > people have not had a
> > > > chance to look at the latest version which is significantly
> > > different from
> > > > the one discussed at the Experts meeting in Ottawa.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > > -----Original Message-----
> > > > > From: Razdan, Rajender [mailto:[email-masked]]
> > > > > Sent: Monday, November 25, 2002 8:55 AM
> > > > > To: John Drake; [email-masked]
> > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > Subject: RE: J0/J1 encoding issues
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > >     I don't subscribe to the ccamp mailing list, and so
> > > > > haven't had a chance
> > > > > to comment on the LMP drafts till now. The discussion on
> > > > > J0/J1 issues was
> > > > > forwarded to me by Jonathan Sadler. As the editor of Draft
> > > > > G.7714.1, I was
> > > > > quite distressed to read about your understanding that none
> > > > > of the work aimed
> > > > > at G.7714.1 is compatible with the T.50 requirement. I don't
> > > > > know how you got
> > > > > that absolutely wrong impression. In fact, compatibility with
> > > > > the T.50
> > > > > requirement, as dictated by ITU Rec. G.707, has been the most
> > > > > important
> > > > > consideration for us in our defining J0/J1/J2 discovery
> > > > > mechanisms. The current
> > > > > draft of G.7714.1 clearly states this. I FULLY agree with
> > > > > Jonathan Sadler that
> > > > > the LMP work should also be consistent with this requirement.
> > > > >
> > > > > Regards,
> > > > > Rajender Razdan
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Drake [mailto:[email-masked]]
> > > > > Sent: Monday, November 25, 2002 11:24 AM
> > > > > To: [email-masked]
> > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > Subject: RE: J0/J1 encoding issues
> > > > >
> > > > >
> > > > > Jonathan,
> > > > >
> > > > > The various Test transport mechanisms that are currently
> > > defined in
> > > > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to
> > > > > input from
> > > > > various carriers and organizations such as the OIF.  The
> > > fact that the
> > > > > individual carriers have different requirements for the
> > > > > contents of the
> > > > > various SDH/SONET overheads is also consistent with my
> > > > > reading of Deborah's
> > > > > recent e-mail on this topic.
> > > > >
> > > > > Since one of the transport mechanisms, the J0/J1/J2 trace
> > > correlation,
> > > > > allows the transport of T.50 characters, I think 
> we're done wrt
> > > > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > > > >
> > > > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding
> > > > > that none of the
> > > > > work aimed at G.7714.1 is compatible with the T.50 
> requirement.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > Sent: Thursday, November 21, 2002 8:23 PM
> > > > > To: John Drake
> > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > Subject: Re: J0/J1 encoding issues
> > > > >
> > > > >
> > > > > John -
> > > > >
> > > > > I think you forgot what my original message said.  It stated:
> > > > >
> > > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > > bytes (J0/J1/J2)
> > > > > > > have restrictions not only on the length of a trace
> > > message and on
> > > > > > > the bits usable in a octet, but also on whether the
> > > payload in the
> > > > > > > message uses printable ASCII characters.
> > > > > > >
> > > > > > > The requirements for J0/J1/J2 (found in G.707) 
> state the trace
> > > > > > > message payload must utilize the printable characters
> > > defined in
> > > > > > > T.50.  Two current LMP drafts
> > > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings 
> that are not
> > > > > > > consistant with this requirement.
> > > > >
> > > > > I fail to see what is incorrect with the above.
> > > > >
> > > > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe
> > > methods for
> > > > > J0/J1/J2 that fall within the requirements of G.707, it
> > > also includes
> > > > > methods that don't.  This situation SHOULD be resolved to
> > > provide the
> > > > > greatest amount of interoperability while reducing the
> > > number of trace
> > > > > methods that need to be implemented.
> > > > >
> > > > > I'm glad to see we agree on the fact that
> > > > > draft-lang-ccamp-lmp-bootstrap
> > > > > only provides methods that fall outside the requirements of
> > > > > G.707.  This
> > > > > situation MUST be resolved.
> > > > >
> > > > > Jonathan Sadler
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Wouldn't it be more precise to say that it is an issue with
> > > > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT 
> an issue with
> > > > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > > > To: John Drake
> > > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > > Subject: Re: J0/J1 encoding issues
> > > > > >
> > > > > > John -
> > > > > >
> > > > > > draft-lang-ccamp-lmp-bootstrap does not support Trace
> > > Correlation.
> > > > > > Therefore, it is an issue.
> > > > > >
> > > > > > Jonathan Sadler
> > > > > >
> > > > > > John Drake wrote:
> > > > > > >
> > > > > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> > > > > Correlation,
> > > > > then
> > > > > > > Jonathan Sadler's issue is a non-issue?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jonathan Lang
> > > > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > > > To: 'Brungard, Deborah A, ALASO ';
> > > [email-masked] ';
> > > > > > > 'ccamp '
> > > > > > > Subject: FW: J0/J1 encoding issues
> > > > > > >
> > > > > > > Deborah,
> > > > > > >   Thanks for the note. The option that Jonathan mentioned
> > > > > is one of a
> > > > > > couple
> > > > > > > options we define for Jx. We defined other options to
> > > > > > > interwork with existing equipment without requiring
> > > any changes to
> > > > > > > existing encodings (this would support both C1 and T.50
> > > > > requirements).
> > > > > > > These mechanisms are defined in Section 3.1 as 
> J0/J1/J2 Trace
> > > > > > > Correlation. We welcome additional comments from you
> > > and others at
> > > > > > > T1X1.5/ITU.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jonathan
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brungard, Deborah A, ALASO
> > > > > > > To: [email-masked]; ccamp
> > > > > > > Sent: 11/21/2002 5:22 AM
> > > > > > > Subject: RE: J0/J1 encoding issues
> > > > > > >
> > > > > > > As Jonathan says, the current G.707 is using T.50. And
> > > > > there's more.
> > > > > > > Example, for J0, one currently needs to support:
> > > > > > > - previously defined C1 (repeating one-byte)
> > > > > > > - T.50 (with format of G.707)
> > > > > > > - no J0 (for equipment not supporting).
> > > > > > >
> > > > > > > So already we have defined multiple applications for this
> > > > > byte. Not to
> > > > > > > say, there will be not any new ones. Even ITU knows,
> > > it never is
> > > > > > > final;-)
> > > > > > >
> > > > > > > For supporting LMP's use, we need to understand the
> > > > > scenarios of use
> > > > > > > (sounds familiar to T1X1.5 participants?) e.g. 
> intra-operator,
> > > > > > > inter-operator, applied for equipment installation
> > > verification or
> > > > > > > service connection verification, etc. And hardware
> > > implications.
> > > > > > >
> > > > > > > Actually, G.831 defines multiple uses depending if inter
> > > > > or intra -
> > > > > > > including for intra-operator, support of routing/path
> > > > > set-up (and G.831
> > > > > > > was done years ago).
> > > > > > >
> > > > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> > > > > contribute the
> > > > > > > proposal for the meeting and we can start the discussion.
> > > > > The next ITU-T
> > > > > > > meeting is in January. If the LMP editors need help
> > > on our T1X1.5
> > > > > > > process, just ask.
> > > > > > >
> > > > > > > Deborah
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > > > To: ccamp
> > > > > > > Subject: J0/J1 encoding issues
> > > > > > >
> > > > > > > All -
> > > > > > >
> > > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > > bytes (J0/J1/J2)
> > > > > > > have restrictions not only on the length of a trace
> > > message and on
> > > > > > > the bits usable in a octet, but also on whether the
> > > payload in the
> > > > > > > message uses printable ASCII characters.
> > > > > > >
> > > > > > > The requirements for J0/J1/J2 (found in G.707) 
> state the trace
> > > > > > > message payload must utilize the printable characters
> > > defined in
> > > > > > > T.50.  Two current LMP drafts
> > > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings 
> that are not
> > > > > > > consistant with this requirement.
> > > > > > >
> > > > > > > This message is being sent to document this issue.
> > > It is not a
> > > > > > > statement that no other issues exist -- I expect that the
> > > > > appropriate
> > > > > > > experts in the ITU will review the rest of these two
> > > drafts and
> > > > > > > provide appropriate comment.
> > > > > > >
> > > > > > > Jonathan Sadler
> > > > >
> > > > > (I disclaim the disclaimer that follows this message.)
> > > > > ============================================================
> > > > > The information contained in this message may be privileged
> > > > > and confidential and protected from disclosure.  If the
> > > > > reader of this message is not the intended recipient, or an
> > > > > employee or agent responsible for delivering this message to
> > > > > the intended recipient, you are hereby notified that any
> > > > > reproduction, dissemination or distribution of this
> > > > > communication is strictly prohibited. If you have received
> > > > > this communication in error, please notify us immediately by
> > > > > replying to the message and deleting it from your computer.
> > > > >
> > > > > Thank you.
> > > > > Tellabs
> > > > > ============================================================
> > > > >
> > >
> 

Delivery-date: Tue, 26 Nov 2002 10:22:31 -0800
Date: Tue, 26 Nov 2002 11:20:52 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>, Peter Wery <[email-masked]>
CC: "Razdan, Rajender" <[email-masked]>, John Drake <[email-masked]>, [email-masked], "'Brungard, Deborah A, ALASO '" <[email-masked]>, [email-masked]
Subject: Re: J0/J1 encoding issues

Jonathan,
I do not write these communication statements: they come from the
individual Rapporteur groups doing the work (in this case, Q.14/15).
These are usually generated at meetings (in the case of this one,
and the one to IETF ccamp regarding G.7713.2 and G.7713.3, these
were generated at the meeting of Q.14/15 in Ottawa in October).

I did think it more expeditious to refer people to the OIF
communication which already contained the desired document rather
than going through the mechanics of generating a new one. After
all, I think the majority of key participants are OIF memebers
as well.

I will copy Kam Lam, the Rapporteur of Q.14/15 on this email so
that he is aware of your interest. The next meeting of Q.14/15 is
not until our full Study Group 15 meeting from 20-31 January in
Geneva, but it is also possible for communication statements to
be formulated and approved via email correspondence when necessary
between meetings.
Regards,
Steve

Jonathan Lang wrote:
> 
> Stephen,
>   May I suggest that you add routing & discovery to the
> communication/liaison statement to the IETF. Since most of the OIF work is
> based on protocols developed in the IETF, it seems odd that IETF
> participants need to go through the OIF to see these documents.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, November 26, 2002 9:30 AM
> > To: Razdan, Rajender
> > Cc: Jonathan Lang; John Drake; [email-masked]; 'Brungard,
> > Deborah A, ALASO '; [email-masked]
> > Subject: Re: J0/J1 encoding issues
> >
> >
> > All,
> > There are some rules about distributing ITU-T documents
> > outside of ITU-T.
> > Generally, the only way to distribute draft text to non-ITU-T
> > members is by
> > sending them via communication/liaison statements to
> > organizations outside
> > of ITU-T.
> >
> > G.7714.1 has not been officially communicated to IETF ccamp,
> > but it has
> > been communicated to OIF in which many of you participate. To obtain a
> > copy of the document from the communication statement to OIF, start by
> > pointing your browser to:
> > ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> > /COMMUNICATIONS/index.html
> >
> > From there, choose the link for Optical Internetworking Forum (OIF).
> > Acknowledge the ITU-T copyright.
> > Choose the communication statement dated 11 October 2002 entitled:
> > "Signaling, Routing, and Discovery work in Q.14/15".
> >
> > There are links in this communication for the download of
> > several documents,
> > the last of which is the latest draft of G.7714.1.
> > Regards,
> > Steve Trowbridge
> > Vice-Chairman, ITU-T Study Group 15
> >
> > "Razdan, Rajender" wrote:
> > >
> > > [ post by non-subscriber.  with the massive amount of spam,
> > it is easy to
> > >   miss and therefore delete mis-posts.  so fix subscription
> > addresses! ]
> > >
> > > Jonathan,
> > >
> > >     I welcome the idea of making the draft of G.7714.1 more freely
> > > available. I don't know, however, if there are any ITU rules about
> > > distributing draft documents. One possibility, which I have often
> > > seen used in the past, is to send the latest version as a
> > contribution
> > > to a T1X1.5 meeting. These contributions are freely available to the
> > > public. Noting that we do have an upcoming T1X1.5 meeting, I'll go
> > > ahead and do that.
> > >
> > > Cheers,
> > > Rajender Razdan
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 10:28 PM
> > > To: Razdan, Rajender; John Drake; [email-masked]
> > > Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > Rajender,
> > >   May I suggest that the authors of the G.7714.1 draft make
> > it available to
> > > the wider community. As it is still a draft with most of
> > the discussion
> > > amongst authors and not on a public mailing list, most
> > people have not had a
> > > chance to look at the latest version which is significantly
> > different from
> > > the one discussed at the Experts meeting in Ottawa.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Razdan, Rajender [mailto:[email-masked]]
> > > > Sent: Monday, November 25, 2002 8:55 AM
> > > > To: John Drake; [email-masked]
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > >
> > > > John,
> > > >
> > > >     I don't subscribe to the ccamp mailing list, and so
> > > > haven't had a chance
> > > > to comment on the LMP drafts till now. The discussion on
> > > > J0/J1 issues was
> > > > forwarded to me by Jonathan Sadler. As the editor of Draft
> > > > G.7714.1, I was
> > > > quite distressed to read about your understanding that none
> > > > of the work aimed
> > > > at G.7714.1 is compatible with the T.50 requirement. I don't
> > > > know how you got
> > > > that absolutely wrong impression. In fact, compatibility with
> > > > the T.50
> > > > requirement, as dictated by ITU Rec. G.707, has been the most
> > > > important
> > > > consideration for us in our defining J0/J1/J2 discovery
> > > > mechanisms. The current
> > > > draft of G.7714.1 clearly states this. I FULLY agree with
> > > > Jonathan Sadler that
> > > > the LMP work should also be consistent with this requirement.
> > > >
> > > > Regards,
> > > > Rajender Razdan
> > > >
> > > > -----Original Message-----
> > > > From: John Drake [mailto:[email-masked]]
> > > > Sent: Monday, November 25, 2002 11:24 AM
> > > > To: [email-masked]
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > >
> > > > Jonathan,
> > > >
> > > > The various Test transport mechanisms that are currently
> > defined in
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to
> > > > input from
> > > > various carriers and organizations such as the OIF.  The
> > fact that the
> > > > individual carriers have different requirements for the
> > > > contents of the
> > > > various SDH/SONET overheads is also consistent with my
> > > > reading of Deborah's
> > > > recent e-mail on this topic.
> > > >
> > > > Since one of the transport mechanisms, the J0/J1/J2 trace
> > correlation,
> > > > allows the transport of T.50 characters, I think we're done wrt
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > > >
> > > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding
> > > > that none of the
> > > > work aimed at G.7714.1 is compatible with the T.50 requirement.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Thursday, November 21, 2002 8:23 PM
> > > > To: John Drake
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: Re: J0/J1 encoding issues
> > > >
> > > >
> > > > John -
> > > >
> > > > I think you forgot what my original message said.  It stated:
> > > >
> > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > bytes (J0/J1/J2)
> > > > > > have restrictions not only on the length of a trace
> > message and on
> > > > > > the bits usable in a octet, but also on whether the
> > payload in the
> > > > > > message uses printable ASCII characters.
> > > > > >
> > > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > > message payload must utilize the printable characters
> > defined in
> > > > > > T.50.  Two current LMP drafts
> > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > > consistant with this requirement.
> > > >
> > > > I fail to see what is incorrect with the above.
> > > >
> > > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe
> > methods for
> > > > J0/J1/J2 that fall within the requirements of G.707, it
> > also includes
> > > > methods that don't.  This situation SHOULD be resolved to
> > provide the
> > > > greatest amount of interoperability while reducing the
> > number of trace
> > > > methods that need to be implemented.
> > > >
> > > > I'm glad to see we agree on the fact that
> > > > draft-lang-ccamp-lmp-bootstrap
> > > > only provides methods that fall outside the requirements of
> > > > G.707.  This
> > > > situation MUST be resolved.
> > > >
> > > > Jonathan Sadler
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Wouldn't it be more precise to say that it is an issue with
> > > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > > To: John Drake
> > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > Subject: Re: J0/J1 encoding issues
> > > > >
> > > > > John -
> > > > >
> > > > > draft-lang-ccamp-lmp-bootstrap does not support Trace
> > Correlation.
> > > > > Therefore, it is an issue.
> > > > >
> > > > > Jonathan Sadler
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> > > > Correlation,
> > > > then
> > > > > > Jonathan Sadler's issue is a non-issue?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang
> > > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > > To: 'Brungard, Deborah A, ALASO ';
> > [email-masked] ';
> > > > > > 'ccamp '
> > > > > > Subject: FW: J0/J1 encoding issues
> > > > > >
> > > > > > Deborah,
> > > > > >   Thanks for the note. The option that Jonathan mentioned
> > > > is one of a
> > > > > couple
> > > > > > options we define for Jx. We defined other options to
> > > > > > interwork with existing equipment without requiring
> > any changes to
> > > > > > existing encodings (this would support both C1 and T.50
> > > > requirements).
> > > > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > > > Correlation. We welcome additional comments from you
> > and others at
> > > > > > T1X1.5/ITU.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brungard, Deborah A, ALASO
> > > > > > To: [email-masked]; ccamp
> > > > > > Sent: 11/21/2002 5:22 AM
> > > > > > Subject: RE: J0/J1 encoding issues
> > > > > >
> > > > > > As Jonathan says, the current G.707 is using T.50. And
> > > > there's more.
> > > > > > Example, for J0, one currently needs to support:
> > > > > > - previously defined C1 (repeating one-byte)
> > > > > > - T.50 (with format of G.707)
> > > > > > - no J0 (for equipment not supporting).
> > > > > >
> > > > > > So already we have defined multiple applications for this
> > > > byte. Not to
> > > > > > say, there will be not any new ones. Even ITU knows,
> > it never is
> > > > > > final;-)
> > > > > >
> > > > > > For supporting LMP's use, we need to understand the
> > > > scenarios of use
> > > > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > > > inter-operator, applied for equipment installation
> > verification or
> > > > > > service connection verification, etc. And hardware
> > implications.
> > > > > >
> > > > > > Actually, G.831 defines multiple uses depending if inter
> > > > or intra -
> > > > > > including for intra-operator, support of routing/path
> > > > set-up (and G.831
> > > > > > was done years ago).
> > > > > >
> > > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> > > > contribute the
> > > > > > proposal for the meeting and we can start the discussion.
> > > > The next ITU-T
> > > > > > meeting is in January. If the LMP editors need help
> > on our T1X1.5
> > > > > > process, just ask.
> > > > > >
> > > > > > Deborah
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > > To: ccamp
> > > > > > Subject: J0/J1 encoding issues
> > > > > >
> > > > > > All -
> > > > > >
> > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > bytes (J0/J1/J2)
> > > > > > have restrictions not only on the length of a trace
> > message and on
> > > > > > the bits usable in a octet, but also on whether the
> > payload in the
> > > > > > message uses printable ASCII characters.
> > > > > >
> > > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > > message payload must utilize the printable characters
> > defined in
> > > > > > T.50.  Two current LMP drafts
> > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > > consistant with this requirement.
> > > > > >
> > > > > > This message is being sent to document this issue.
> > It is not a
> > > > > > statement that no other issues exist -- I expect that the
> > > > appropriate
> > > > > > experts in the ITU will review the rest of these two
> > drafts and
> > > > > > provide appropriate comment.
> > > > > >
> > > > > > Jonathan Sadler
> > > >
> > > > (I disclaim the disclaimer that follows this message.)
> > > > ============================================================
> > > > The information contained in this message may be privileged
> > > > and confidential and protected from disclosure.  If the
> > > > reader of this message is not the intended recipient, or an
> > > > employee or agent responsible for delivering this message to
> > > > the intended recipient, you are hereby notified that any
> > > > reproduction, dissemination or distribution of this
> > > > communication is strictly prohibited. If you have received
> > > > this communication in error, please notify us immediately by
> > > > replying to the message and deleting it from your computer.
> > > >
> > > > Thank you.
> > > > Tellabs
> > > > ============================================================
> > > >
> >

Delivery-date: Tue, 26 Nov 2002 10:12:00 -0800
From: "Razdan, Rajender" <[email-masked]>
To: "'John Drake'" <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Tue, 26 Nov 2002 12:04:33 -0500

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

Hi all,

   It was brought to my notice that we do, indeed, have a pointer 
to the document through a freely accessable site. I had completely 
forgotten about the following site which does provide a pointer 
to the latest G.7714.1 draft document:
http://www.ietf.org/IESG/LIAISON/ITU-tsg15opt.html 

If you look under OIF, then 11OCT2002:Signaling/Routing/Discovery, 
you'll  find the liason sent to the OIF after the last Q14/15 
rapporteur's meeting.  This liason includes a link to 
g7714.1v0.3_wd29r6_0210.doc. 

Cheers,
Rajender Razdan

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 10:23 AM
To: Razdan, Rajender; [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

Rajender,

Why don't you send a pointer to the draft, so that any interested party can
take a look at it and decide for themselves?

As I understand it, the  version presented at the Experts Meeting in Ottawa
did not comply with T.50 requirements, and it is only the newest draft
version that attempts to address the T.50 requirements.  It does so by
re-defining current Jx processing with a new format that "uses a non-E.164
and non-alphabetic character in the first byte of the message".

Thanks,

John

-----Original Message-----
From: Razdan, Rajender [mailto:[email-masked]]
Sent: Monday, November 25, 2002 8:55 AM
To: John Drake; [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

John,

    I don't subscribe to the ccamp mailing list, and so haven't had a chance
to comment on the LMP drafts till now. The discussion on J0/J1 issues was 
forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I was 
quite distressed to read about your understanding that none of the work
aimed 
at G.7714.1 is compatible with the T.50 requirement. I don't know how you
got
that absolutely wrong impression. In fact, compatibility with the T.50 
requirement, as dictated by ITU Rec. G.707, has been the most important 
consideration for us in our defining J0/J1/J2 discovery mechanisms. The
current
draft of G.7714.1 clearly states this. I FULLY agree with Jonathan Sadler
that 
the LMP work should also be consistent with this requirement.

Regards,
Rajender Razdan

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Monday, November 25, 2002 11:24 AM
To: [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

Jonathan,

The various Test transport mechanisms that are currently defined in
draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
various carriers and organizations such as the OIF.  The fact that the
individual carriers have different requirements for the contents of the
various SDH/SONET overheads is also consistent with my reading of Deborah's
recent e-mail on this topic. 

Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
allows the transport of T.50 characters, I think we're done wrt
draft-ietf-ccamp-lmp-test-sonet-sdh.

Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
work aimed at G.7714.1 is compatible with the T.50 requirement.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 PM
To: John Drake
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: Re: J0/J1 encoding issues

John -

I think you forgot what my original message said.  It stated:

> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.

I fail to see what is incorrect with the above.

While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
J0/J1/J2 that fall within the requirements of G.707, it also includes
methods that don't.  This situation SHOULD be resolved to provide the
greatest amount of interoperability while reducing the number of trace
methods that need to be implemented.

I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
only provides methods that fall outside the requirements of G.707.  This
situation MUST be resolved.

Jonathan Sadler

John Drake wrote:
> 
> Wouldn't it be more precise to say that it is an issue with
> draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> draft-ietf-ccamp-lmp-test-sonet-sdh?
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:49 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> Therefore, it is an issue.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
then
> > Jonathan Sadler's issue is a non-issue?
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Lang
> > Sent: Thursday, November 21, 2002 8:56 AM
> > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > 'ccamp '
> > Subject: FW: J0/J1 encoding issues
> >
> > Deborah,
> >   Thanks for the note. The option that Jonathan mentioned is one of a
> couple
> > options we define for Jx. We defined other options to
> > interwork with existing equipment without requiring any changes to
> > existing encodings (this would support both C1 and T.50 requirements).
> > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > Correlation. We welcome additional comments from you and others at
> > T1X1.5/ITU.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Brungard, Deborah A, ALASO
> > To: [email-masked]; ccamp
> > Sent: 11/21/2002 5:22 AM
> > Subject: RE: J0/J1 encoding issues
> >
> > As Jonathan says, the current G.707 is using T.50. And there's more.
> > Example, for J0, one currently needs to support:
> > - previously defined C1 (repeating one-byte)
> > - T.50 (with format of G.707)
> > - no J0 (for equipment not supporting).
> >
> > So already we have defined multiple applications for this byte. Not to
> > say, there will be not any new ones. Even ITU knows, it never is
> > final;-)
> >
> > For supporting LMP's use, we need to understand the scenarios of use
> > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > inter-operator, applied for equipment installation verification or
> > service connection verification, etc. And hardware implications.
> >
> > Actually, G.831 defines multiple uses depending if inter or intra -
> > including for intra-operator, support of routing/path set-up (and G.831
> > was done years ago).
> >
> > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > proposal for the meeting and we can start the discussion. The next ITU-T
> > meeting is in January. If the LMP editors need help on our T1X1.5
> > process, just ask.
> >
> > Deborah
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 7:59 PM
> > To: ccamp
> > Subject: J0/J1 encoding issues
> >
> > All -
> >
> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.
> >
> > This message is being sent to document this issue.  It is not a
> > statement that no other issues exist -- I expect that the appropriate
> > experts in the ITU will review the rest of these two drafts and
> > provide appropriate comment.
> >
> > Jonathan Sadler

(I disclaim the disclaimer that follows this message.)
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Tue, 26 Nov 2002 09:52:35 -0800
From: Jonathan Lang <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, "Razdan, Rajender" <[email-masked]>
Cc: John Drake <[email-masked]>, [email-masked],  "'Brungard, Deborah A, ALASO '" <[email-masked]>, [email-masked]
Subject: RE: J0/J1 encoding issues
Date: Tue, 26 Nov 2002 09:49:52 -0800

Stephen,
  May I suggest that you add routing & discovery to the
communication/liaison statement to the IETF. Since most of the OIF work is
based on protocols developed in the IETF, it seems odd that IETF
participants need to go through the OIF to see these documents.

Thanks,
Jonathan

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 9:30 AM
> To: Razdan, Rajender
> Cc: Jonathan Lang; John Drake; [email-masked]; 'Brungard,
> Deborah A, ALASO '; [email-masked]
> Subject: Re: J0/J1 encoding issues
> 
> 
> All,
> There are some rules about distributing ITU-T documents 
> outside of ITU-T.
> Generally, the only way to distribute draft text to non-ITU-T 
> members is by
> sending them via communication/liaison statements to 
> organizations outside
> of ITU-T.
> 
> G.7714.1 has not been officially communicated to IETF ccamp, 
> but it has
> been communicated to OIF in which many of you participate. To obtain a
> copy of the document from the communication statement to OIF, start by
> pointing your browser to:
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> /COMMUNICATIONS/index.html
> 
> From there, choose the link for Optical Internetworking Forum (OIF).
> Acknowledge the ITU-T copyright.
> Choose the communication statement dated 11 October 2002 entitled:
> "Signaling, Routing, and Discovery work in Q.14/15".
> 
> There are links in this communication for the download of 
> several documents,
> the last of which is the latest draft of G.7714.1.
> Regards,
> Steve Trowbridge
> Vice-Chairman, ITU-T Study Group 15
> 
> "Razdan, Rajender" wrote:
> > 
> > [ post by non-subscriber.  with the massive amount of spam, 
> it is easy to
> >   miss and therefore delete mis-posts.  so fix subscription 
> addresses! ]
> > 
> > Jonathan,
> > 
> >     I welcome the idea of making the draft of G.7714.1 more freely
> > available. I don't know, however, if there are any ITU rules about
> > distributing draft documents. One possibility, which I have often
> > seen used in the past, is to send the latest version as a 
> contribution
> > to a T1X1.5 meeting. These contributions are freely available to the
> > public. Noting that we do have an upcoming T1X1.5 meeting, I'll go
> > ahead and do that.
> > 
> > Cheers,
> > Rajender Razdan
> > 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 10:28 PM
> > To: Razdan, Rajender; John Drake; [email-masked]
> > Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> > 
> > Rajender,
> >   May I suggest that the authors of the G.7714.1 draft make 
> it available to
> > the wider community. As it is still a draft with most of 
> the discussion
> > amongst authors and not on a public mailing list, most 
> people have not had a
> > chance to look at the latest version which is significantly 
> different from
> > the one discussed at the Experts meeting in Ottawa.
> > 
> > Thanks,
> > Jonathan
> > 
> > > -----Original Message-----
> > > From: Razdan, Rajender [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 8:55 AM
> > > To: John Drake; [email-masked]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > >
> > > John,
> > >
> > >     I don't subscribe to the ccamp mailing list, and so
> > > haven't had a chance
> > > to comment on the LMP drafts till now. The discussion on
> > > J0/J1 issues was
> > > forwarded to me by Jonathan Sadler. As the editor of Draft
> > > G.7714.1, I was
> > > quite distressed to read about your understanding that none
> > > of the work aimed
> > > at G.7714.1 is compatible with the T.50 requirement. I don't
> > > know how you got
> > > that absolutely wrong impression. In fact, compatibility with
> > > the T.50
> > > requirement, as dictated by ITU Rec. G.707, has been the most
> > > important
> > > consideration for us in our defining J0/J1/J2 discovery
> > > mechanisms. The current
> > > draft of G.7714.1 clearly states this. I FULLY agree with
> > > Jonathan Sadler that
> > > the LMP work should also be consistent with this requirement.
> > >
> > > Regards,
> > > Rajender Razdan
> > >
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 11:24 AM
> > > To: [email-masked]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > >
> > > Jonathan,
> > >
> > > The various Test transport mechanisms that are currently 
> defined in
> > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to
> > > input from
> > > various carriers and organizations such as the OIF.  The 
> fact that the
> > > individual carriers have different requirements for the
> > > contents of the
> > > various SDH/SONET overheads is also consistent with my
> > > reading of Deborah's
> > > recent e-mail on this topic.
> > >
> > > Since one of the transport mechanisms, the J0/J1/J2 trace 
> correlation,
> > > allows the transport of T.50 characters, I think we're done wrt
> > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > >
> > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding
> > > that none of the
> > > work aimed at G.7714.1 is compatible with the T.50 requirement.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 8:23 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > >
> > > John -
> > >
> > > I think you forgot what my original message said.  It stated:
> > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts
> > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > >
> > > I fail to see what is incorrect with the above.
> > >
> > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe 
> methods for
> > > J0/J1/J2 that fall within the requirements of G.707, it 
> also includes
> > > methods that don't.  This situation SHOULD be resolved to 
> provide the
> > > greatest amount of interoperability while reducing the 
> number of trace
> > > methods that need to be implemented.
> > >
> > > I'm glad to see we agree on the fact that
> > > draft-lang-ccamp-lmp-bootstrap
> > > only provides methods that fall outside the requirements of
> > > G.707.  This
> > > situation MUST be resolved.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Wouldn't it be more precise to say that it is an issue with
> > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > To: John Drake
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: Re: J0/J1 encoding issues
> > > >
> > > > John -
> > > >
> > > > draft-lang-ccamp-lmp-bootstrap does not support Trace 
> Correlation.
> > > > Therefore, it is an issue.
> > > >
> > > > Jonathan Sadler
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> > > Correlation,
> > > then
> > > > > Jonathan Sadler's issue is a non-issue?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang
> > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > To: 'Brungard, Deborah A, ALASO '; 
> [email-masked] ';
> > > > > 'ccamp '
> > > > > Subject: FW: J0/J1 encoding issues
> > > > >
> > > > > Deborah,
> > > > >   Thanks for the note. The option that Jonathan mentioned
> > > is one of a
> > > > couple
> > > > > options we define for Jx. We defined other options to
> > > > > interwork with existing equipment without requiring 
> any changes to
> > > > > existing encodings (this would support both C1 and T.50
> > > requirements).
> > > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > > Correlation. We welcome additional comments from you 
> and others at
> > > > > T1X1.5/ITU.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brungard, Deborah A, ALASO
> > > > > To: [email-masked]; ccamp
> > > > > Sent: 11/21/2002 5:22 AM
> > > > > Subject: RE: J0/J1 encoding issues
> > > > >
> > > > > As Jonathan says, the current G.707 is using T.50. And
> > > there's more.
> > > > > Example, for J0, one currently needs to support:
> > > > > - previously defined C1 (repeating one-byte)
> > > > > - T.50 (with format of G.707)
> > > > > - no J0 (for equipment not supporting).
> > > > >
> > > > > So already we have defined multiple applications for this
> > > byte. Not to
> > > > > say, there will be not any new ones. Even ITU knows, 
> it never is
> > > > > final;-)
> > > > >
> > > > > For supporting LMP's use, we need to understand the
> > > scenarios of use
> > > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > > inter-operator, applied for equipment installation 
> verification or
> > > > > service connection verification, etc. And hardware 
> implications.
> > > > >
> > > > > Actually, G.831 defines multiple uses depending if inter
> > > or intra -
> > > > > including for intra-operator, support of routing/path
> > > set-up (and G.831
> > > > > was done years ago).
> > > > >
> > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> > > contribute the
> > > > > proposal for the meeting and we can start the discussion.
> > > The next ITU-T
> > > > > meeting is in January. If the LMP editors need help 
> on our T1X1.5
> > > > > process, just ask.
> > > > >
> > > > > Deborah
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > To: ccamp
> > > > > Subject: J0/J1 encoding issues
> > > > >
> > > > > All -
> > > > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts
> > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > > > >
> > > > > This message is being sent to document this issue.  
> It is not a
> > > > > statement that no other issues exist -- I expect that the
> > > appropriate
> > > > > experts in the ITU will review the rest of these two 
> drafts and
> > > > > provide appropriate comment.
> > > > >
> > > > > Jonathan Sadler
> > >
> > > (I disclaim the disclaimer that follows this message.)
> > > ============================================================
> > > The information contained in this message may be privileged
> > > and confidential and protected from disclosure.  If the
> > > reader of this message is not the intended recipient, or an
> > > employee or agent responsible for delivering this message to
> > > the intended recipient, you are hereby notified that any
> > > reproduction, dissemination or distribution of this
> > > communication is strictly prohibited. If you have received
> > > this communication in error, please notify us immediately by
> > > replying to the message and deleting it from your computer.
> > >
> > > Thank you.
> > > Tellabs
> > > ============================================================
> > >
> 

Delivery-date: Tue, 26 Nov 2002 09:31:36 -0800
Date: Tue, 26 Nov 2002 10:29:52 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Razdan, Rajender" <[email-masked]>
CC: "'Jonathan Lang'" <[email-masked]>, John Drake <[email-masked]>, [email-masked], "'Brungard, Deborah A, ALASO '" <[email-masked]>, [email-masked]
Subject: Re: J0/J1 encoding issues

All,
There are some rules about distributing ITU-T documents outside of ITU-T.
Generally, the only way to distribute draft text to non-ITU-T members is by
sending them via communication/liaison statements to organizations outside
of ITU-T.

G.7714.1 has not been officially communicated to IETF ccamp, but it has
been communicated to OIF in which many of you participate. To obtain a
copy of the document from the communication statement to OIF, start by
pointing your browser to:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

>From there, choose the link for Optical Internetworking Forum (OIF).
Acknowledge the ITU-T copyright.
Choose the communication statement dated 11 October 2002 entitled:
"Signaling, Routing, and Discovery work in Q.14/15".

There are links in this communication for the download of several documents,
the last of which is the latest draft of G.7714.1.
Regards,
Steve Trowbridge
Vice-Chairman, ITU-T Study Group 15

"Razdan, Rajender" wrote:
> 
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix subscription addresses! ]
> 
> Jonathan,
> 
>     I welcome the idea of making the draft of G.7714.1 more freely
> available. I don't know, however, if there are any ITU rules about
> distributing draft documents. One possibility, which I have often
> seen used in the past, is to send the latest version as a contribution
> to a T1X1.5 meeting. These contributions are freely available to the
> public. Noting that we do have an upcoming T1X1.5 meeting, I'll go
> ahead and do that.
> 
> Cheers,
> Rajender Razdan
> 
> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 10:28 PM
> To: Razdan, Rajender; John Drake; [email-masked]
> Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Rajender,
>   May I suggest that the authors of the G.7714.1 draft make it available to
> the wider community. As it is still a draft with most of the discussion
> amongst authors and not on a public mailing list, most people have not had a
> chance to look at the latest version which is significantly different from
> the one discussed at the Experts meeting in Ottawa.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Razdan, Rajender [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 8:55 AM
> > To: John Drake; [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> >
> > John,
> >
> >     I don't subscribe to the ccamp mailing list, and so
> > haven't had a chance
> > to comment on the LMP drafts till now. The discussion on
> > J0/J1 issues was
> > forwarded to me by Jonathan Sadler. As the editor of Draft
> > G.7714.1, I was
> > quite distressed to read about your understanding that none
> > of the work aimed
> > at G.7714.1 is compatible with the T.50 requirement. I don't
> > know how you got
> > that absolutely wrong impression. In fact, compatibility with
> > the T.50
> > requirement, as dictated by ITU Rec. G.707, has been the most
> > important
> > consideration for us in our defining J0/J1/J2 discovery
> > mechanisms. The current
> > draft of G.7714.1 clearly states this. I FULLY agree with
> > Jonathan Sadler that
> > the LMP work should also be consistent with this requirement.
> >
> > Regards,
> > Rajender Razdan
> >
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 11:24 AM
> > To: [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> >
> > Jonathan,
> >
> > The various Test transport mechanisms that are currently defined in
> > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to
> > input from
> > various carriers and organizations such as the OIF.  The fact that the
> > individual carriers have different requirements for the
> > contents of the
> > various SDH/SONET overheads is also consistent with my
> > reading of Deborah's
> > recent e-mail on this topic.
> >
> > Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> > allows the transport of T.50 characters, I think we're done wrt
> > draft-ietf-ccamp-lmp-test-sonet-sdh.
> >
> > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding
> > that none of the
> > work aimed at G.7714.1 is compatible with the T.50 requirement.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 8:23 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> >
> > John -
> >
> > I think you forgot what my original message said.  It stated:
> >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts
> > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> >
> > I fail to see what is incorrect with the above.
> >
> > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> > J0/J1/J2 that fall within the requirements of G.707, it also includes
> > methods that don't.  This situation SHOULD be resolved to provide the
> > greatest amount of interoperability while reducing the number of trace
> > methods that need to be implemented.
> >
> > I'm glad to see we agree on the fact that
> > draft-lang-ccamp-lmp-bootstrap
> > only provides methods that fall outside the requirements of
> > G.707.  This
> > situation MUST be resolved.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Wouldn't it be more precise to say that it is an issue with
> > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 12:49 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > > Therefore, it is an issue.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> > Correlation,
> > then
> > > > Jonathan Sadler's issue is a non-issue?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang
> > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > > 'ccamp '
> > > > Subject: FW: J0/J1 encoding issues
> > > >
> > > > Deborah,
> > > >   Thanks for the note. The option that Jonathan mentioned
> > is one of a
> > > couple
> > > > options we define for Jx. We defined other options to
> > > > interwork with existing equipment without requiring any changes to
> > > > existing encodings (this would support both C1 and T.50
> > requirements).
> > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > Correlation. We welcome additional comments from you and others at
> > > > T1X1.5/ITU.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > -----Original Message-----
> > > > From: Brungard, Deborah A, ALASO
> > > > To: [email-masked]; ccamp
> > > > Sent: 11/21/2002 5:22 AM
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > As Jonathan says, the current G.707 is using T.50. And
> > there's more.
> > > > Example, for J0, one currently needs to support:
> > > > - previously defined C1 (repeating one-byte)
> > > > - T.50 (with format of G.707)
> > > > - no J0 (for equipment not supporting).
> > > >
> > > > So already we have defined multiple applications for this
> > byte. Not to
> > > > say, there will be not any new ones. Even ITU knows, it never is
> > > > final;-)
> > > >
> > > > For supporting LMP's use, we need to understand the
> > scenarios of use
> > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > inter-operator, applied for equipment installation verification or
> > > > service connection verification, etc. And hardware implications.
> > > >
> > > > Actually, G.831 defines multiple uses depending if inter
> > or intra -
> > > > including for intra-operator, support of routing/path
> > set-up (and G.831
> > > > was done years ago).
> > > >
> > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> > contribute the
> > > > proposal for the meeting and we can start the discussion.
> > The next ITU-T
> > > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > > process, just ask.
> > > >
> > > > Deborah
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > To: ccamp
> > > > Subject: J0/J1 encoding issues
> > > >
> > > > All -
> > > >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts
> > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> > > >
> > > > This message is being sent to document this issue.  It is not a
> > > > statement that no other issues exist -- I expect that the
> > appropriate
> > > > experts in the ITU will review the rest of these two drafts and
> > > > provide appropriate comment.
> > > >
> > > > Jonathan Sadler
> >
> > (I disclaim the disclaimer that follows this message.)
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > ============================================================
> >

Delivery-date: Tue, 26 Nov 2002 08:50:54 -0800
Date: Tue, 26 Nov 2002 10:48:44 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: John Drake <[email-masked]>
CC: "Razdan, Rajender" <[email-masked]>, Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: Re: J0/J1 encoding issues

John, 

There are a number of T.50 characters that are non-E.164 and
non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
the format defined by draft G.7714.1 is to provide backward
compatability with the country-specific and carrier-specific encodings
described in G.831.

Jonathan Sadler

John Drake wrote:
> 
> Rajender,
> 
> Why don't you send a pointer to the draft, so that any interested party can
> take a look at it and decide for themselves?
> 
> As I understand it, the  version presented at the Experts Meeting in Ottawa
> did not comply with T.50 requirements, and it is only the newest draft
> version that attempts to address the T.50 requirements.  It does so by
> re-defining current Jx processing with a new format that "uses a non-E.164
> and non-alphabetic character in the first byte of the message".
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Razdan, Rajender [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 8:55 AM
> To: John Drake; [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> John,
> 
>     I don't subscribe to the ccamp mailing list, and so haven't had a chance
> to comment on the LMP drafts till now. The discussion on J0/J1 issues was
> forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I was
> quite distressed to read about your understanding that none of the work
> aimed
> at G.7714.1 is compatible with the T.50 requirement. I don't know how you
> got
> that absolutely wrong impression. In fact, compatibility with the T.50
> requirement, as dictated by ITU Rec. G.707, has been the most important
> consideration for us in our defining J0/J1/J2 discovery mechanisms. The
> current
> draft of G.7714.1 clearly states this. I FULLY agree with Jonathan Sadler
> that
> the LMP work should also be consistent with this requirement.
> 
> Regards,
> Rajender Razdan
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 11:24 AM
> To: [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Jonathan,
> 
> The various Test transport mechanisms that are currently defined in
> draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
> various carriers and organizations such as the OIF.  The fact that the
> individual carriers have different requirements for the contents of the
> various SDH/SONET overheads is also consistent with my reading of Deborah's
> recent e-mail on this topic.
> 
> Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> allows the transport of T.50 characters, I think we're done wrt
> draft-ietf-ccamp-lmp-test-sonet-sdh.
> 
> Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
> work aimed at G.7714.1 is compatible with the T.50 requirement.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 8:23 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> I think you forgot what my original message said.  It stated:
> 
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> 
> I fail to see what is incorrect with the above.
> 
> While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> J0/J1/J2 that fall within the requirements of G.707, it also includes
> methods that don't.  This situation SHOULD be resolved to provide the
> greatest amount of interoperability while reducing the number of trace
> methods that need to be implemented.
> 
> I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
> only provides methods that fall outside the requirements of G.707.  This
> situation MUST be resolved.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Wouldn't it be more precise to say that it is an issue with
> > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > draft-ietf-ccamp-lmp-test-sonet-sdh?
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 12:49 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > Therefore, it is an issue.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
> then
> > > Jonathan Sadler's issue is a non-issue?
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang
> > > Sent: Thursday, November 21, 2002 8:56 AM
> > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > 'ccamp '
> > > Subject: FW: J0/J1 encoding issues
> > >
> > > Deborah,
> > >   Thanks for the note. The option that Jonathan mentioned is one of a
> > couple
> > > options we define for Jx. We defined other options to
> > > interwork with existing equipment without requiring any changes to
> > > existing encodings (this would support both C1 and T.50 requirements).
> > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > Correlation. We welcome additional comments from you and others at
> > > T1X1.5/ITU.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > -----Original Message-----
> > > From: Brungard, Deborah A, ALASO
> > > To: [email-masked]; ccamp
> > > Sent: 11/21/2002 5:22 AM
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > As Jonathan says, the current G.707 is using T.50. And there's more.
> > > Example, for J0, one currently needs to support:
> > > - previously defined C1 (repeating one-byte)
> > > - T.50 (with format of G.707)
> > > - no J0 (for equipment not supporting).
> > >
> > > So already we have defined multiple applications for this byte. Not to
> > > say, there will be not any new ones. Even ITU knows, it never is
> > > final;-)
> > >
> > > For supporting LMP's use, we need to understand the scenarios of use
> > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > inter-operator, applied for equipment installation verification or
> > > service connection verification, etc. And hardware implications.
> > >
> > > Actually, G.831 defines multiple uses depending if inter or intra -
> > > including for intra-operator, support of routing/path set-up (and G.831
> > > was done years ago).
> > >
> > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > > proposal for the meeting and we can start the discussion. The next ITU-T
> > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > process, just ask.
> > >
> > > Deborah
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Monday, November 18, 2002 7:59 PM
> > > To: ccamp
> > > Subject: J0/J1 encoding issues
> > >
> > > All -
> > >
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> > >
> > > This message is being sent to document this issue.  It is not a
> > > statement that no other issues exist -- I expect that the appropriate
> > > experts in the ITU will review the rest of these two drafts and
> > > provide appropriate comment.
> > >
> > > Jonathan Sadler
> 
> (I disclaim the disclaimer that follows this message.)
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Tue, 26 Nov 2002 07:41:56 -0800
From: "Razdan, Rajender" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, John Drake <[email-masked]>, [email-masked]
Cc: "'Brungard, Deborah A, ALASO '" <[email-masked]>, <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Tue, 26 Nov 2002 10:07:45 -0500

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

Jonathan,

    I welcome the idea of making the draft of G.7714.1 more freely
available. I don't know, however, if there are any ITU rules about
distributing draft documents. One possibility, which I have often
seen used in the past, is to send the latest version as a contribution 
to a T1X1.5 meeting. These contributions are freely available to the 
public. Noting that we do have an upcoming T1X1.5 meeting, I'll go 
ahead and do that.

Cheers,
Rajender Razdan

-----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Monday, November 25, 2002 10:28 PM
To: Razdan, Rajender; John Drake; [email-masked]
Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

Rajender,
  May I suggest that the authors of the G.7714.1 draft make it available to
the wider community. As it is still a draft with most of the discussion
amongst authors and not on a public mailing list, most people have not had a
chance to look at the latest version which is significantly different from
the one discussed at the Experts meeting in Ottawa.

Thanks,
Jonathan

> -----Original Message-----
> From: Razdan, Rajender [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 8:55 AM
> To: John Drake; [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> 
> John,
> 
>     I don't subscribe to the ccamp mailing list, and so 
> haven't had a chance
> to comment on the LMP drafts till now. The discussion on 
> J0/J1 issues was 
> forwarded to me by Jonathan Sadler. As the editor of Draft 
> G.7714.1, I was 
> quite distressed to read about your understanding that none 
> of the work aimed 
> at G.7714.1 is compatible with the T.50 requirement. I don't 
> know how you got
> that absolutely wrong impression. In fact, compatibility with 
> the T.50 
> requirement, as dictated by ITU Rec. G.707, has been the most 
> important 
> consideration for us in our defining J0/J1/J2 discovery 
> mechanisms. The current
> draft of G.7714.1 clearly states this. I FULLY agree with 
> Jonathan Sadler that 
> the LMP work should also be consistent with this requirement.
> 
> Regards,
> Rajender Razdan
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 11:24 AM
> To: [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> 
> Jonathan,
> 
> The various Test transport mechanisms that are currently defined in
> draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to 
> input from
> various carriers and organizations such as the OIF.  The fact that the
> individual carriers have different requirements for the 
> contents of the
> various SDH/SONET overheads is also consistent with my 
> reading of Deborah's
> recent e-mail on this topic. 
> 
> Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> allows the transport of T.50 characters, I think we're done wrt
> draft-ietf-ccamp-lmp-test-sonet-sdh.
> 
> Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding 
> that none of the
> work aimed at G.7714.1 is compatible with the T.50 requirement.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 8:23 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> 
> John -
> 
> I think you forgot what my original message said.  It stated:
> 
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> 
> I fail to see what is incorrect with the above.
> 
> While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> J0/J1/J2 that fall within the requirements of G.707, it also includes
> methods that don't.  This situation SHOULD be resolved to provide the
> greatest amount of interoperability while reducing the number of trace
> methods that need to be implemented.
> 
> I'm glad to see we agree on the fact that 
> draft-lang-ccamp-lmp-bootstrap
> only provides methods that fall outside the requirements of 
> G.707.  This
> situation MUST be resolved.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> > 
> > Wouldn't it be more precise to say that it is an issue with
> > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > 
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 12:49 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> > 
> > John -
> > 
> > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > Therefore, it is an issue.
> > 
> > Jonathan Sadler
> > 
> > John Drake wrote:
> > >
> > > Is it the case that if one chooses to use J0/J1/J2 Trace 
> Correlation,
> then
> > > Jonathan Sadler's issue is a non-issue?
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang
> > > Sent: Thursday, November 21, 2002 8:56 AM
> > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > 'ccamp '
> > > Subject: FW: J0/J1 encoding issues
> > >
> > > Deborah,
> > >   Thanks for the note. The option that Jonathan mentioned 
> is one of a
> > couple
> > > options we define for Jx. We defined other options to
> > > interwork with existing equipment without requiring any changes to
> > > existing encodings (this would support both C1 and T.50 
> requirements).
> > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > Correlation. We welcome additional comments from you and others at
> > > T1X1.5/ITU.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > -----Original Message-----
> > > From: Brungard, Deborah A, ALASO
> > > To: [email-masked]; ccamp
> > > Sent: 11/21/2002 5:22 AM
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > As Jonathan says, the current G.707 is using T.50. And 
> there's more.
> > > Example, for J0, one currently needs to support:
> > > - previously defined C1 (repeating one-byte)
> > > - T.50 (with format of G.707)
> > > - no J0 (for equipment not supporting).
> > >
> > > So already we have defined multiple applications for this 
> byte. Not to
> > > say, there will be not any new ones. Even ITU knows, it never is
> > > final;-)
> > >
> > > For supporting LMP's use, we need to understand the 
> scenarios of use
> > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > inter-operator, applied for equipment installation verification or
> > > service connection verification, etc. And hardware implications.
> > >
> > > Actually, G.831 defines multiple uses depending if inter 
> or intra -
> > > including for intra-operator, support of routing/path 
> set-up (and G.831
> > > was done years ago).
> > >
> > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, 
> contribute the
> > > proposal for the meeting and we can start the discussion. 
> The next ITU-T
> > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > process, just ask.
> > >
> > > Deborah
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Monday, November 18, 2002 7:59 PM
> > > To: ccamp
> > > Subject: J0/J1 encoding issues
> > >
> > > All -
> > >
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> > >
> > > This message is being sent to document this issue.  It is not a
> > > statement that no other issues exist -- I expect that the 
> appropriate
> > > experts in the ITU will review the rest of these two drafts and
> > > provide appropriate comment.
> > >
> > > Jonathan Sadler
> 
> (I disclaim the disclaimer that follows this message.)
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 

Delivery-date: Tue, 26 Nov 2002 07:25:07 -0800
From: John Drake <[email-masked]>
To: "Razdan, Rajender" <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Tue, 26 Nov 2002 07:22:55 -0800

Rajender,

Why don't you send a pointer to the draft, so that any interested party can
take a look at it and decide for themselves?

As I understand it, the  version presented at the Experts Meeting in Ottawa
did not comply with T.50 requirements, and it is only the newest draft
version that attempts to address the T.50 requirements.  It does so by
re-defining current Jx processing with a new format that "uses a non-E.164
and non-alphabetic character in the first byte of the message".

Thanks,

John

-----Original Message-----
From: Razdan, Rajender [mailto:[email-masked]]
Sent: Monday, November 25, 2002 8:55 AM
To: John Drake; [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

John,

    I don't subscribe to the ccamp mailing list, and so haven't had a chance
to comment on the LMP drafts till now. The discussion on J0/J1 issues was 
forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I was 
quite distressed to read about your understanding that none of the work
aimed 
at G.7714.1 is compatible with the T.50 requirement. I don't know how you
got
that absolutely wrong impression. In fact, compatibility with the T.50 
requirement, as dictated by ITU Rec. G.707, has been the most important 
consideration for us in our defining J0/J1/J2 discovery mechanisms. The
current
draft of G.7714.1 clearly states this. I FULLY agree with Jonathan Sadler
that 
the LMP work should also be consistent with this requirement.

Regards,
Rajender Razdan

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Monday, November 25, 2002 11:24 AM
To: [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

Jonathan,

The various Test transport mechanisms that are currently defined in
draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
various carriers and organizations such as the OIF.  The fact that the
individual carriers have different requirements for the contents of the
various SDH/SONET overheads is also consistent with my reading of Deborah's
recent e-mail on this topic. 

Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
allows the transport of T.50 characters, I think we're done wrt
draft-ietf-ccamp-lmp-test-sonet-sdh.

Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
work aimed at G.7714.1 is compatible with the T.50 requirement.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 PM
To: John Drake
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: Re: J0/J1 encoding issues

John -

I think you forgot what my original message said.  It stated:

> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.

I fail to see what is incorrect with the above.

While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
J0/J1/J2 that fall within the requirements of G.707, it also includes
methods that don't.  This situation SHOULD be resolved to provide the
greatest amount of interoperability while reducing the number of trace
methods that need to be implemented.

I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
only provides methods that fall outside the requirements of G.707.  This
situation MUST be resolved.

Jonathan Sadler

John Drake wrote:
> 
> Wouldn't it be more precise to say that it is an issue with
> draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> draft-ietf-ccamp-lmp-test-sonet-sdh?
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:49 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> Therefore, it is an issue.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
then
> > Jonathan Sadler's issue is a non-issue?
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Lang
> > Sent: Thursday, November 21, 2002 8:56 AM
> > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > 'ccamp '
> > Subject: FW: J0/J1 encoding issues
> >
> > Deborah,
> >   Thanks for the note. The option that Jonathan mentioned is one of a
> couple
> > options we define for Jx. We defined other options to
> > interwork with existing equipment without requiring any changes to
> > existing encodings (this would support both C1 and T.50 requirements).
> > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > Correlation. We welcome additional comments from you and others at
> > T1X1.5/ITU.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Brungard, Deborah A, ALASO
> > To: [email-masked]; ccamp
> > Sent: 11/21/2002 5:22 AM
> > Subject: RE: J0/J1 encoding issues
> >
> > As Jonathan says, the current G.707 is using T.50. And there's more.
> > Example, for J0, one currently needs to support:
> > - previously defined C1 (repeating one-byte)
> > - T.50 (with format of G.707)
> > - no J0 (for equipment not supporting).
> >
> > So already we have defined multiple applications for this byte. Not to
> > say, there will be not any new ones. Even ITU knows, it never is
> > final;-)
> >
> > For supporting LMP's use, we need to understand the scenarios of use
> > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > inter-operator, applied for equipment installation verification or
> > service connection verification, etc. And hardware implications.
> >
> > Actually, G.831 defines multiple uses depending if inter or intra -
> > including for intra-operator, support of routing/path set-up (and G.831
> > was done years ago).
> >
> > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > proposal for the meeting and we can start the discussion. The next ITU-T
> > meeting is in January. If the LMP editors need help on our T1X1.5
> > process, just ask.
> >
> > Deborah
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 7:59 PM
> > To: ccamp
> > Subject: J0/J1 encoding issues
> >
> > All -
> >
> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.
> >
> > This message is being sent to document this issue.  It is not a
> > statement that no other issues exist -- I expect that the appropriate
> > experts in the ITU will review the rest of these two drafts and
> > provide appropriate comment.
> >
> > Jonathan Sadler

(I disclaim the disclaimer that follows this message.)
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Tue, 26 Nov 2002 06:36:38 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: Draft SUBIP Area Meeting minutes
Date: Tue, 26 Nov 2002 13:36:07 +0100

These minutes (Draft for now, mainly based on Dmitri's notes)
have been posted to [email-masked]

Mailing list info:

   General Discussion: [email-masked]
   To subscribe:       [email-masked]
        in body:       subscribe subip-area

        Archive:       ftp://subip.ietf.org/pub/lists/

Thanks,
Bert 

Delivery-date: Mon, 25 Nov 2002 19:29:40 -0800
From: Jonathan Lang <[email-masked]>
To: "'Razdan, Rajender'" <[email-masked]>, John Drake <[email-masked]>, [email-masked]
Cc: "'Brungard, Deborah A, ALASO '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Mon, 25 Nov 2002 19:27:47 -0800

Rajender,
  May I suggest that the authors of the G.7714.1 draft make it available to
the wider community. As it is still a draft with most of the discussion
amongst authors and not on a public mailing list, most people have not had a
chance to look at the latest version which is significantly different from
the one discussed at the Experts meeting in Ottawa.

Thanks,
Jonathan

> -----Original Message-----
> From: Razdan, Rajender [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 8:55 AM
> To: John Drake; [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> 
> John,
> 
>     I don't subscribe to the ccamp mailing list, and so 
> haven't had a chance
> to comment on the LMP drafts till now. The discussion on 
> J0/J1 issues was 
> forwarded to me by Jonathan Sadler. As the editor of Draft 
> G.7714.1, I was 
> quite distressed to read about your understanding that none 
> of the work aimed 
> at G.7714.1 is compatible with the T.50 requirement. I don't 
> know how you got
> that absolutely wrong impression. In fact, compatibility with 
> the T.50 
> requirement, as dictated by ITU Rec. G.707, has been the most 
> important 
> consideration for us in our defining J0/J1/J2 discovery 
> mechanisms. The current
> draft of G.7714.1 clearly states this. I FULLY agree with 
> Jonathan Sadler that 
> the LMP work should also be consistent with this requirement.
> 
> Regards,
> Rajender Razdan
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 11:24 AM
> To: [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> 
> Jonathan,
> 
> The various Test transport mechanisms that are currently defined in
> draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to 
> input from
> various carriers and organizations such as the OIF.  The fact that the
> individual carriers have different requirements for the 
> contents of the
> various SDH/SONET overheads is also consistent with my 
> reading of Deborah's
> recent e-mail on this topic. 
> 
> Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> allows the transport of T.50 characters, I think we're done wrt
> draft-ietf-ccamp-lmp-test-sonet-sdh.
> 
> Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding 
> that none of the
> work aimed at G.7714.1 is compatible with the T.50 requirement.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 8:23 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> 
> John -
> 
> I think you forgot what my original message said.  It stated:
> 
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> 
> I fail to see what is incorrect with the above.
> 
> While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> J0/J1/J2 that fall within the requirements of G.707, it also includes
> methods that don't.  This situation SHOULD be resolved to provide the
> greatest amount of interoperability while reducing the number of trace
> methods that need to be implemented.
> 
> I'm glad to see we agree on the fact that 
> draft-lang-ccamp-lmp-bootstrap
> only provides methods that fall outside the requirements of 
> G.707.  This
> situation MUST be resolved.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> > 
> > Wouldn't it be more precise to say that it is an issue with
> > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > 
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 12:49 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> > 
> > John -
> > 
> > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > Therefore, it is an issue.
> > 
> > Jonathan Sadler
> > 
> > John Drake wrote:
> > >
> > > Is it the case that if one chooses to use J0/J1/J2 Trace 
> Correlation,
> then
> > > Jonathan Sadler's issue is a non-issue?
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang
> > > Sent: Thursday, November 21, 2002 8:56 AM
> > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > 'ccamp '
> > > Subject: FW: J0/J1 encoding issues
> > >
> > > Deborah,
> > >   Thanks for the note. The option that Jonathan mentioned 
> is one of a
> > couple
> > > options we define for Jx. We defined other options to
> > > interwork with existing equipment without requiring any changes to
> > > existing encodings (this would support both C1 and T.50 
> requirements).
> > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > Correlation. We welcome additional comments from you and others at
> > > T1X1.5/ITU.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > -----Original Message-----
> > > From: Brungard, Deborah A, ALASO
> > > To: [email-masked]; ccamp
> > > Sent: 11/21/2002 5:22 AM
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > As Jonathan says, the current G.707 is using T.50. And 
> there's more.
> > > Example, for J0, one currently needs to support:
> > > - previously defined C1 (repeating one-byte)
> > > - T.50 (with format of G.707)
> > > - no J0 (for equipment not supporting).
> > >
> > > So already we have defined multiple applications for this 
> byte. Not to
> > > say, there will be not any new ones. Even ITU knows, it never is
> > > final;-)
> > >
> > > For supporting LMP's use, we need to understand the 
> scenarios of use
> > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > inter-operator, applied for equipment installation verification or
> > > service connection verification, etc. And hardware implications.
> > >
> > > Actually, G.831 defines multiple uses depending if inter 
> or intra -
> > > including for intra-operator, support of routing/path 
> set-up (and G.831
> > > was done years ago).
> > >
> > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, 
> contribute the
> > > proposal for the meeting and we can start the discussion. 
> The next ITU-T
> > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > process, just ask.
> > >
> > > Deborah
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Monday, November 18, 2002 7:59 PM
> > > To: ccamp
> > > Subject: J0/J1 encoding issues
> > >
> > > All -
> > >
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> > >
> > > This message is being sent to document this issue.  It is not a
> > > statement that no other issues exist -- I expect that the 
> appropriate
> > > experts in the ITU will review the rest of these two drafts and
> > > provide appropriate comment.
> > >
> > > Jonathan Sadler
> 
> (I disclaim the disclaimer that follows this message.)
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 

Delivery-date: Mon, 25 Nov 2002 18:44:36 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'John Drake'" <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Mon, 25 Nov 2002 18:42:36 -0800

John, as far as how IETF wants to define the contents of J0/J1/J2 strings
for use in a test message is, of course, up to us at the IETF.  I'd
recommend, for broad support and widest implementation compatibility, that
we align with the ITU-T's G.7714.1 work.

You are incorrect concerning the work on G.7714.1 which is completely
compatible with both G.707's T.50 requirement and in the case of DCC channel
usage will be compatible with G.7712. G.7712 defines (among other things)
the protocols stacks (LAPD or PPP) for use on DCC and GCC channels.

Greg B.

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Monday, November 25, 2002 8:24 AM
To: [email-masked]
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: RE: J0/J1 encoding issues

Jonathan,

The various Test transport mechanisms that are currently defined in
draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
various carriers and organizations such as the OIF.  The fact that the
individual carriers have different requirements for the contents of the
various SDH/SONET overheads is also consistent with my reading of Deborah's
recent e-mail on this topic. 

Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
allows the transport of T.50 characters, I think we're done wrt
draft-ietf-ccamp-lmp-test-sonet-sdh.

Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
work aimed at G.7714.1 is compatible with the T.50 requirement.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 PM
To: John Drake
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: Re: J0/J1 encoding issues

John -

I think you forgot what my original message said.  It stated:

> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.

I fail to see what is incorrect with the above.

While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
J0/J1/J2 that fall within the requirements of G.707, it also includes
methods that don't.  This situation SHOULD be resolved to provide the
greatest amount of interoperability while reducing the number of trace
methods that need to be implemented.

I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
only provides methods that fall outside the requirements of G.707.  This
situation MUST be resolved.

Jonathan Sadler

John Drake wrote:
> 
> Wouldn't it be more precise to say that it is an issue with
> draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> draft-ietf-ccamp-lmp-test-sonet-sdh?
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:49 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> Therefore, it is an issue.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
then
> > Jonathan Sadler's issue is a non-issue?
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Lang
> > Sent: Thursday, November 21, 2002 8:56 AM
> > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > 'ccamp '
> > Subject: FW: J0/J1 encoding issues
> >
> > Deborah,
> >   Thanks for the note. The option that Jonathan mentioned is one of a
> couple
> > options we define for Jx. We defined other options to
> > interwork with existing equipment without requiring any changes to
> > existing encodings (this would support both C1 and T.50 requirements).
> > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > Correlation. We welcome additional comments from you and others at
> > T1X1.5/ITU.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Brungard, Deborah A, ALASO
> > To: [email-masked]; ccamp
> > Sent: 11/21/2002 5:22 AM
> > Subject: RE: J0/J1 encoding issues
> >
> > As Jonathan says, the current G.707 is using T.50. And there's more.
> > Example, for J0, one currently needs to support:
> > - previously defined C1 (repeating one-byte)
> > - T.50 (with format of G.707)
> > - no J0 (for equipment not supporting).
> >
> > So already we have defined multiple applications for this byte. Not to
> > say, there will be not any new ones. Even ITU knows, it never is
> > final;-)
> >
> > For supporting LMP's use, we need to understand the scenarios of use
> > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > inter-operator, applied for equipment installation verification or
> > service connection verification, etc. And hardware implications.
> >
> > Actually, G.831 defines multiple uses depending if inter or intra -
> > including for intra-operator, support of routing/path set-up (and G.831
> > was done years ago).
> >
> > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > proposal for the meeting and we can start the discussion. The next ITU-T
> > meeting is in January. If the LMP editors need help on our T1X1.5
> > process, just ask.
> >
> > Deborah
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 7:59 PM
> > To: ccamp
> > Subject: J0/J1 encoding issues
> >
> > All -
> >
> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.
> >
> > This message is being sent to document this issue.  It is not a
> > statement that no other issues exist -- I expect that the appropriate
> > experts in the ITU will review the rest of these two drafts and
> > provide appropriate comment.
> >
> > Jonathan Sadler

(I disclaim the disclaimer that follows this message.)
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Envelope-to: [email-masked]
Delivery-date: Mon, 25 Nov 2002 18:10:00 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Signaling route exclusions 
Date: Mon, 25 Nov 2002 21:07:23 -0500

All,

Below I have included a text version of the material that Cheng-Yin and I would
have used with the WG to lead a discussion on
draft-lee-ccamp-rsvp-te-exclude-route-01.txt if there had been time to slip it
in to the agenda.

Route exclusions are applicable to any MPLS (and therefore GMPLS ;-) network
where full computation of the ERO is not performed before the LSP is signaled.
This might be because loose or non-explicit routes are used, or because there
are "domains of computation" within the network. Such domains of computation
include (but are not limited to) multiple areas.

Note that multi-area signaling is now (or about to be, or might be soon, or will
be discussed soon) in the ccamp charter.

We would very much appreciate the opinions of everyone on the list both on the
usefulness and the practicality of this draft.

Thanks,
Adrian

==========

Why in the CCAMP WG?
- Charter item "Define signaling mechanisms for protection, diverse routing."
- This is an extension to MPLS but is generalized and should form part of GMPLS

Why do we need route exclusion?
- Not all signaled EROs are built entirely from strict explicit hops
   - Loose hops
   - Abstract nodes such as prefixes and AS numbers
- Not all path computation is performed offline or at the ingress
   - Protection domains
   - Limited visibility of routing information
   - George's overlay draft
   - Multiple areas (NOT a prerequisite for this draft)
- Helps address new charter item for multi-area

Changes in this version of the draft
- Updates after comments in Yokohama
   - Address chair's concerns
   - Clarify questions from the floor
   - Further refinements by authors
- New section on scope of route exclusion
- Description of relationship to (G)MPLS TE-MIB
   - Desired routes may be configured with exclusions
- Distinguish between node and interface exclusions
- Allow distinction between desired and required exclusion
- Clarify procedures for conflict between ERO and route exclusion
- Add new co-author (Stefaan De Cnodder)

Actions
- Thanks for feedback on and off the list
- We would welcome more input and contributions especially from providers
- Request to be adopted as WG document

Delivery-date: Mon, 25 Nov 2002 16:31:28 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes
Date: Mon, 25 Nov 2002 16:25:08 -0800

Hi Ron,

Just adding some more notes on George's overlay presentation -

The question was raised on the difference between this
and the OIF UNI work, George responded that the OIF UNI
is aimed at public service providers with a separate
address space, while this is not.  George also noted 
that the current addressing in Session and Sender_Template
objects may be overly constrained for overlay.

IMHO, I'm not sure I would say a vast majority supported
it, the vast majority was generally pretty quiet at the meeting.

Cheers,

Lyndon Ong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: Sunday, November 24, 2002 7:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes

Thanks!

I will add this to the minutes.

                  Ron

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 10:12 PM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: IETF 55 - CCAMP Minutes
>
>
> hi ron, all
>
> i do not see the report on the gmpls for overlay networks
> what i have is as follows (may be others can correct me
> or complete this):
>
> G.Swallow: discussed the application of gmpls for overlay
> networks, ending with a proposal for making this a
> wg i-d (proposed standard) see for more details:
> http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
>
> K.Kompella: asked for people in favor/opposed: the result
> was that only a few people (2 or 3) were opposed whilst
> the vast majority were in favor
>
> S.Throwbridge: asked whether the proposal was aligned with
> the carrier requirements (without more details)
>
> K.Kompella: let's bring it to the mailing list.
>
> also some comments:
>
> "> Dmitri: Could you comment on applicability of incompatibility with
> other
> > documents."
>
> "Can you comment on backward compatibility with the other lmp
> documents ?"
>
> thanks,
> - dimitri.
>
> Ron Bonica wrote:
> >
> > Folks,
> >
> > CCAMP WG minutes follow. Slides are attached. Please comment on
> the minutes
> > within two weeks so that we can make any required corrections
> and enter them
> > into the record.
> >
> >                                            Ron
> >
> > P.S. Kireeti's presentation provides a snapshot of WG status. I
> will make
> > sure that the ID tracker stays up to date so we will always
> have a current
> > picture of WG status.
> >
> > ===============================
> >
> > IETF 54 CCAMP Meeting Minutes
> > ==============================
> >
> > Schedule rearranged due to technical difficulties.....
> >
> > Kireeti:  Can someone come up here and sing during the break? *)
> >
> > 0935 - 0950
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
> >                 Lang
> >
> > Provided summary of updates to LMP draft.  See his slides for details.
> > Thinks we are ready for IESG last call. Summary of updates to
> LMP WDM draft.
> > See slides for details. Ready for WG last call.
> >
> > Bonica: initiate last call on list after meeting.
> >
> > LMP Test Sonet SDH draft. See slides for details. After
> changes, we should
> > solicit
> > comments from list. We would like a WG last call thereafter.
> Get a feel from
> > the room?
> >
> > Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> >
> > Bert: The base LMP document was intended for proposed standard. We got
> > pushback
> > from ITU people stating that we should not be working on some
> of this stuff,
> > so we
> > split it out to a separate document. Are we intending on prop
> standard for
> > this stuff?
> >
> > Kireeti: Yes, prop. Standards stuff.
> >
> > Bert: Are we on our proper turf? I would like ITU people to
> speak up on this
> > as well
> > as review it. I don't want discussion during last call, want
> resolution now.
> >
> > Speaker 1: Question RE: LMP. After this meeting I intend to
> start a draft.
> > After reading LMP specification, I believe it has mandatory
> configuration.
> > Are there security considerations.
> >
> > Lang: Yes, security considerations are mandatory.
> >
> > Speaker 1: I would like security to be optional.
> >
> > Bert: Security considerations may not be optional.  We can have some as
> > optional,
> > but some mandatory security options are required.
> >
> > Kireeti: It is mandatory to define security - how to run LMP in a secure
> > mode.
> > It is not mandatory to run LMP in a secure mode. Can you?
> >
> > Lang: That is correct, it can be run un-secure.  Ipsec is
> defined for LMP.
> > If you do not want to run IPSec, you can run it without.
> >
> > Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> > consistent with ITU
> > T.50 requirement. Printable ASCII characters in particular might be an
> > issue.
> >
> > Bert: Please pose question to mailing list.
> >
> > Ron: That way we will have record of conversation.
> >
> > Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
> Will there
> > be any
> > additional alignment with this?
> >
> > Lang: I think the 7714.1 document is more closely related to bootstrap
> > document, and
> > I would lke to discuss this in next part of presentation.
> >
> > Lyndon: This is now taking LMP and LMP-WDM that are tech
> specific. Are there
> > any non-tech
> > specific things that cannot be applied to both.
> >
> > Lang: The whole document can be applied to both.
> >
> > Kireeti: Is there any objection in ITU from letting IETF have
> this document
> > or will
> > we dribble out requirements one by one?
> >
> > ITU leason: I cannot speak for all ITUT, but we need to socialize this
> > within the ITU.
> > There is work going on with regard to discovery in ITU 7714
> that might need
> > to be aligned.
> > However, I will try to get discussion going on rapidly.
> >
> > Dmitry P:  There may be issues with the way the messages are encoded.
> >
> > Kireeti:  We are not talking about discovery; test messages.
> Documents were
> > separated
> > so that we can work issues doc-by-doc.  Good to get ruling for each
> > document. The
> > typical issues with using J0 etc... has rules for how to use this.  Make
> > clear that
> > that some issues are about before service starts.
> >
> > Speaker 5: 7714 issue: if they do the same thing, then why define two
> > documents for this?
> >
> > Lang: There may be overlap between next document, but not here.
> >
> > Speaker 5: Need to be clear about what the overlaps are.
> >
> > Lang: Bootstrap document (next doc), the intro describes why
> the doc exists.
> > Prev. document is defined in LMP base document. If you disagree, let me
> > know.
> >
> > LMP Bootstrap document. See slides for details. This is not WG document.
> > Would like
> > technical comments on list.
> >
> > Dmitri: Could you comment on applicability of incompatibility with other
> > documents.
> >
> > Lang: The point to make is the information exchanged is the
> same as that for
> > the LMP
> > protocol. There is no new information exchanged.
> >
> > Kireeti: We need to continue this on the list (ITU input) on how we move
> > these documents
> > forward.
> >
> > Kireeti - CCAMP 55 WG status.
> >
> > Kireeti: Is there any problem with sending GMPLS framework to IESG as
> > informational.
> >
> > Bert: I reviewed this doc a while back, and question is that
> non-standard
> > extensions are
> > detailed here. This seems strange to publish a document that
> suggests a way
> > of signaling
> > things without a document being somewhere that details the specifics
> > somewhere.
> >
> > Dmitri: We have been looking for comments RE: pointers/document
> to fulfill
> > your query. I
> > think it is unfair to continue without filling these
> requirements. When I
> > sent comments
> > on the list, I asked people to provide pointers. If people would like to
> > continue, please
> > send pointers ASAP.
> >
> > Kireeti: As a fallback, what are we going to do if no docs are received.
> >
> > Bert: Throw it into the garbage.
> >
> > Kireeti: Unless we get pointers, this goes in the can.
> >
> > Kireeti: One thing has been asked about is changes to the
> charter. We want
> > to make
> > changes to the charter. Please send us suggestions. Few additions:
> > inter-area (within AS
> > domain),  Protection/restoration, optical VPN.  This will be discussed
> > partially during
> > SUB-IP meeting, but approval of charter changes come from IESG.
> >
> > JPV: Question about the charter. Will signaling between
> computation server
> > and client are
> > part of the charter, or do we need to add?
> >
> > Kireeti: The current charter does not explicitly have this.
> This is part of
> > the charter
> > extensions we are asking for.
> >
> > JPV: This can be used in other areas.
> >
> > Kireeti: Don't go there. If it is in the charter it is, if not
> then no. Need
> > to make sure
> > this is in the charter.
> >
> > Ron: I will send out an update on the charter additions
> (proposed) to the
> > mailing list.
> >
> > Ashok - Interoperability draft.
> >
> > Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> > issues for RSVP.
> >
> > Bert: These are separate documents. Do this in RSVP.
> >
> > Lou:  Spec. requires TSPEC. Lets talk about this offline.
> >
> > Kireeti: Okay. I want to talk about some implementation
> recommendations. How
> > are these
> > published?
> >
> > Bert: Implementation recommendations are fine to either publish
> as BCP or
> > Informational.
> > I am worried about the limited set of specifications/issues and
> that they
> > are captured.
> >
> > Kireeti: Generic RSVP things are already specified (according
> to Lou). Lets
> > talk about
> > this offline to see where changes are required. Define what
> issues are, how
> > are they
> > specified. Do this offline.  Should we add recommendations to
> implementation
> > survey as an
> > appendix?
> >
> > Bert: Whichever.
> >
> > Lou: These look like guidelines to implementations. This is usually done
> > outside of spec.
> > done as BCP/Info.
> >
> > Kireeti: Question is where to put it.
> >
> > Lou: Seems like this is not a BCP.
> >
> > Kireeti: Too early to say that these include "best" practices. Looks
> > informational.
> > Need to talk with Lou about remaining issues.
> >
> > Tom Nadeau did a presentation on the discussions
> > regarding the GMPLS MIBs at the Sat MIB Meeting.
> >
> > * how Saturday meeting affects the GMPLS MIBs?
> >
> > * issues for CCAMP: how to represent SONET (i.e.
> > longer) labels
> >
> > * proposed solution on label/index given
> >   Tom asked for feedback from the working group
> >    on this proposed solution
> >
> >    type field + octet string
> >
> >    goal is to support longer labels
> >
> > * Comment by Kireeti to rename
> >   Link Bundling MIB to TE-LINK-MIB.
> >
> > (No questions on presentation).
> >
> > Nadeau: MIB overview presentation
> >
> > Dora: MIB discussion. 2 issues.
> >
> > Tom: SNMP is just another management interface, and like any
> other tool, it
> > needs to be
> > used appropriately. Otherwise, you will have scalability and
> provisioning
> > issues.
> >
> > Kireeti: Lets have a discussion on the list for all of these things.
> >
> > Bert: Discussion going on in IESG/SNMP community. Been hearing
> that people
> > do not want to
> > use SNMP for configuration.   However, I will defer to the WG
> for guidance
> > on this. We
> > need discussion on this issue, in particular from operators.
> > Kireeti: We should take this to the mailing list.
> >
> > Protection/Restoration Team:
> >
> > Kireeti: I suggest that you kick off a discussion so that
> people can pick on
> > points that
> > might be controversial. We need to do this before we make this a WG
> > document.  We need to
> > take this into account.
> >
> > Dmitri:  We took existing protocols and analysed them.   What I
> have said is
> > a
> > consolidation. I think we are fine with the scope. We need to
> focus on the
> > validation.
> >
> > Kireeti: We need to make sure there is a consensus on your cut
> off that it
> > was reasonable.
> >
> > Bonica: Tunnel trace draft. See slides.  Is the requirements
> draft ready for
> > WG last call.
> >
> > Monique:  How is this going to relate to LSP Ping?
> >
> > Ron: When you discover a tunnel, GTTP invokes LSP ping.  There
> is one open
> > item: if the
> > LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> >
> > Kireeti: Are there any comments from anyone else?  The
> requirements document
> > is a WG
> > document. Can we have a show of hands for support of GTTP
> proposed solution
> > as WG
> > document?  We have a small consensus in favor of this. Go back
> to mailing
> > list to confirm.
> >
> > Dmitri: Draft.
> >
> > Dmitri: When you increase the scope of what GMPLS may cover. We need to
> > handle the
> > limited complexity here. This is what we have worked on.   We
> need to handle
> > optical/PSTN.
> >
> > Kireeti: Lets not make this a WG document until discussion on the list.
> >
> > ===========================================
> > Ronald P. Bonica       Ph: 703 886 1681
> > vBNS Engineering       page: 1 888 268 8021
> > Ashburn, Va.
> > ===========================================
> > "We are not on Earth to guard a museum, but
> > to cultivate a flourishing garden of life."
> >                 -- Angelo Giuseppe Roncalli
> >
> >
> ------------------------------------------------------------------------
> >                  Name: IETF55.zip
> >    IETF55.zip    Type: Zip Compressed Data
> (application/x-zip-compressed)
> >              Encoding: base64
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Mon, 25 Nov 2002 13:55:19 -0800
Date: Mon, 25 Nov 2002 13:52:32 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: WG Last Call: draft-ietf-ccamp-tracereq-00.txt (#1)

Hi,

This begins a WG Last Call for draft-ietf-ccamp-tracereq-00.txt.
The Last Call ends Wed, Dec 11, 2002 at 5pm EST.

Please send your comments as a reply to this email for easier
tracking.

Thanks,
Kireeti.

Delivery-date: Mon, 25 Nov 2002 08:28:18 -0800
From: John Drake <[email-masked]>
To: [email-masked]
Cc: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Mon, 25 Nov 2002 08:24:16 -0800

Jonathan,

The various Test transport mechanisms that are currently defined in
draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
various carriers and organizations such as the OIF.  The fact that the
individual carriers have different requirements for the contents of the
various SDH/SONET overheads is also consistent with my reading of Deborah's
recent e-mail on this topic. 

Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
allows the transport of T.50 characters, I think we're done wrt
draft-ietf-ccamp-lmp-test-sonet-sdh.

Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
work aimed at G.7714.1 is compatible with the T.50 requirement.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 PM
To: John Drake
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: Re: J0/J1 encoding issues

John -

I think you forgot what my original message said.  It stated:

> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.

I fail to see what is incorrect with the above.

While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
J0/J1/J2 that fall within the requirements of G.707, it also includes
methods that don't.  This situation SHOULD be resolved to provide the
greatest amount of interoperability while reducing the number of trace
methods that need to be implemented.

I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
only provides methods that fall outside the requirements of G.707.  This
situation MUST be resolved.

Jonathan Sadler

John Drake wrote:
> 
> Wouldn't it be more precise to say that it is an issue with
> draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> draft-ietf-ccamp-lmp-test-sonet-sdh?
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:49 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> Therefore, it is an issue.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
then
> > Jonathan Sadler's issue is a non-issue?
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Lang
> > Sent: Thursday, November 21, 2002 8:56 AM
> > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > 'ccamp '
> > Subject: FW: J0/J1 encoding issues
> >
> > Deborah,
> >   Thanks for the note. The option that Jonathan mentioned is one of a
> couple
> > options we define for Jx. We defined other options to
> > interwork with existing equipment without requiring any changes to
> > existing encodings (this would support both C1 and T.50 requirements).
> > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > Correlation. We welcome additional comments from you and others at
> > T1X1.5/ITU.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Brungard, Deborah A, ALASO
> > To: [email-masked]; ccamp
> > Sent: 11/21/2002 5:22 AM
> > Subject: RE: J0/J1 encoding issues
> >
> > As Jonathan says, the current G.707 is using T.50. And there's more.
> > Example, for J0, one currently needs to support:
> > - previously defined C1 (repeating one-byte)
> > - T.50 (with format of G.707)
> > - no J0 (for equipment not supporting).
> >
> > So already we have defined multiple applications for this byte. Not to
> > say, there will be not any new ones. Even ITU knows, it never is
> > final;-)
> >
> > For supporting LMP's use, we need to understand the scenarios of use
> > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > inter-operator, applied for equipment installation verification or
> > service connection verification, etc. And hardware implications.
> >
> > Actually, G.831 defines multiple uses depending if inter or intra -
> > including for intra-operator, support of routing/path set-up (and G.831
> > was done years ago).
> >
> > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > proposal for the meeting and we can start the discussion. The next ITU-T
> > meeting is in January. If the LMP editors need help on our T1X1.5
> > process, just ask.
> >
> > Deborah
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 7:59 PM
> > To: ccamp
> > Subject: J0/J1 encoding issues
> >
> > All -
> >
> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.
> >
> > This message is being sent to document this issue.  It is not a
> > statement that no other issues exist -- I expect that the appropriate
> > experts in the ITU will review the rest of these two drafts and
> > provide appropriate comment.
> >
> > Jonathan Sadler

(I disclaim the disclaimer that follows this message.)
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Mon, 25 Nov 2002 05:25:09 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-czezowski-optical-recovery-reqs-00.txt
Date: Mon, 25 Nov 2002 08:19:09 -0500

--NextPart

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

	Title		: Optical Network Failure Recovery Requirements
	Author(s)	: P. Czezowski, T. Soumiya
	Filename	: draft-czezowski-optical-recovery-reqs-00.txt
	Pages		: 11
	Date		: 2002-10-28
	
This draft describes requirements for control plane-based recovery 
from data plane failures in pre-OTN networks.  pre-OTN networks are 
transport networks that have a GMPLS-based control plane and various 
transport plane technologies (such as Optical Cross Connects and 
Optical Add/Drop Multiplexers, etc.)  An important feature of these 
networks is recovery from failures - using either a protection or 
restoration scheme.  Achieving recovery under strict time constraints 
is a difficult problem.  Shared mesh-based recovery is especially 
desirable for reducing spare capacity ratios and achieving flexible 
recovery scenarios.  Following a brief overview and consideration of 
the requirements, they are presented in an itemized list in section 
3.4 of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-czezowski-optical-recovery-reqs-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-czezowski-optical-recovery-reqs-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-czezowski-optical-recovery-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-czezowski-optical-recovery-reqs-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: Sun, 24 Nov 2002 19:27:30 -0800
Date: Sun, 24 Nov 2002 22:10:17 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: IETF 55 - CCAMP Minutes
To: [email-masked]
Cc: [email-masked]

Thanks!

I will add this to the minutes.

                  Ron

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 10:12 PM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: IETF 55 - CCAMP Minutes
>
>
> hi ron, all
>
> i do not see the report on the gmpls for overlay networks
> what i have is as follows (may be others can correct me
> or complete this):
>
> G.Swallow: discussed the application of gmpls for overlay
> networks, ending with a proposal for making this a
> wg i-d (proposed standard) see for more details:
> http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
>
> K.Kompella: asked for people in favor/opposed: the result
> was that only a few people (2 or 3) were opposed whilst
> the vast majority were in favor
>
> S.Throwbridge: asked whether the proposal was aligned with
> the carrier requirements (without more details)
>
> K.Kompella: let's bring it to the mailing list.
>
> also some comments:
>
> "> Dmitri: Could you comment on applicability of incompatibility with
> other
> > documents."
>
> "Can you comment on backward compatibility with the other lmp
> documents ?"
>
> thanks,
> - dimitri.
>
> Ron Bonica wrote:
> >
> > Folks,
> >
> > CCAMP WG minutes follow. Slides are attached. Please comment on
> the minutes
> > within two weeks so that we can make any required corrections
> and enter them
> > into the record.
> >
> >                                            Ron
> >
> > P.S. Kireeti's presentation provides a snapshot of WG status. I
> will make
> > sure that the ID tracker stays up to date so we will always
> have a current
> > picture of WG status.
> >
> > ===============================
> >
> > IETF 54 CCAMP Meeting Minutes
> > ==============================
> >
> > Schedule rearranged due to technical difficulties.....
> >
> > Kireeti:  Can someone come up here and sing during the break? *)
> >
> > 0935 - 0950
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
> >                 Lang
> >
> > Provided summary of updates to LMP draft.  See his slides for details.
> > Thinks we are ready for IESG last call. Summary of updates to
> LMP WDM draft.
> > See slides for details. Ready for WG last call.
> >
> > Bonica: initiate last call on list after meeting.
> >
> > LMP Test Sonet SDH draft. See slides for details. After
> changes, we should
> > solicit
> > comments from list. We would like a WG last call thereafter.
> Get a feel from
> > the room?
> >
> > Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> >
> > Bert: The base LMP document was intended for proposed standard. We got
> > pushback
> > from ITU people stating that we should not be working on some
> of this stuff,
> > so we
> > split it out to a separate document. Are we intending on prop
> standard for
> > this stuff?
> >
> > Kireeti: Yes, prop. Standards stuff.
> >
> > Bert: Are we on our proper turf? I would like ITU people to
> speak up on this
> > as well
> > as review it. I don't want discussion during last call, want
> resolution now.
> >
> > Speaker 1: Question RE: LMP. After this meeting I intend to
> start a draft.
> > After reading LMP specification, I believe it has mandatory
> configuration.
> > Are there security considerations.
> >
> > Lang: Yes, security considerations are mandatory.
> >
> > Speaker 1: I would like security to be optional.
> >
> > Bert: Security considerations may not be optional.  We can have some as
> > optional,
> > but some mandatory security options are required.
> >
> > Kireeti: It is mandatory to define security - how to run LMP in a secure
> > mode.
> > It is not mandatory to run LMP in a secure mode. Can you?
> >
> > Lang: That is correct, it can be run un-secure.  Ipsec is
> defined for LMP.
> > If you do not want to run IPSec, you can run it without.
> >
> > Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> > consistent with ITU
> > T.50 requirement. Printable ASCII characters in particular might be an
> > issue.
> >
> > Bert: Please pose question to mailing list.
> >
> > Ron: That way we will have record of conversation.
> >
> > Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
> Will there
> > be any
> > additional alignment with this?
> >
> > Lang: I think the 7714.1 document is more closely related to bootstrap
> > document, and
> > I would lke to discuss this in next part of presentation.
> >
> > Lyndon: This is now taking LMP and LMP-WDM that are tech
> specific. Are there
> > any non-tech
> > specific things that cannot be applied to both.
> >
> > Lang: The whole document can be applied to both.
> >
> > Kireeti: Is there any objection in ITU from letting IETF have
> this document
> > or will
> > we dribble out requirements one by one?
> >
> > ITU leason: I cannot speak for all ITUT, but we need to socialize this
> > within the ITU.
> > There is work going on with regard to discovery in ITU 7714
> that might need
> > to be aligned.
> > However, I will try to get discussion going on rapidly.
> >
> > Dmitry P:  There may be issues with the way the messages are encoded.
> >
> > Kireeti:  We are not talking about discovery; test messages.
> Documents were
> > separated
> > so that we can work issues doc-by-doc.  Good to get ruling for each
> > document. The
> > typical issues with using J0 etc... has rules for how to use this.  Make
> > clear that
> > that some issues are about before service starts.
> >
> > Speaker 5: 7714 issue: if they do the same thing, then why define two
> > documents for this?
> >
> > Lang: There may be overlap between next document, but not here.
> >
> > Speaker 5: Need to be clear about what the overlaps are.
> >
> > Lang: Bootstrap document (next doc), the intro describes why
> the doc exists.
> > Prev. document is defined in LMP base document. If you disagree, let me
> > know.
> >
> > LMP Bootstrap document. See slides for details. This is not WG document.
> > Would like
> > technical comments on list.
> >
> > Dmitri: Could you comment on applicability of incompatibility with other
> > documents.
> >
> > Lang: The point to make is the information exchanged is the
> same as that for
> > the LMP
> > protocol. There is no new information exchanged.
> >
> > Kireeti: We need to continue this on the list (ITU input) on how we move
> > these documents
> > forward.
> >
> > Kireeti - CCAMP 55 WG status.
> >
> > Kireeti: Is there any problem with sending GMPLS framework to IESG as
> > informational.
> >
> > Bert: I reviewed this doc a while back, and question is that
> non-standard
> > extensions are
> > detailed here. This seems strange to publish a document that
> suggests a way
> > of signaling
> > things without a document being somewhere that details the specifics
> > somewhere.
> >
> > Dmitri: We have been looking for comments RE: pointers/document
> to fulfill
> > your query. I
> > think it is unfair to continue without filling these
> requirements. When I
> > sent comments
> > on the list, I asked people to provide pointers. If people would like to
> > continue, please
> > send pointers ASAP.
> >
> > Kireeti: As a fallback, what are we going to do if no docs are received.
> >
> > Bert: Throw it into the garbage.
> >
> > Kireeti: Unless we get pointers, this goes in the can.
> >
> > Kireeti: One thing has been asked about is changes to the
> charter. We want
> > to make
> > changes to the charter. Please send us suggestions. Few additions:
> > inter-area (within AS
> > domain),  Protection/restoration, optical VPN.  This will be discussed
> > partially during
> > SUB-IP meeting, but approval of charter changes come from IESG.
> >
> > JPV: Question about the charter. Will signaling between
> computation server
> > and client are
> > part of the charter, or do we need to add?
> >
> > Kireeti: The current charter does not explicitly have this.
> This is part of
> > the charter
> > extensions we are asking for.
> >
> > JPV: This can be used in other areas.
> >
> > Kireeti: Don't go there. If it is in the charter it is, if not
> then no. Need
> > to make sure
> > this is in the charter.
> >
> > Ron: I will send out an update on the charter additions
> (proposed) to the
> > mailing list.
> >
> > Ashok - Interoperability draft.
> >
> > Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> > issues for RSVP.
> >
> > Bert: These are separate documents. Do this in RSVP.
> >
> > Lou:  Spec. requires TSPEC. Lets talk about this offline.
> >
> > Kireeti: Okay. I want to talk about some implementation
> recommendations. How
> > are these
> > published?
> >
> > Bert: Implementation recommendations are fine to either publish
> as BCP or
> > Informational.
> > I am worried about the limited set of specifications/issues and
> that they
> > are captured.
> >
> > Kireeti: Generic RSVP things are already specified (according
> to Lou). Lets
> > talk about
> > this offline to see where changes are required. Define what
> issues are, how
> > are they
> > specified. Do this offline.  Should we add recommendations to
> implementation
> > survey as an
> > appendix?
> >
> > Bert: Whichever.
> >
> > Lou: These look like guidelines to implementations. This is usually done
> > outside of spec.
> > done as BCP/Info.
> >
> > Kireeti: Question is where to put it.
> >
> > Lou: Seems like this is not a BCP.
> >
> > Kireeti: Too early to say that these include "best" practices. Looks
> > informational.
> > Need to talk with Lou about remaining issues.
> >
> > Tom Nadeau did a presentation on the discussions
> > regarding the GMPLS MIBs at the Sat MIB Meeting.
> >
> > * how Saturday meeting affects the GMPLS MIBs?
> >
> > * issues for CCAMP: how to represent SONET (i.e.
> > longer) labels
> >
> > * proposed solution on label/index given
> >   Tom asked for feedback from the working group
> >    on this proposed solution
> >
> >    type field + octet string
> >
> >    goal is to support longer labels
> >
> > * Comment by Kireeti to rename
> >   Link Bundling MIB to TE-LINK-MIB.
> >
> > (No questions on presentation).
> >
> > Nadeau: MIB overview presentation
> >
> > Dora: MIB discussion. 2 issues.
> >
> > Tom: SNMP is just another management interface, and like any
> other tool, it
> > needs to be
> > used appropriately. Otherwise, you will have scalability and
> provisioning
> > issues.
> >
> > Kireeti: Lets have a discussion on the list for all of these things.
> >
> > Bert: Discussion going on in IESG/SNMP community. Been hearing
> that people
> > do not want to
> > use SNMP for configuration.   However, I will defer to the WG
> for guidance
> > on this. We
> > need discussion on this issue, in particular from operators.
> > Kireeti: We should take this to the mailing list.
> >
> > Protection/Restoration Team:
> >
> > Kireeti: I suggest that you kick off a discussion so that
> people can pick on
> > points that
> > might be controversial. We need to do this before we make this a WG
> > document.  We need to
> > take this into account.
> >
> > Dmitri:  We took existing protocols and analysed them.   What I
> have said is
> > a
> > consolidation. I think we are fine with the scope. We need to
> focus on the
> > validation.
> >
> > Kireeti: We need to make sure there is a consensus on your cut
> off that it
> > was reasonable.
> >
> > Bonica: Tunnel trace draft. See slides.  Is the requirements
> draft ready for
> > WG last call.
> >
> > Monique:  How is this going to relate to LSP Ping?
> >
> > Ron: When you discover a tunnel, GTTP invokes LSP ping.  There
> is one open
> > item: if the
> > LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> >
> > Kireeti: Are there any comments from anyone else?  The
> requirements document
> > is a WG
> > document. Can we have a show of hands for support of GTTP
> proposed solution
> > as WG
> > document?  We have a small consensus in favor of this. Go back
> to mailing
> > list to confirm.
> >
> > Dmitri: Draft.
> >
> > Dmitri: When you increase the scope of what GMPLS may cover. We need to
> > handle the
> > limited complexity here. This is what we have worked on.   We
> need to handle
> > optical/PSTN.
> >
> > Kireeti: Lets not make this a WG document until discussion on the list.
> >
> > ===========================================
> > Ronald P. Bonica       Ph: 703 886 1681
> > vBNS Engineering       page: 1 888 268 8021
> > Ashburn, Va.
> > ===========================================
> > "We are not on Earth to guard a museum, but
> > to cultivate a flourishing garden of life."
> >                 -- Angelo Giuseppe Roncalli
> >
> >
> ------------------------------------------------------------------------
> >                  Name: IETF55.zip
> >    IETF55.zip    Type: Zip Compressed Data
> (application/x-zip-compressed)
> >              Encoding: base64
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Sun, 24 Nov 2002 19:27:19 -0800
Date: Sun, 24 Nov 2002 22:10:19 -0500
From: Ron Bonica <[email-masked]>
Subject: =?ks_c_5601-1987?B?UkU6IFvIuL3FXSBJRVRGIDU1IC0gQ0NBTVAgTWludXRlcw==?=
To: [email-masked], [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_a2UF5+gQ6oDiaLalA6Tmbw)
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: QUOTED-PRINTABLE

[=C8=B8=BD=C5] IETF 55 - CCAMP MinutesThanks! I will make these corre=
ctions

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Sunday, November 24, 2002 9:59 PM
  To: [email-masked]; [email-masked]
  Subject: [=C8=B8=BD=C5] IETF 55 - CCAMP Minutes

  Hi Ron,
  Thank you for the minutes.

  Speaker 1 is Kim.
  And, I'd like to change the minutes of Speaker-1 as follows:

  Kim: Question RE: LMP. I checked minor editing errors in LMP Ver 7.=
 After
this meeting I'll tell Mr. Lang them.
  After reading LMP specification, I believe the security considerati=
on has
mandatory configuration.
  Is my understanding right?

  =BF=F8=BA=BB =B3=BB=BF=EB:

  =BA=B8=B3=BD=BB=E7=B6=F7: Ron Bonica[[email-masked]]
  =B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]
  =C1=A6=B8=F1: IETF 55 - CCAMP Minutes
  =B9=DE=C0=BA=B3=AF=C2=A5: 2002/11/25 =BF=F9 07:26

  Folks,
  CCAMP WG minutes follow. Slides are attached. Please comment on the
minutes
  within two weeks so that we can make any required corrections and e=
nter
them
  into the record.

Ron
  P.S. Kireeti's presentation provides a snapshot of WG status. I wil=
l make
  sure that the ID tracker stays up to date so we will always have a =
current
  picture of WG status.
  =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

  IETF 54 CCAMP Meeting Minutes
  =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
  Schedule rearranged due to technical difficulties.....
  Kireeti:  Can someone come up here and sing during the break? *)
  0935 - 0950
  http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
                              Lang
  Provided summary of updates to LMP draft.  See his slides for detai=
ls.
  Thinks we are ready for IESG last call. Summary of updates to LMP W=
DM
draft.
  See slides for details. Ready for WG last call.
  Bonica: initiate last call on list after meeting.
  LMP Test Sonet SDH draft. See slides for details. After changes, we=
 should
  solicit
  comments from list. We would like a WG last call thereafter. Get a =
feel
=66rom
  the room?
  Kireeti:  Assuming that J0-64 format is removed, are there any comm=
ents?
  Bert: The base LMP document was intended for proposed standard. We =
got
  pushback
  from ITU people stating that we should not be working on some of th=
is
stuff,
  so we
  split it out to a separate document. Are we intending on prop stand=
ard for
  this stuff?
  Kireeti: Yes, prop. Standards stuff.
  Bert: Are we on our proper turf? I would like ITU people to speak u=
p on
this
  as well
  as review it. I don't want discussion during last call, want resolu=
tion
now.
  Speaker 1: Question RE: LMP. After this meeting I intend to start a=
 draft.
  After reading LMP specification, I believe it has mandatory configu=
ration.
  Are there security considerations.
  Lang: Yes, security considerations are mandatory.
  Speaker 1: I would like security to be optional.
  Bert: Security considerations may not be optional.  We can have som=
e as
  optional,
  but some mandatory security options are required.
  Kireeti: It is mandatory to define security - how to run LMP in a s=
ecure
  mode.
  It is not mandatory to run LMP in a secure mode. Can you?
  Lang: That is correct, it can be run un-secure.  Ipsec is defined f=
or LMP.
  If you do not want to run IPSec, you can run it without.
  Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
  consistent with ITU
  T.50 requirement. Printable ASCII characters in particular might be=
 an
  issue.
  Bert: Please pose question to mailing list.
  Ron: That way we will have record of conversation.
  Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.  Wil=
l there
  be any
  additional alignment with this?
  Lang: I think the 7714.1 document is more closely related to bootst=
rap
  document, and
  I would lke to discuss this in next part of presentation.
  Lyndon: This is now taking LMP and LMP-WDM that are tech specific. =
Are
there
  any non-tech
  specific things that cannot be applied to both.
  Lang: The whole document can be applied to both.
  Kireeti: Is there any objection in ITU from letting IETF have this
document
  or will
  we dribble out requirements one by one?
  ITU leason: I cannot speak for all ITUT, but we need to socialize t=
his
  within the ITU.
  There is work going on with regard to discovery in ITU 7714 that mi=
ght
need
  to be aligned.
  However, I will try to get discussion going on rapidly.
  Dmitry P:  There may be issues with the way the messages are encode=
d.
  Kireeti:  We are not talking about discovery; test messages. Docume=
nts
were
  separated
  so that we can work issues doc-by-doc.  Good to get ruling for each
  document. The
  typical issues with using J0 etc... has rules for how to use this. =
 Make
  clear that
  that some issues are about before service starts.
  Speaker 5: 7714 issue: if they do the same thing, then why define t=
wo
  documents for this?
  Lang: There may be overlap between next document, but not here.
  Speaker 5: Need to be clear about what the overlaps are.
  Lang: Bootstrap document (next doc), the intro describes why the do=
c
exists.
  Prev. document is defined in LMP base document. If you disagree, le=
t me
  know.
  LMP Bootstrap document. See slides for details. This is not WG docu=
ment.
  Would like
  technical comments on list.
  Dmitri: Could you comment on applicability of incompatibility with =
other
  documents.
  Lang: The point to make is the information exchanged is the same as=
 that
for
  the LMP
  protocol. There is no new information exchanged.
  Kireeti: We need to continue this on the list (ITU input) on how we=
 move
  these documents
  forward.
  Kireeti - CCAMP 55 WG status.
  Kireeti: Is there any problem with sending GMPLS framework to IESG =
as
  informational.
  Bert: I reviewed this doc a while back, and question is that non-st=
andard
  extensions are
  detailed here. This seems strange to publish a document that sugges=
ts a
way
  of signaling
  things without a document being somewhere that details the specific=
s
  somewhere.
  Dmitri: We have been looking for comments RE: pointers/document to =
fulfill
  your query. I
  think it is unfair to continue without filling these requirements. =
When I
  sent comments
  on the list, I asked people to provide pointers. If people would li=
ke to
  continue, please
  send pointers ASAP.
  Kireeti: As a fallback, what are we going to do if no docs are rece=
ived.
  Bert: Throw it into the garbage.
  Kireeti: Unless we get pointers, this goes in the can.
  Kireeti: One thing has been asked about is changes to the charter. =
We want
  to make
  changes to the charter. Please send us suggestions. Few additions:
  inter-area (within AS
  domain),  Protection/restoration, optical VPN.  This will be discus=
sed
  partially during
  SUB-IP meeting, but approval of charter changes come from IESG.
  JPV: Question about the charter. Will signaling between computation=
 server
  and client are
  part of the charter, or do we need to add?
  Kireeti: The current charter does not explicitly have this. This is=
 part
of
  the charter
  extensions we are asking for.
  JPV: This can be used in other areas.
  Kireeti: Don't go there. If it is in the charter it is, if not then=
 no.
Need
  to make sure
  this is in the charter.
  Ron: I will send out an update on the charter additions (proposed) =
to the
  mailing list.
  Ashok - Interoperability draft.
  Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. Thes=
e are
  issues for RSVP.
  Bert: These are separate documents. Do this in RSVP.
  Lou:  Spec. requires TSPEC. Lets talk about this offline.
  Kireeti: Okay. I want to talk about some implementation recommendat=
ions.
How
  are these
  published?
  Bert: Implementation recommendations are fine to either publish as =
BCP or
  Informational.
  I am worried about the limited set of specifications/issues and tha=
t they
  are captured.
  Kireeti: Generic RSVP things are already specified (according to Lo=
u).
Lets
  talk about
  this offline to see where changes are required. Define what issues =
are,
how
  are they
  specified. Do this offline.  Should we add recommendations to
implementation
  survey as an
  appendix?
  Bert: Whichever.
  Lou: These look like guidelines to implementations. This is usually=
 done
  outside of spec.
  done as BCP/Info.
  Kireeti: Question is where to put it.
  Lou: Seems like this is not a BCP.
  Kireeti: Too early to say that these include "best" practices. Look=
s
  informational.
  Need to talk with Lou about remaining issues.

  Tom Nadeau did a presentation on the discussions
  regarding the GMPLS MIBs at the Sat MIB Meeting.
  * how Saturday meeting affects the GMPLS MIBs?
  * issues for CCAMP: how to represent SONET (i.e.
  longer) labels
  * proposed solution on label/index given
    Tom asked for feedback from the working group
     on this proposed solution
     type field + octet string
     goal is to support longer labels
  * Comment by Kireeti to rename
    Link Bundling MIB to TE-LINK-MIB.
  (No questions on presentation).

  Nadeau: MIB overview presentation
  Dora: MIB discussion. 2 issues.
  Tom: SNMP is just another management interface, and like any other =
tool,
it
  needs to be
  used appropriately. Otherwise, you will have scalability and provis=
ioning
  issues.
  Kireeti: Lets have a discussion on the list for all of these things=
.
  Bert: Discussion going on in IESG/SNMP community. Been hearing that=
 people
  do not want to
  use SNMP for configuration.   However, I will defer to the WG for g=
uidance
  on this. We
  need discussion on this issue, in particular from operators.
  Kireeti: We should take this to the mailing list.

  Protection/Restoration Team:
  Kireeti: I suggest that you kick off a discussion so that people ca=
n pick
on
  points that
  might be controversial. We need to do this before we make this a WG
  document.  We need to
  take this into account.
  Dmitri:  We took existing protocols and analysed them.   What I hav=
e said
is
  a
  consolidation. I think we are fine with the scope. We need to focus=
 on the
  validation.
  Kireeti: We need to make sure there is a consensus on your cut off =
that it
  was reasonable.
  Bonica: Tunnel trace draft. See slides.  Is the requirements draft =
ready
for
  WG last call.
  Monique:  How is this going to relate to LSP Ping?
  Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is o=
ne open
  item: if the
  LSP is supported by an IP/IP tunnel. LSP Ping will not tell you thi=
s.
  Kireeti: Are there any comments from anyone else?  The requirements
document
  is a WG
  document. Can we have a show of hands for support of GTTP proposed
solution
  as WG
  document?  We have a small consensus in favor of this. Go back to m=
ailing
  list to confirm.
  Dmitri: Draft.
  Dmitri: When you increase the scope of what GMPLS may cover. We nee=
d to
  handle the
  limited complexity here. This is what we have worked on.   We need =
to
handle
  optical/PSTN.
  Kireeti: Lets not make this a WG document until discussion on the l=
ist.

  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Ronald P. Bonica           Ph: 703 886 1681
  vBNS Engineering           page: 1 888 268 8021
  Ashburn, Va.
  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  "We are not on Earth to guard a museum, but
  to cultivate a flourishing garden of life."
                              -- Angelo Giuseppe Roncalli

--Boundary_(ID_a2UF5+gQ6oDiaLalA6Tmbw)
Content-type: text/html; charset=ks_c_5601-1987
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>[=C8=B8=BD=C5] IETF 55 - CCAMP Minutes</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dks_c_5601-1987">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D836050903-25112002>Thanks! I will make these=20
corrections</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D836050903-25112002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> [email-masked]=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Sunday, November 24, 2002 =
9:59=20
  PM<BR><B>To:</B> [email-masked];=20
  [email-masked]<BR><B>Subject:</B> [=C8=B8=BD=C5] IETF 55 - CCAMP=20
  Minutes<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Hi Ron,</FONT> <BR><FONT size=3D2>Thank you for the=20
  minutes.</FONT> </P>
  <P><FONT size=3D2>Speaker 1 is Kim.</FONT> <BR><FONT size=3D2>And, I'd =
like to=20
  change the minutes of Speaker-1 as follows:</FONT> </P>
  <P><FONT size=3D2>Kim: Question RE: LMP. I checked minor editing =
errors in LMP=20
  Ver 7. After this meeting I'll tell Mr. Lang them.</FONT> <BR><FONT=20
  size=3D2>After reading LMP specification, I believe the security =
consideration=20
  has mandatory configuration. </FONT><BR><FONT size=3D2>Is my =
understanding=20
  right?</FONT> </P><BR>
  <P><FONT size=3D2>=BF=F8=BA=BB =B3=BB=BF=EB:</FONT> </P>
  <P><FONT size=3D2>=BA=B8=B3=BD=BB=E7=B6=F7: Ron =
Bonica[[email-masked]]</FONT> <BR><FONT=20
  size=3D2>=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]</FONT> <BR><FONT =
size=3D2>=C1=A6=B8=F1: IETF 55 - CCAMP=20
  Minutes</FONT> <BR><FONT size=3D2>=B9=DE=C0=BA=B3=AF=C2=A5: 2002/11/25 =
=BF=F9 07:26</FONT> </P><BR>
  <P><FONT size=3D2>Folks,</FONT> <BR><FONT size=3D2>CCAMP WG minutes =
follow. Slides=20
  are attached. Please comment on the minutes </FONT><BR><FONT =
size=3D2>within two=20
  weeks so that we can make any required corrections and enter them=20
  </FONT><BR><FONT size=3D2>into the record.</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>&nbsp;&nbsp; =

  Ron</FONT> <BR><FONT size=3D2>P.S. Kireeti's presentation provides a =
snapshot of=20
  WG status. I will make </FONT><BR><FONT size=3D2>sure that the ID =
tracker stays=20
  up to date so we will always have a current </FONT><BR><FONT =
size=3D2>picture of=20
  WG status.</FONT> <BR><FONT =
size=3D2>=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</FONT> </P>
  <P><FONT size=3D2>IETF 54 CCAMP Meeting Minutes </FONT><BR><FONT=20
  =
size=3D2>=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</FONT> <BR><FONT size=3D2>Schedule=20
  rearranged due to technical difficulties.....</FONT> <BR><FONT=20
  size=3D2>Kireeti:&nbsp; Can someone come up here and sing during the =
break?=20
  *)</FONT> <BR><FONT size=3D2>0935 - 0950 </FONT><BR><FONT size=3D2><A=20
  target=3D_blank=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt">=
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt</A>=20
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  Lang</FONT> <BR><FONT size=3D2>Provided summary of updates to LMP =
draft.&nbsp;=20
  See his slides for details. </FONT><BR><FONT size=3D2>Thinks we are =
ready for=20
  IESG last call. Summary of updates to LMP WDM draft. </FONT><BR><FONT=20
  size=3D2>See slides for details. Ready for WG last call.</FONT> =
<BR><FONT=20
  size=3D2>Bonica: initiate last call on list after meeting.</FONT> =
<BR><FONT=20
  size=3D2>LMP Test Sonet SDH draft. See slides for details. After =
changes, we=20
  should </FONT><BR><FONT size=3D2>solicit </FONT><BR><FONT =
size=3D2>comments from=20
  list. We would like a WG last call thereafter. Get a feel from=20
  </FONT><BR><FONT size=3D2>the room?</FONT> <BR><FONT =
size=3D2>Kireeti:&nbsp;=20
  Assuming that J0-64 format is removed, are there any comments?</FONT>=20
  <BR><FONT size=3D2>Bert: The base LMP document was intended for =
proposed=20
  standard. We got </FONT><BR><FONT size=3D2>pushback </FONT><BR><FONT =
size=3D2>from=20
  ITU people stating that we should not be working on some of this =
stuff,=20
  </FONT><BR><FONT size=3D2>so we </FONT><BR><FONT size=3D2>split it out =
to a=20
  separate document. Are we intending on prop standard for =
</FONT><BR><FONT=20
  size=3D2>this stuff?</FONT> <BR><FONT size=3D2>Kireeti: Yes, prop. =
Standards=20
  stuff.</FONT> <BR><FONT size=3D2>Bert: Are we on our proper turf? I =
would like=20
  ITU people to speak up on this </FONT><BR><FONT size=3D2>as well=20
  </FONT><BR><FONT size=3D2>as review it. I don't want discussion during =
last=20
  call, want resolution now.</FONT> <BR><FONT size=3D2>Speaker 1: =
Question RE:=20
  LMP. After this meeting I intend to start a draft. </FONT><BR><FONT=20
  size=3D2>After reading LMP specification, I believe it has mandatory=20
  configuration. </FONT><BR><FONT size=3D2>Are there security=20
  considerations.</FONT> <BR><FONT size=3D2>Lang: Yes, security =
considerations are=20
  mandatory.</FONT> <BR><FONT size=3D2>Speaker 1: I would like security =
to be=20
  optional.</FONT> <BR><FONT size=3D2>Bert: Security considerations may =
not be=20
  optional.&nbsp; We can have some as </FONT><BR><FONT =
size=3D2>optional,=20
  </FONT><BR><FONT size=3D2>but some mandatory security options are=20
  required.</FONT> <BR><FONT size=3D2>Kireeti: It is mandatory to define =
security=20
  - how to run LMP in a secure </FONT><BR><FONT size=3D2>mode. =
</FONT><BR><FONT=20
  size=3D2>It is not mandatory to run LMP in a secure mode. Can =
you?</FONT>=20
  <BR><FONT size=3D2>Lang: That is correct, it can be run =
un-secure.&nbsp; Ipsec=20
  is defined for LMP. </FONT><BR><FONT size=3D2>If you do not want to =
run IPSec,=20
  you can run it without.</FONT> <BR><FONT size=3D2>Speaker 2: I am =
concerned=20
  about J0 encoding. It doesn't seem to be </FONT><BR><FONT =
size=3D2>consistent=20
  with ITU </FONT><BR><FONT size=3D2>T.50 requirement. Printable ASCII =
characters=20
  in particular might be an </FONT><BR><FONT size=3D2>issue.</FONT> =
<BR><FONT=20
  size=3D2>Bert: Please pose question to mailing list.</FONT> <BR><FONT=20
  size=3D2>Ron: That way we will have record of conversation.</FONT> =
<BR><FONT=20
  size=3D2>Lyndon Ong(Cienna): My company is editing 7714.1 ITU =
document.&nbsp;=20
  Will there </FONT><BR><FONT size=3D2>be any </FONT><BR><FONT =
size=3D2>additional=20
  alignment with this?</FONT> <BR><FONT size=3D2>Lang: I think the =
7714.1 document=20
  is more closely related to bootstrap </FONT><BR><FONT =
size=3D2>document, and=20
  </FONT><BR><FONT size=3D2>I would lke to discuss this in next part of=20
  presentation.</FONT> <BR><FONT size=3D2>Lyndon: This is now taking LMP =
and=20
  LMP-WDM that are tech specific. Are there </FONT><BR><FONT =
size=3D2>any non-tech=20
  </FONT><BR><FONT size=3D2>specific things that cannot be applied to =
both.</FONT>=20
  <BR><FONT size=3D2>Lang: The whole document can be applied to =
both.</FONT>=20
  <BR><FONT size=3D2>Kireeti: Is there any objection in ITU from letting =
IETF have=20
  this document </FONT><BR><FONT size=3D2>or will </FONT><BR><FONT =
size=3D2>we=20
  dribble out requirements one by one?</FONT> <BR><FONT size=3D2>ITU =
leason: I=20
  cannot speak for all ITUT, but we need to socialize this =
</FONT><BR><FONT=20
  size=3D2>within the ITU. </FONT><BR><FONT size=3D2>There is work going =
on with=20
  regard to discovery in ITU 7714 that might need </FONT><BR><FONT =
size=3D2>to be=20
  aligned. </FONT><BR><FONT size=3D2>However, I will try to get =
discussion going=20
  on rapidly.</FONT> <BR><FONT size=3D2>Dmitry P:&nbsp; There may be =
issues with=20
  the way the messages are encoded.</FONT> <BR><FONT =
size=3D2>Kireeti:&nbsp; We=20
  are not talking about discovery; test messages. Documents were=20
  </FONT><BR><FONT size=3D2>separated </FONT><BR><FONT size=3D2>so that =
we can work=20
  issues doc-by-doc.&nbsp; Good to get ruling for each </FONT><BR><FONT=20
  size=3D2>document. The </FONT><BR><FONT size=3D2>typical issues with =
using J0=20
  etc... has rules for how to use this.&nbsp; Make </FONT><BR><FONT =
size=3D2>clear=20
  that </FONT><BR><FONT size=3D2>that some issues are about before =
service=20
  starts.</FONT> <BR><FONT size=3D2>Speaker 5: 7714 issue: if they do =
the same=20
  thing, then why define two </FONT><BR><FONT size=3D2>documents for =
this?</FONT>=20
  <BR><FONT size=3D2>Lang: There may be overlap between next document, =
but not=20
  here.</FONT> <BR><FONT size=3D2>Speaker 5: Need to be clear about what =
the=20
  overlaps are.</FONT> <BR><FONT size=3D2>Lang: Bootstrap document (next =
doc), the=20
  intro describes why the doc exists. </FONT><BR><FONT size=3D2>Prev. =
document is=20
  defined in LMP base document. If you disagree, let me </FONT><BR><FONT =

  size=3D2>know.</FONT> <BR><FONT size=3D2>LMP Bootstrap document. See =
slides for=20
  details. This is not WG document. </FONT><BR><FONT size=3D2>Would like =

  </FONT><BR><FONT size=3D2>technical comments on list.</FONT> <BR><FONT =

  size=3D2>Dmitri: Could you comment on applicability of incompatibility =
with=20
  other </FONT><BR><FONT size=3D2>documents.</FONT> <BR><FONT =
size=3D2>Lang: The=20
  point to make is the information exchanged is the same as that for=20
  </FONT><BR><FONT size=3D2>the LMP </FONT><BR><FONT size=3D2>protocol. =
There is no=20
  new information exchanged.</FONT> <BR><FONT size=3D2>Kireeti: We need =
to=20
  continue this on the list (ITU input) on how we move </FONT><BR><FONT=20
  size=3D2>these documents </FONT><BR><FONT size=3D2>forward.</FONT> =
<BR><FONT=20
  size=3D2>Kireeti - CCAMP 55 WG status.</FONT> <BR><FONT =
size=3D2>Kireeti: Is there=20
  any problem with sending GMPLS framework to IESG as </FONT><BR><FONT=20
  size=3D2>informational.</FONT> <BR><FONT size=3D2>Bert: I reviewed =
this doc a=20
  while back, and question is that non-standard </FONT><BR><FONT=20
  size=3D2>extensions are </FONT><BR><FONT size=3D2>detailed here. This =
seems=20
  strange to publish a document that suggests a way </FONT><BR><FONT =
size=3D2>of=20
  signaling </FONT><BR><FONT size=3D2>things without a document being =
somewhere=20
  that details the specifics </FONT><BR><FONT size=3D2>somewhere.</FONT> =
<BR><FONT=20
  size=3D2>Dmitri: We have been looking for comments RE: =
pointers/document to=20
  fulfill </FONT><BR><FONT size=3D2>your query. I </FONT><BR><FONT =
size=3D2>think it=20
  is unfair to continue without filling these requirements. When I=20
  </FONT><BR><FONT size=3D2>sent comments </FONT><BR><FONT size=3D2>on =
the list, I=20
  asked people to provide pointers. If people would like to =
</FONT><BR><FONT=20
  size=3D2>continue, please </FONT><BR><FONT size=3D2>send pointers =
ASAP.</FONT>=20
  <BR><FONT size=3D2>Kireeti: As a fallback, what are we going to do if =
no docs=20
  are received.</FONT> <BR><FONT size=3D2>Bert: Throw it into the =
garbage.</FONT>=20
  <BR><FONT size=3D2>Kireeti: Unless we get pointers, this goes in the =
can.</FONT>=20
  <BR><FONT size=3D2>Kireeti: One thing has been asked about is changes =
to the=20
  charter. We want </FONT><BR><FONT size=3D2>to make </FONT><BR><FONT=20
  size=3D2>changes to the charter. Please send us suggestions. Few =
additions:=20
  </FONT><BR><FONT size=3D2>inter-area (within AS </FONT><BR><FONT=20
  size=3D2>domain),&nbsp; Protection/restoration, optical VPN.&nbsp; =
This will be=20
  discussed </FONT><BR><FONT size=3D2>partially during </FONT><BR><FONT=20
  size=3D2>SUB-IP meeting, but approval of charter changes come from =
IESG.</FONT>=20
  <BR><FONT size=3D2>JPV: Question about the charter. Will signaling =
between=20
  computation server </FONT><BR><FONT size=3D2>and client are =
</FONT><BR><FONT=20
  size=3D2>part of the charter, or do we need to add?</FONT> <BR><FONT=20
  size=3D2>Kireeti: The current charter does not explicitly have this. =
This is=20
  part of </FONT><BR><FONT size=3D2>the charter </FONT><BR><FONT =
size=3D2>extensions=20
  we are asking for.</FONT> <BR><FONT size=3D2>JPV: This can be used in =
other=20
  areas.</FONT> <BR><FONT size=3D2>Kireeti: Don't go there. If it is in =
the=20
  charter it is, if not then no. Need </FONT><BR><FONT size=3D2>to make =
sure=20
  </FONT><BR><FONT size=3D2>this is in the charter.</FONT> <BR><FONT =
size=3D2>Ron: I=20
  will send out an update on the charter additions (proposed) to the=20
  </FONT><BR><FONT size=3D2>mailing list.</FONT> <BR><FONT =
size=3D2>Ashok -=20
  Interoperability draft.</FONT> <BR><FONT size=3D2>Kireeti: FEC change =
and TSPEC=20
  changes are orthogonal to GMPLS. These are </FONT><BR><FONT =
size=3D2>issues for=20
  RSVP.</FONT> <BR><FONT size=3D2>Bert: These are separate documents. Do =
this in=20
  RSVP.</FONT> <BR><FONT size=3D2>Lou:&nbsp; Spec. requires TSPEC. Lets =
talk about=20
  this offline.</FONT> <BR><FONT size=3D2>Kireeti: Okay. I want to talk =
about some=20
  implementation recommendations. How </FONT><BR><FONT size=3D2>are =
these=20
  </FONT><BR><FONT size=3D2>published?</FONT> <BR><FONT size=3D2>Bert:=20
  Implementation recommendations are fine to either publish as BCP or=20
  </FONT><BR><FONT size=3D2>Informational. </FONT><BR><FONT size=3D2>I =
am worried=20
  about the limited set of specifications/issues and that they =
</FONT><BR><FONT=20
  size=3D2>are captured.</FONT> <BR><FONT size=3D2>Kireeti: Generic RSVP =
things are=20
  already specified (according to Lou). Lets </FONT><BR><FONT =
size=3D2>talk about=20
  </FONT><BR><FONT size=3D2>this offline to see where changes are =
required. Define=20
  what issues are, how </FONT><BR><FONT size=3D2>are they =
</FONT><BR><FONT=20
  size=3D2>specified. Do this offline.&nbsp; Should we add =
recommendations to=20
  implementation </FONT><BR><FONT size=3D2>survey as an </FONT><BR><FONT =

  size=3D2>appendix?</FONT> <BR><FONT size=3D2>Bert: Whichever.</FONT> =
<BR><FONT=20
  size=3D2>Lou: These look like guidelines to implementations. This is =
usually=20
  done </FONT><BR><FONT size=3D2>outside of spec. </FONT><BR><FONT =
size=3D2>done as=20
  BCP/Info.</FONT> <BR><FONT size=3D2>Kireeti: Question is where to put =
it.</FONT>=20
  <BR><FONT size=3D2>Lou: Seems like this is not a BCP.</FONT> <BR><FONT =

  size=3D2>Kireeti: Too early to say that these include "best" =
practices. Looks=20
  </FONT><BR><FONT size=3D2>informational. </FONT><BR><FONT =
size=3D2>Need to talk=20
  with Lou about remaining issues.</FONT> </P>
  <P><FONT size=3D2>Tom Nadeau did a presentation on the discussions=20
  </FONT><BR><FONT size=3D2>regarding the GMPLS MIBs at the Sat MIB=20
  Meeting.</FONT> <BR><FONT size=3D2>* how Saturday meeting affects the =
GMPLS=20
  MIBs?</FONT> <BR><FONT size=3D2>* issues for CCAMP: how to represent =
SONET (i.e.=20
  </FONT><BR><FONT size=3D2>longer) labels</FONT> <BR><FONT size=3D2>* =
proposed=20
  solution on label/index given </FONT><BR><FONT size=3D2>&nbsp; Tom =
asked for=20
  feedback from the working group </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
on this=20
  proposed solution</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; type field + =
octet=20
  string</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; goal is to support =
longer=20
  labels</FONT> <BR><FONT size=3D2>* Comment by Kireeti to rename =
</FONT><BR><FONT=20
  size=3D2>&nbsp; Link Bundling MIB to TE-LINK-MIB.</FONT> <BR><FONT =
size=3D2>(No=20
  questions on presentation).</FONT> </P>
  <P><FONT size=3D2>Nadeau: MIB overview presentation</FONT> <BR><FONT=20
  size=3D2>Dora: MIB discussion. 2 issues.</FONT> <BR><FONT =
size=3D2>Tom: SNMP is=20
  just another management interface, and like any other tool, it=20
  </FONT><BR><FONT size=3D2>needs to be </FONT><BR><FONT size=3D2>used=20
  appropriately. Otherwise, you will have scalability and provisioning=20
  </FONT><BR><FONT size=3D2>issues.</FONT> <BR><FONT size=3D2>Kireeti: =
Lets have a=20
  discussion on the list for all of these things.</FONT> <BR><FONT =
size=3D2>Bert:=20
  Discussion going on in IESG/SNMP community. Been hearing that people=20
  </FONT><BR><FONT size=3D2>do not want to </FONT><BR><FONT size=3D2>use =
SNMP for=20
  configuration.&nbsp;&nbsp; However, I will defer to the WG for =
guidance=20
  </FONT><BR><FONT size=3D2>on this. We </FONT><BR><FONT size=3D2>need =
discussion on=20
  this issue, in particular from operators. </FONT><BR><FONT =
size=3D2>Kireeti: We=20
  should take this to the mailing list.</FONT> </P>
  <P><FONT size=3D2>Protection/Restoration Team:</FONT> <BR><FONT =
size=3D2>Kireeti:=20
  I suggest that you kick off a discussion so that people can pick on=20
  </FONT><BR><FONT size=3D2>points that </FONT><BR><FONT size=3D2>might =
be=20
  controversial. We need to do this before we make this a WG =
</FONT><BR><FONT=20
  size=3D2>document.&nbsp; We need to </FONT><BR><FONT size=3D2>take =
this into=20
  account.</FONT> <BR><FONT size=3D2>Dmitri:&nbsp; We took existing =
protocols and=20
  analysed them.&nbsp;&nbsp; What I have said is </FONT><BR><FONT =
size=3D2>a=20
  </FONT><BR><FONT size=3D2>consolidation. I think we are fine with the =
scope. We=20
  need to focus on the </FONT><BR><FONT size=3D2>validation.</FONT> =
<BR><FONT=20
  size=3D2>Kireeti: We need to make sure there is a consensus on your =
cut off that=20
  it </FONT><BR><FONT size=3D2>was reasonable.</FONT> <BR><FONT =
size=3D2>Bonica:=20
  Tunnel trace draft. See slides.&nbsp; Is the requirements draft ready =
for=20
  </FONT><BR><FONT size=3D2>WG last call.</FONT> <BR><FONT =
size=3D2>Monique:&nbsp;=20
  How is this going to relate to LSP Ping?</FONT> <BR><FONT =
size=3D2>Ron: When you=20
  discover a tunnel, GTTP invokes LSP ping.&nbsp; There is one open=20
  </FONT><BR><FONT size=3D2>item: if the </FONT><BR><FONT size=3D2>LSP =
is supported=20
  by an IP/IP tunnel. LSP Ping will not tell you this.</FONT> <BR><FONT=20
  size=3D2>Kireeti: Are there any comments from anyone else?&nbsp; The=20
  requirements document </FONT><BR><FONT size=3D2>is a WG =
</FONT><BR><FONT=20
  size=3D2>document. Can we have a show of hands for support of GTTP =
proposed=20
  solution </FONT><BR><FONT size=3D2>as WG </FONT><BR><FONT =
size=3D2>document?&nbsp;=20
  We have a small consensus in favor of this. Go back to mailing=20
  </FONT><BR><FONT size=3D2>list to confirm.</FONT> <BR><FONT =
size=3D2>Dmitri:=20
  Draft.</FONT> <BR><FONT size=3D2>Dmitri: When you increase the scope =
of what=20
  GMPLS may cover. We need to </FONT><BR><FONT size=3D2>handle the=20
  </FONT><BR><FONT size=3D2>limited complexity here. This is what we =
have worked=20
  on.&nbsp;&nbsp; We need to handle </FONT><BR><FONT =
size=3D2>optical/PSTN.</FONT>=20
  <BR><FONT size=3D2>Kireeti: Lets not make this a WG document until =
discussion on=20
  the list.</FONT> </P><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
  <P><FONT =
size=3D2>=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 =
</FONT><BR><FONT=20
  size=3D2>Ronald P. Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;=20
  Ph: 703 886 1681 </FONT><BR><FONT size=3D2>vBNS=20
  Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =
page: 1 888=20
  268 8021 </FONT><BR><FONT size=3D2>Ashburn, Va. </FONT><BR><FONT=20
  =
size=3D2>=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 =
</FONT><BR><FONT size=3D2>"We=20
  are not on Earth to guard a museum, but </FONT><BR><FONT size=3D2>to =
cultivate a=20
  flourishing garden of life."=20
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>&nbsp;&nbsp;&nbsp; --=20
  Angelo Giuseppe Roncalli</FONT> </P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_a2UF5+gQ6oDiaLalA6Tmbw)--

Delivery-date: Sun, 24 Nov 2002 19:09:39 -0800
Date: Mon, 25 Nov 2002 04:11:49 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

hi ron, all

i do not see the report on the gmpls for overlay networks
what i have is as follows (may be others can correct me
or complete this):

G.Swallow: discussed the application of gmpls for overlay
networks, ending with a proposal for making this a 
wg i-d (proposed standard) see for more details:
http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt

K.Kompella: asked for people in favor/opposed: the result
was that only a few people (2 or 3) were opposed whilst
the vast majority were in favor

S.Throwbridge: asked whether the proposal was aligned with
the carrier requirements (without more details)

K.Kompella: let's bring it to the mailing list.

also some comments:

"> Dmitri: Could you comment on applicability of incompatibility with
other
> documents."

"Can you comment on backward compatibility with the other lmp
documents ?"

thanks,
- dimitri.

Ron Bonica wrote:
> 
> Folks,
> 
> CCAMP WG minutes follow. Slides are attached. Please comment on the minutes
> within two weeks so that we can make any required corrections and enter them
> into the record.
> 
>                                            Ron
> 
> P.S. Kireeti's presentation provides a snapshot of WG status. I will make
> sure that the ID tracker stays up to date so we will always have a current
> picture of WG status.
> 
> ===============================
> 
> IETF 54 CCAMP Meeting Minutes
> ==============================
> 
> Schedule rearranged due to technical difficulties.....
> 
> Kireeti:  Can someone come up here and sing during the break? *)
> 
> 0935 - 0950
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
>                 Lang
> 
> Provided summary of updates to LMP draft.  See his slides for details.
> Thinks we are ready for IESG last call. Summary of updates to LMP WDM draft.
> See slides for details. Ready for WG last call.
> 
> Bonica: initiate last call on list after meeting.
> 
> LMP Test Sonet SDH draft. See slides for details. After changes, we should
> solicit
> comments from list. We would like a WG last call thereafter. Get a feel from
> the room?
> 
> Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> 
> Bert: The base LMP document was intended for proposed standard. We got
> pushback
> from ITU people stating that we should not be working on some of this stuff,
> so we
> split it out to a separate document. Are we intending on prop standard for
> this stuff?
> 
> Kireeti: Yes, prop. Standards stuff.
> 
> Bert: Are we on our proper turf? I would like ITU people to speak up on this
> as well
> as review it. I don't want discussion during last call, want resolution now.
> 
> Speaker 1: Question RE: LMP. After this meeting I intend to start a draft.
> After reading LMP specification, I believe it has mandatory configuration.
> Are there security considerations.
> 
> Lang: Yes, security considerations are mandatory.
> 
> Speaker 1: I would like security to be optional.
> 
> Bert: Security considerations may not be optional.  We can have some as
> optional,
> but some mandatory security options are required.
> 
> Kireeti: It is mandatory to define security - how to run LMP in a secure
> mode.
> It is not mandatory to run LMP in a secure mode. Can you?
> 
> Lang: That is correct, it can be run un-secure.  Ipsec is defined for LMP.
> If you do not want to run IPSec, you can run it without.
> 
> Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> consistent with ITU
> T.50 requirement. Printable ASCII characters in particular might be an
> issue.
> 
> Bert: Please pose question to mailing list.
> 
> Ron: That way we will have record of conversation.
> 
> Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.  Will there
> be any
> additional alignment with this?
> 
> Lang: I think the 7714.1 document is more closely related to bootstrap
> document, and
> I would lke to discuss this in next part of presentation.
> 
> Lyndon: This is now taking LMP and LMP-WDM that are tech specific. Are there
> any non-tech
> specific things that cannot be applied to both.
> 
> Lang: The whole document can be applied to both.
> 
> Kireeti: Is there any objection in ITU from letting IETF have this document
> or will
> we dribble out requirements one by one?
> 
> ITU leason: I cannot speak for all ITUT, but we need to socialize this
> within the ITU.
> There is work going on with regard to discovery in ITU 7714 that might need
> to be aligned.
> However, I will try to get discussion going on rapidly.
> 
> Dmitry P:  There may be issues with the way the messages are encoded.
> 
> Kireeti:  We are not talking about discovery; test messages. Documents were
> separated
> so that we can work issues doc-by-doc.  Good to get ruling for each
> document. The
> typical issues with using J0 etc... has rules for how to use this.  Make
> clear that
> that some issues are about before service starts.
> 
> Speaker 5: 7714 issue: if they do the same thing, then why define two
> documents for this?
> 
> Lang: There may be overlap between next document, but not here.
> 
> Speaker 5: Need to be clear about what the overlaps are.
> 
> Lang: Bootstrap document (next doc), the intro describes why the doc exists.
> Prev. document is defined in LMP base document. If you disagree, let me
> know.
> 
> LMP Bootstrap document. See slides for details. This is not WG document.
> Would like
> technical comments on list.
> 
> Dmitri: Could you comment on applicability of incompatibility with other
> documents.
> 
> Lang: The point to make is the information exchanged is the same as that for
> the LMP
> protocol. There is no new information exchanged.
> 
> Kireeti: We need to continue this on the list (ITU input) on how we move
> these documents
> forward.
> 
> Kireeti - CCAMP 55 WG status.
> 
> Kireeti: Is there any problem with sending GMPLS framework to IESG as
> informational.
> 
> Bert: I reviewed this doc a while back, and question is that non-standard
> extensions are
> detailed here. This seems strange to publish a document that suggests a way
> of signaling
> things without a document being somewhere that details the specifics
> somewhere.
> 
> Dmitri: We have been looking for comments RE: pointers/document to fulfill
> your query. I
> think it is unfair to continue without filling these requirements. When I
> sent comments
> on the list, I asked people to provide pointers. If people would like to
> continue, please
> send pointers ASAP.
> 
> Kireeti: As a fallback, what are we going to do if no docs are received.
> 
> Bert: Throw it into the garbage.
> 
> Kireeti: Unless we get pointers, this goes in the can.
> 
> Kireeti: One thing has been asked about is changes to the charter. We want
> to make
> changes to the charter. Please send us suggestions. Few additions:
> inter-area (within AS
> domain),  Protection/restoration, optical VPN.  This will be discussed
> partially during
> SUB-IP meeting, but approval of charter changes come from IESG.
> 
> JPV: Question about the charter. Will signaling between computation server
> and client are
> part of the charter, or do we need to add?
> 
> Kireeti: The current charter does not explicitly have this. This is part of
> the charter
> extensions we are asking for.
> 
> JPV: This can be used in other areas.
> 
> Kireeti: Don't go there. If it is in the charter it is, if not then no. Need
> to make sure
> this is in the charter.
> 
> Ron: I will send out an update on the charter additions (proposed) to the
> mailing list.
> 
> Ashok - Interoperability draft.
> 
> Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> issues for RSVP.
> 
> Bert: These are separate documents. Do this in RSVP.
> 
> Lou:  Spec. requires TSPEC. Lets talk about this offline.
> 
> Kireeti: Okay. I want to talk about some implementation recommendations. How
> are these
> published?
> 
> Bert: Implementation recommendations are fine to either publish as BCP or
> Informational.
> I am worried about the limited set of specifications/issues and that they
> are captured.
> 
> Kireeti: Generic RSVP things are already specified (according to Lou). Lets
> talk about
> this offline to see where changes are required. Define what issues are, how
> are they
> specified. Do this offline.  Should we add recommendations to implementation
> survey as an
> appendix?
> 
> Bert: Whichever.
> 
> Lou: These look like guidelines to implementations. This is usually done
> outside of spec.
> done as BCP/Info.
> 
> Kireeti: Question is where to put it.
> 
> Lou: Seems like this is not a BCP.
> 
> Kireeti: Too early to say that these include "best" practices. Looks
> informational.
> Need to talk with Lou about remaining issues.
> 
> Tom Nadeau did a presentation on the discussions
> regarding the GMPLS MIBs at the Sat MIB Meeting.
> 
> * how Saturday meeting affects the GMPLS MIBs?
> 
> * issues for CCAMP: how to represent SONET (i.e.
> longer) labels
> 
> * proposed solution on label/index given
>   Tom asked for feedback from the working group
>    on this proposed solution
> 
>    type field + octet string
> 
>    goal is to support longer labels
> 
> * Comment by Kireeti to rename
>   Link Bundling MIB to TE-LINK-MIB.
> 
> (No questions on presentation).
> 
> Nadeau: MIB overview presentation
> 
> Dora: MIB discussion. 2 issues.
> 
> Tom: SNMP is just another management interface, and like any other tool, it
> needs to be
> used appropriately. Otherwise, you will have scalability and provisioning
> issues.
> 
> Kireeti: Lets have a discussion on the list for all of these things.
> 
> Bert: Discussion going on in IESG/SNMP community. Been hearing that people
> do not want to
> use SNMP for configuration.   However, I will defer to the WG for guidance
> on this. We
> need discussion on this issue, in particular from operators.
> Kireeti: We should take this to the mailing list.
> 
> Protection/Restoration Team:
> 
> Kireeti: I suggest that you kick off a discussion so that people can pick on
> points that
> might be controversial. We need to do this before we make this a WG
> document.  We need to
> take this into account.
> 
> Dmitri:  We took existing protocols and analysed them.   What I have said is
> a
> consolidation. I think we are fine with the scope. We need to focus on the
> validation.
> 
> Kireeti: We need to make sure there is a consensus on your cut off that it
> was reasonable.
> 
> Bonica: Tunnel trace draft. See slides.  Is the requirements draft ready for
> WG last call.
> 
> Monique:  How is this going to relate to LSP Ping?
> 
> Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is one open
> item: if the
> LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> 
> Kireeti: Are there any comments from anyone else?  The requirements document
> is a WG
> document. Can we have a show of hands for support of GTTP proposed solution
> as WG
> document?  We have a small consensus in favor of this. Go back to mailing
> list to confirm.
> 
> Dmitri: Draft.
> 
> Dmitri: When you increase the scope of what GMPLS may cover. We need to
> handle the
> limited complexity here. This is what we have worked on.   We need to handle
> optical/PSTN.
> 
> Kireeti: Lets not make this a WG document until discussion on the list.
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli
> 
>   ------------------------------------------------------------------------
>                  Name: IETF55.zip
>    IETF55.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>              Encoding: base64

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Sun, 24 Nov 2002 14:46:51 -0800
Date: Sun, 24 Nov 2002 17:26:04 -0500
From: Ron Bonica <[email-masked]>
Subject: IETF 55 - CCAMP Minutes
To: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_sz3LI1uv96w5P7/V3GcWxw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

Folks,

CCAMP WG minutes follow. Slides are attached. Please comment on the minutes
within two weeks so that we can make any required corrections and enter them
into the record.

                                           Ron

P.S. Kireeti's presentation provides a snapshot of WG status. I will make
sure that the ID tracker stays up to date so we will always have a current
picture of WG status.

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

IETF 54 CCAMP Meeting Minutes
==============================

Schedule rearranged due to technical difficulties.....

Kireeti:  Can someone come up here and sing during the break? *)

0935 - 0950
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
                Lang

Provided summary of updates to LMP draft.  See his slides for details.
Thinks we are ready for IESG last call. Summary of updates to LMP WDM draft.
See slides for details. Ready for WG last call.

Bonica: initiate last call on list after meeting.

LMP Test Sonet SDH draft. See slides for details. After changes, we should
solicit
comments from list. We would like a WG last call thereafter. Get a feel from
the room?

Kireeti:  Assuming that J0-64 format is removed, are there any comments?

Bert: The base LMP document was intended for proposed standard. We got
pushback
from ITU people stating that we should not be working on some of this stuff,
so we
split it out to a separate document. Are we intending on prop standard for
this stuff?

Kireeti: Yes, prop. Standards stuff.

Bert: Are we on our proper turf? I would like ITU people to speak up on this
as well
as review it. I don't want discussion during last call, want resolution now.

Speaker 1: Question RE: LMP. After this meeting I intend to start a draft.
After reading LMP specification, I believe it has mandatory configuration.
Are there security considerations.

Lang: Yes, security considerations are mandatory.

Speaker 1: I would like security to be optional.

Bert: Security considerations may not be optional.  We can have some as
optional,
but some mandatory security options are required.

Kireeti: It is mandatory to define security - how to run LMP in a secure
mode.
It is not mandatory to run LMP in a secure mode. Can you?

Lang: That is correct, it can be run un-secure.  Ipsec is defined for LMP.
If you do not want to run IPSec, you can run it without.

Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
consistent with ITU
T.50 requirement. Printable ASCII characters in particular might be an
issue.

Bert: Please pose question to mailing list.

Ron: That way we will have record of conversation.

Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.  Will there
be any
additional alignment with this?

Lang: I think the 7714.1 document is more closely related to bootstrap
document, and
I would lke to discuss this in next part of presentation.

Lyndon: This is now taking LMP and LMP-WDM that are tech specific. Are there
any non-tech
specific things that cannot be applied to both.

Lang: The whole document can be applied to both.

Kireeti: Is there any objection in ITU from letting IETF have this document
or will
we dribble out requirements one by one?

ITU leason: I cannot speak for all ITUT, but we need to socialize this
within the ITU.
There is work going on with regard to discovery in ITU 7714 that might need
to be aligned.
However, I will try to get discussion going on rapidly.

Dmitry P:  There may be issues with the way the messages are encoded.

Kireeti:  We are not talking about discovery; test messages. Documents were
separated
so that we can work issues doc-by-doc.  Good to get ruling for each
document. The
typical issues with using J0 etc... has rules for how to use this.  Make
clear that
that some issues are about before service starts.

Speaker 5: 7714 issue: if they do the same thing, then why define two
documents for this?

Lang: There may be overlap between next document, but not here.

Speaker 5: Need to be clear about what the overlaps are.

Lang: Bootstrap document (next doc), the intro describes why the doc exists.
Prev. document is defined in LMP base document. If you disagree, let me
know.

LMP Bootstrap document. See slides for details. This is not WG document.
Would like
technical comments on list.

Dmitri: Could you comment on applicability of incompatibility with other
documents.

Lang: The point to make is the information exchanged is the same as that for
the LMP
protocol. There is no new information exchanged.

Kireeti: We need to continue this on the list (ITU input) on how we move
these documents
forward.

Kireeti - CCAMP 55 WG status.

Kireeti: Is there any problem with sending GMPLS framework to IESG as
informational.

Bert: I reviewed this doc a while back, and question is that non-standard
extensions are
detailed here. This seems strange to publish a document that suggests a way
of signaling
things without a document being somewhere that details the specifics
somewhere.

Dmitri: We have been looking for comments RE: pointers/document to fulfill
your query. I
think it is unfair to continue without filling these requirements. When I
sent comments
on the list, I asked people to provide pointers. If people would like to
continue, please
send pointers ASAP.

Kireeti: As a fallback, what are we going to do if no docs are received.

Bert: Throw it into the garbage.

Kireeti: Unless we get pointers, this goes in the can.

Kireeti: One thing has been asked about is changes to the charter. We want
to make
changes to the charter. Please send us suggestions. Few additions:
inter-area (within AS
domain),  Protection/restoration, optical VPN.  This will be discussed
partially during
SUB-IP meeting, but approval of charter changes come from IESG.

JPV: Question about the charter. Will signaling between computation server
and client are
part of the charter, or do we need to add?

Kireeti: The current charter does not explicitly have this. This is part of
the charter
extensions we are asking for.

JPV: This can be used in other areas.

Kireeti: Don't go there. If it is in the charter it is, if not then no. Need
to make sure
this is in the charter.

Ron: I will send out an update on the charter additions (proposed) to the
mailing list.

Ashok - Interoperability draft.

Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
issues for RSVP.

Bert: These are separate documents. Do this in RSVP.

Lou:  Spec. requires TSPEC. Lets talk about this offline.

Kireeti: Okay. I want to talk about some implementation recommendations. How
are these
published?

Bert: Implementation recommendations are fine to either publish as BCP or
Informational.
I am worried about the limited set of specifications/issues and that they
are captured.

Kireeti: Generic RSVP things are already specified (according to Lou). Lets
talk about
this offline to see where changes are required. Define what issues are, how
are they
specified. Do this offline.  Should we add recommendations to implementation
survey as an
appendix?

Bert: Whichever.

Lou: These look like guidelines to implementations. This is usually done
outside of spec.
done as BCP/Info.

Kireeti: Question is where to put it.

Lou: Seems like this is not a BCP.

Kireeti: Too early to say that these include "best" practices. Looks
informational.
Need to talk with Lou about remaining issues.

Tom Nadeau did a presentation on the discussions
regarding the GMPLS MIBs at the Sat MIB Meeting.

* how Saturday meeting affects the GMPLS MIBs?

* issues for CCAMP: how to represent SONET (i.e.
longer) labels

* proposed solution on label/index given
  Tom asked for feedback from the working group
   on this proposed solution

   type field + octet string

   goal is to support longer labels

* Comment by Kireeti to rename
  Link Bundling MIB to TE-LINK-MIB.

(No questions on presentation).

Nadeau: MIB overview presentation

Dora: MIB discussion. 2 issues.

Tom: SNMP is just another management interface, and like any other tool, it
needs to be
used appropriately. Otherwise, you will have scalability and provisioning
issues.

Kireeti: Lets have a discussion on the list for all of these things.

Bert: Discussion going on in IESG/SNMP community. Been hearing that people
do not want to
use SNMP for configuration.   However, I will defer to the WG for guidance
on this. We
need discussion on this issue, in particular from operators.
Kireeti: We should take this to the mailing list.

Protection/Restoration Team:

Kireeti: I suggest that you kick off a discussion so that people can pick on
points that
might be controversial. We need to do this before we make this a WG
document.  We need to
take this into account.

Dmitri:  We took existing protocols and analysed them.   What I have said is
a
consolidation. I think we are fine with the scope. We need to focus on the
validation.

Kireeti: We need to make sure there is a consensus on your cut off that it
was reasonable.

Bonica: Tunnel trace draft. See slides.  Is the requirements draft ready for
WG last call.

Monique:  How is this going to relate to LSP Ping?

Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is one open
item: if the
LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.

Kireeti: Are there any comments from anyone else?  The requirements document
is a WG
document. Can we have a show of hands for support of GTTP proposed solution
as WG
document?  We have a small consensus in favor of this. Go back to mailing
list to confirm.

Dmitri: Draft.

Dmitri: When you increase the scope of what GMPLS may cover. We need to
handle the
limited complexity here. This is what we have worked on.   We need to handle
optical/PSTN.

Kireeti: Lets not make this a WG document until discussion on the list.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

--Boundary_(ID_sz3LI1uv96w5P7/V3GcWxw)
Content-type: application/x-zip-compressed; name=IETF55.zip
Content-transfer-encoding: base64
Content-disposition: attachment; filename=IETF55.zip

--Boundary_(ID_sz3LI1uv96w5P7/V3GcWxw)--

Delivery-date: Sun, 24 Nov 2002 14:46:19 -0800
Date: Sun, 24 Nov 2002 17:27:05 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
To: [email-masked]

Folks,

In order to give people time to recover from IETF travel, this last call has
been extended to December 13, 2002.

                                                   Ron

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 11:22 AM
> To: [email-masked]
> Subject: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
>
>
> Folks,
>
> This email begins a WG last call for draft-ietf-ccamp-lmp-wdm-01.
> Last call will end at COB on December 6, 2002.
>
> (We will let the last call run for two weeks to accommodate folks
> who are traveling).
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli

Delivery-date: Thu, 21 Nov 2002 20:26:20 -0800
Date: Thu, 21 Nov 2002 22:22:31 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: John Drake <[email-masked]>
CC: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: Re: J0/J1 encoding issues

John -

I think you forgot what my original message said.  It stated:

> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.

I fail to see what is incorrect with the above.

While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
J0/J1/J2 that fall within the requirements of G.707, it also includes
methods that don't.  This situation SHOULD be resolved to provide the
greatest amount of interoperability while reducing the number of trace
methods that need to be implemented.

I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
only provides methods that fall outside the requirements of G.707.  This
situation MUST be resolved.

Jonathan Sadler

John Drake wrote:
> 
> Wouldn't it be more precise to say that it is an issue with
> draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> draft-ietf-ccamp-lmp-test-sonet-sdh?
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 12:49 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> Therefore, it is an issue.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation, then
> > Jonathan Sadler's issue is a non-issue?
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Lang
> > Sent: Thursday, November 21, 2002 8:56 AM
> > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > 'ccamp '
> > Subject: FW: J0/J1 encoding issues
> >
> > Deborah,
> >   Thanks for the note. The option that Jonathan mentioned is one of a
> couple
> > options we define for Jx. We defined other options to
> > interwork with existing equipment without requiring any changes to
> > existing encodings (this would support both C1 and T.50 requirements).
> > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > Correlation. We welcome additional comments from you and others at
> > T1X1.5/ITU.
> >
> > Thanks,
> > Jonathan
> >
> > -----Original Message-----
> > From: Brungard, Deborah A, ALASO
> > To: [email-masked]; ccamp
> > Sent: 11/21/2002 5:22 AM
> > Subject: RE: J0/J1 encoding issues
> >
> > As Jonathan says, the current G.707 is using T.50. And there's more.
> > Example, for J0, one currently needs to support:
> > - previously defined C1 (repeating one-byte)
> > - T.50 (with format of G.707)
> > - no J0 (for equipment not supporting).
> >
> > So already we have defined multiple applications for this byte. Not to
> > say, there will be not any new ones. Even ITU knows, it never is
> > final;-)
> >
> > For supporting LMP's use, we need to understand the scenarios of use
> > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > inter-operator, applied for equipment installation verification or
> > service connection verification, etc. And hardware implications.
> >
> > Actually, G.831 defines multiple uses depending if inter or intra -
> > including for intra-operator, support of routing/path set-up (and G.831
> > was done years ago).
> >
> > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> > proposal for the meeting and we can start the discussion. The next ITU-T
> > meeting is in January. If the LMP editors need help on our T1X1.5
> > process, just ask.
> >
> > Deborah
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 7:59 PM
> > To: ccamp
> > Subject: J0/J1 encoding issues
> >
> > All -
> >
> > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > have restrictions not only on the length of a trace message and on
> > the bits usable in a octet, but also on whether the payload in the
> > message uses printable ASCII characters.
> >
> > The requirements for J0/J1/J2 (found in G.707) state the trace
> > message payload must utilize the printable characters defined in
> > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > consistant with this requirement.
> >
> > This message is being sent to document this issue.  It is not a
> > statement that no other issues exist -- I expect that the appropriate
> > experts in the ITU will review the rest of these two drafts and
> > provide appropriate comment.
> >
> > Jonathan Sadler

(I disclaim the disclaimer that follows this message.)
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 13:09:24 -0800
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 13:06:54 -0800

Wouldn't it be more precise to say that it is an issue with
draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
draft-ietf-ccamp-lmp-test-sonet-sdh?

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 12:49 PM
To: John Drake
Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
Subject: Re: J0/J1 encoding issues

John -

draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation. 
Therefore, it is an issue.

Jonathan Sadler

John Drake wrote:
> 
> Is it the case that if one chooses to use J0/J1/J2 Trace Correlation, then
> Jonathan Sadler's issue is a non-issue?
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Lang
> Sent: Thursday, November 21, 2002 8:56 AM
> To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> 'ccamp '
> Subject: FW: J0/J1 encoding issues
> 
> Deborah,
>   Thanks for the note. The option that Jonathan mentioned is one of a
couple
> options we define for Jx. We defined other options to
> interwork with existing equipment without requiring any changes to
> existing encodings (this would support both C1 and T.50 requirements).
> These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> Correlation. We welcome additional comments from you and others at
> T1X1.5/ITU.
> 
> Thanks,
> Jonathan
> 
> -----Original Message-----
> From: Brungard, Deborah A, ALASO
> To: [email-masked]; ccamp
> Sent: 11/21/2002 5:22 AM
> Subject: RE: J0/J1 encoding issues
> 
> As Jonathan says, the current G.707 is using T.50. And there's more.
> Example, for J0, one currently needs to support:
> - previously defined C1 (repeating one-byte)
> - T.50 (with format of G.707)
> - no J0 (for equipment not supporting).
> 
> So already we have defined multiple applications for this byte. Not to
> say, there will be not any new ones. Even ITU knows, it never is
> final;-)
> 
> For supporting LMP's use, we need to understand the scenarios of use
> (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> inter-operator, applied for equipment installation verification or
> service connection verification, etc. And hardware implications.
> 
> Actually, G.831 defines multiple uses depending if inter or intra -
> including for intra-operator, support of routing/path set-up (and G.831
> was done years ago).
> 
> Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> proposal for the meeting and we can start the discussion. The next ITU-T
> meeting is in January. If the LMP editors need help on our T1X1.5
> process, just ask.
> 
> Deborah
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 7:59 PM
> To: ccamp
> Subject: J0/J1 encoding issues
> 
> All -
> 
> As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> have restrictions not only on the length of a trace message and on
> the bits usable in a octet, but also on whether the payload in the
> message uses printable ASCII characters.
> 
> The requirements for J0/J1/J2 (found in G.707) state the trace
> message payload must utilize the printable characters defined in
> T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> consistant with this requirement.
> 
> This message is being sent to document this issue.  It is not a
> statement that no other issues exist -- I expect that the appropriate
> experts in the ITU will review the rest of these two drafts and
> provide appropriate comment.
> 
> Jonathan Sadler
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 12:52:05 -0800
Date: Thu, 21 Nov 2002 14:48:36 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: John Drake <[email-masked]>
CC: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: Re: J0/J1 encoding issues

John -

draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation. 
Therefore, it is an issue.

Jonathan Sadler

John Drake wrote:
> 
> Is it the case that if one chooses to use J0/J1/J2 Trace Correlation, then
> Jonathan Sadler's issue is a non-issue?
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Lang
> Sent: Thursday, November 21, 2002 8:56 AM
> To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> 'ccamp '
> Subject: FW: J0/J1 encoding issues
> 
> Deborah,
>   Thanks for the note. The option that Jonathan mentioned is one of a couple
> options we define for Jx. We defined other options to
> interwork with existing equipment without requiring any changes to
> existing encodings (this would support both C1 and T.50 requirements).
> These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> Correlation. We welcome additional comments from you and others at
> T1X1.5/ITU.
> 
> Thanks,
> Jonathan
> 
> -----Original Message-----
> From: Brungard, Deborah A, ALASO
> To: [email-masked]; ccamp
> Sent: 11/21/2002 5:22 AM
> Subject: RE: J0/J1 encoding issues
> 
> As Jonathan says, the current G.707 is using T.50. And there's more.
> Example, for J0, one currently needs to support:
> - previously defined C1 (repeating one-byte)
> - T.50 (with format of G.707)
> - no J0 (for equipment not supporting).
> 
> So already we have defined multiple applications for this byte. Not to
> say, there will be not any new ones. Even ITU knows, it never is
> final;-)
> 
> For supporting LMP's use, we need to understand the scenarios of use
> (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> inter-operator, applied for equipment installation verification or
> service connection verification, etc. And hardware implications.
> 
> Actually, G.831 defines multiple uses depending if inter or intra -
> including for intra-operator, support of routing/path set-up (and G.831
> was done years ago).
> 
> Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
> proposal for the meeting and we can start the discussion. The next ITU-T
> meeting is in January. If the LMP editors need help on our T1X1.5
> process, just ask.
> 
> Deborah
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 7:59 PM
> To: ccamp
> Subject: J0/J1 encoding issues
> 
> All -
> 
> As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> have restrictions not only on the length of a trace message and on
> the bits usable in a octet, but also on whether the payload in the
> message uses printable ASCII characters.
> 
> The requirements for J0/J1/J2 (found in G.707) state the trace
> message payload must utilize the printable characters defined in
> T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> consistant with this requirement.
> 
> This message is being sent to document this issue.  It is not a
> statement that no other issues exist -- I expect that the appropriate
> experts in the ITU will review the rest of these two drafts and
> provide appropriate comment.
> 
> Jonathan Sadler
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 11:28:26 -0800
From: Jonathan Lang <[email-masked]>
To: John Drake <[email-masked]>, "''Brungard, Deborah A, ALASO ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, ''ccamp ' ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 11:25:12 -0800

yes.

-Jonathan 

-----Original Message-----
From: John Drake
To: Jonathan Lang; 'Brungard, Deborah A, ALASO ';
[email-masked] '; 'ccamp '
Sent: 11/21/2002 10:19 AM
Subject: RE: J0/J1 encoding issues

Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
then Jonathan Sadler's issue is a non-issue?

Thanks,

John

-----Original Message-----
From: Jonathan Lang 
Sent: Thursday, November 21, 2002 8:56 AM
To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
'ccamp '
Subject: FW: J0/J1 encoding issues

Deborah,
  Thanks for the note. The option that Jonathan mentioned is one of a
couple
options we define for Jx. We defined other options to
interwork with existing equipment without requiring any changes to
existing encodings (this would support both C1 and T.50 requirements).
These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
Correlation. We welcome additional comments from you and others at
T1X1.5/ITU.

Thanks,
Jonathan

-----Original Message-----
From: Brungard, Deborah A, ALASO
To: [email-masked]; ccamp
Sent: 11/21/2002 5:22 AM
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to
say, there will be not any new ones. Even ITU knows, it never is
final;-)

For supporting LMP's use, we need to understand the scenarios of use
(sounds familiar to T1X1.5 participants?) e.g. intra-operator,
inter-operator, applied for equipment installation verification or
service connection verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831
was done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5
process, just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 10:21:35 -0800
From: John Drake <[email-masked]>
To: Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "[email-masked] '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 10:19:02 -0800

Is it the case that if one chooses to use J0/J1/J2 Trace Correlation, then
Jonathan Sadler's issue is a non-issue?

Thanks,

John

-----Original Message-----
From: Jonathan Lang 
Sent: Thursday, November 21, 2002 8:56 AM
To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
'ccamp '
Subject: FW: J0/J1 encoding issues

Deborah,
  Thanks for the note. The option that Jonathan mentioned is one of a couple
options we define for Jx. We defined other options to
interwork with existing equipment without requiring any changes to
existing encodings (this would support both C1 and T.50 requirements).
These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
Correlation. We welcome additional comments from you and others at
T1X1.5/ITU.

Thanks,
Jonathan

-----Original Message-----
From: Brungard, Deborah A, ALASO
To: [email-masked]; ccamp
Sent: 11/21/2002 5:22 AM
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to
say, there will be not any new ones. Even ITU knows, it never is
final;-)

For supporting LMP's use, we need to understand the scenarios of use
(sounds familiar to T1X1.5 participants?) e.g. intra-operator,
inter-operator, applied for equipment installation verification or
service connection verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831
was done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5
process, just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 09:02:01 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'Bala Rajagopalan'" <[email-masked]>, "'Brungard, Deborah A, ALASO'" <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 09:00:48 -0800

Hi Bala, the proposed encoding in the current G.7714.1 took into account:
(1)The old OIF contributions
(2)The need for different formats assuming different control plane address
types
(3)A bit closer reading of the ITU specs.

What it didn't include was the "cross layer" discovery concept that was in
the older OIF contributions.  This material is somewhat subsummed in the
"test signal" method for discovery.

Greg B.

-----------------------
New e-mail as of December 2nd: [email-masked]

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:32 AM
To: Bernstein, Greg; 'Brungard, Deborah A, ALASO';
[email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

Hi,

My question though is w.r.t the encoding carried
in J0. There was a specific T.50 based encoding
proposed in OIF a while ago. Now, there is a different
encoding specified in G.7714. Which one of these
should be followed and why?

Regards,

Bala 
-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 10:56 AM
To: 'Bala Rajagopalan'; 'Brungard, Deborah A, ALASO';
[email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

Hi Bala if you really dig hard through the ITU-T specs you'll see that the
use of Jx traces is for "connectivity supervision".  Both understanding
where a particular signal came from and keeping an eye on it to make sure it
hasn't changed, i.e., a misconnection.

Hence, the intent is very similar to discovery but the content was not
standardized.  By staying within the general guidelines contained in G.707
(the SDH specification) then existing as well as new equipment can take
advantage of this functionality.  For example with a legacy ADM I could set
and receive these J0 strings via TL1 commands then run the rest of my
optical control plane "off the box".

Greg B.

----------------------------------------------------------
New E-mail as of December 2nd: [email-masked]

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 7:38 AM
To: 'Brungard, Deborah A, ALASO'; [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

It is not clear reading any of the docs
(including G.7714) what the actual practice is
currently w.r.t J0 usage. Also, it's not
clear how discovery, a new capability, relates
to existing equipment, i.e., is it possible
to implement this feature in legacy equipment that 
reads J0 in specific ways? Or, are we talking
essentially about next generation equipment
in which case we may have some lattitude on how
to interpret J0? Some clarification on this
would be appreciated.

Bala

-----Original Message-----
From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 AM
To: [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to say,
there will be not any new ones. Even ITU knows, it never is final;-)

For supporting LMP's use, we need to understand the scenarios of use (sounds
familiar to T1X1.5 participants?) e.g. intra-operator, inter-operator,
applied for equipment installation verification or service connection
verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831 was
done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5 process,
just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 08:59:08 -0800
From: Jonathan Lang <[email-masked]>
To: "'Brungard, Deborah A, ALASO '" <[email-masked]>,  "[email-masked] '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: FW: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 08:56:27 -0800

Deborah,
  Thanks for the note. The option that Jonathan mentioned is one of a couple
options we define for Jx. We defined other options to
interwork with existing equipment without requiring any changes to
existing encodings (this would support both C1 and T.50 requirements).
These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
Correlation. We welcome additional comments from you and others at
T1X1.5/ITU.

Thanks,
Jonathan

-----Original Message-----
From: Brungard, Deborah A, ALASO
To: [email-masked]; ccamp
Sent: 11/21/2002 5:22 AM
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to
say, there will be not any new ones. Even ITU knows, it never is
final;-)

For supporting LMP's use, we need to understand the scenarios of use
(sounds familiar to T1X1.5 participants?) e.g. intra-operator,
inter-operator, applied for equipment installation verification or
service connection verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831
was done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5
process, just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 08:40:31 -0800
Date: Thu, 21 Nov 2002 11:21:33 -0500
From: Ron Bonica <[email-masked]>
Subject: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
To: [email-masked]

Folks,

This email begins a WG last call for draft-ietf-ccamp-lmp-wdm-01. Last call
will end at COB on December 6, 2002.

(We will let the last call run for two weeks to accommodate folks who are
traveling).

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Thu, 21 Nov 2002 08:35:48 -0800
From: Bala Rajagopalan <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "'Brungard, Deborah A, ALASO'" <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 11:32:03 -0500

Hi,

My question though is w.r.t the encoding carried
in J0. There was a specific T.50 based encoding
proposed in OIF a while ago. Now, there is a different
encoding specified in G.7714. Which one of these
should be followed and why?

Regards,

Bala 
-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 10:56 AM
To: 'Bala Rajagopalan'; 'Brungard, Deborah A, ALASO';
[email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

Hi Bala if you really dig hard through the ITU-T specs you'll see that the
use of Jx traces is for "connectivity supervision".  Both understanding
where a particular signal came from and keeping an eye on it to make sure it
hasn't changed, i.e., a misconnection.

Hence, the intent is very similar to discovery but the content was not
standardized.  By staying within the general guidelines contained in G.707
(the SDH specification) then existing as well as new equipment can take
advantage of this functionality.  For example with a legacy ADM I could set
and receive these J0 strings via TL1 commands then run the rest of my
optical control plane "off the box".

Greg B.

----------------------------------------------------------
New E-mail as of December 2nd: [email-masked]

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 7:38 AM
To: 'Brungard, Deborah A, ALASO'; [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

It is not clear reading any of the docs
(including G.7714) what the actual practice is
currently w.r.t J0 usage. Also, it's not
clear how discovery, a new capability, relates
to existing equipment, i.e., is it possible
to implement this feature in legacy equipment that 
reads J0 in specific ways? Or, are we talking
essentially about next generation equipment
in which case we may have some lattitude on how
to interpret J0? Some clarification on this
would be appreciated.

Bala

-----Original Message-----
From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 AM
To: [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to say,
there will be not any new ones. Even ITU knows, it never is final;-)

For supporting LMP's use, we need to understand the scenarios of use (sounds
familiar to T1X1.5 participants?) e.g. intra-operator, inter-operator,
applied for equipment installation verification or service connection
verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831 was
done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5 process,
just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 07:58:35 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'Bala Rajagopalan'" <[email-masked]>, "'Brungard, Deborah A, ALASO'" <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 07:56:17 -0800

Hi Bala if you really dig hard through the ITU-T specs you'll see that the
use of Jx traces is for "connectivity supervision".  Both understanding
where a particular signal came from and keeping an eye on it to make sure it
hasn't changed, i.e., a misconnection.

Hence, the intent is very similar to discovery but the content was not
standardized.  By staying within the general guidelines contained in G.707
(the SDH specification) then existing as well as new equipment can take
advantage of this functionality.  For example with a legacy ADM I could set
and receive these J0 strings via TL1 commands then run the rest of my
optical control plane "off the box".

Greg B.

----------------------------------------------------------
New E-mail as of December 2nd: [email-masked]

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 7:38 AM
To: 'Brungard, Deborah A, ALASO'; [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

It is not clear reading any of the docs
(including G.7714) what the actual practice is
currently w.r.t J0 usage. Also, it's not
clear how discovery, a new capability, relates
to existing equipment, i.e., is it possible
to implement this feature in legacy equipment that 
reads J0 in specific ways? Or, are we talking
essentially about next generation equipment
in which case we may have some lattitude on how
to interpret J0? Some clarification on this
would be appreciated.

Bala

-----Original Message-----
From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 AM
To: [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to say,
there will be not any new ones. Even ITU knows, it never is final;-)

For supporting LMP's use, we need to understand the scenarios of use (sounds
familiar to T1X1.5 participants?) e.g. intra-operator, inter-operator,
applied for equipment installation verification or service connection
verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831 was
done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5 process,
just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 07:43:32 -0800
From: Bala Rajagopalan <[email-masked]>
To: "'Brungard, Deborah A, ALASO'" <[email-masked]>,  [email-masked], ccamp <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 10:38:04 -0500

It is not clear reading any of the docs
(including G.7714) what the actual practice is
currently w.r.t J0 usage. Also, it's not
clear how discovery, a new capability, relates
to existing equipment, i.e., is it possible
to implement this feature in legacy equipment that 
reads J0 in specific ways? Or, are we talking
essentially about next generation equipment
in which case we may have some lattitude on how
to interpret J0? Some clarification on this
would be appreciated.

Bala

-----Original Message-----
From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 8:23 AM
To: [email-masked]; ccamp
Subject: RE: J0/J1 encoding issues

As Jonathan says, the current G.707 is using T.50. And there's more.
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to say,
there will be not any new ones. Even ITU knows, it never is final;-)

For supporting LMP's use, we need to understand the scenarios of use (sounds
familiar to T1X1.5 participants?) e.g. intra-operator, inter-operator,
applied for equipment installation verification or service connection
verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra -
including for intra-operator, support of routing/path set-up (and G.831 was
done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the
proposal for the meeting and we can start the discussion. The next ITU-T
meeting is in January. If the LMP editors need help on our T1X1.5 process,
just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 21 Nov 2002 05:27:35 -0800
content-class: urn:content-classes:message
Subject: RE: J0/J1 encoding issues
Date: Thu, 21 Nov 2002 08:22:59 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: <[email-masked]>, "ccamp" <[email-masked]>

As Jonathan says, the current G.707 is using T.50. And there's more. =
Example, for J0, one currently needs to support:
- previously defined C1 (repeating one-byte)
- T.50 (with format of G.707)
- no J0 (for equipment not supporting).

So already we have defined multiple applications for this byte. Not to =
say, there will be not any new ones. Even ITU knows, it never is =
final;-)

For supporting LMP's use, we need to understand the scenarios of use =
(sounds familiar to T1X1.5 participants?) e.g. intra-operator, =
inter-operator, applied for equipment installation verification or =
service connection verification, etc. And hardware implications.

Actually, G.831 defines multiple uses depending if inter or intra - =
including for intra-operator, support of routing/path set-up (and G.831 =
was done years ago).

Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute the =
proposal for the meeting and we can start the discussion. The next ITU-T =
meeting is in January. If the LMP editors need help on our T1X1.5 =
process, just ask.

Deborah

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:59 PM
To: ccamp
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
=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=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged=20
and confidential and protected from disclosure.  If the=20
reader of this message is not the intended recipient, or an=20
employee or agent responsible for delivering this message to=20
the intended recipient, you are hereby notified that any=20
reproduction, dissemination or distribution of this=20
communication is strictly prohibited. If you have received=20
this communication in error, please notify us immediately by=20
replying to the message and deleting it from your computer.

Thank you.
Tellabs
=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=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Delivery-date: Tue, 19 Nov 2002 08:29:35 -0800
Date: Tue, 19 Nov 2002 11:24:36 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Question on ResvConf from CCAMP WG

All,
	My understanding of the issue raised the "ResvConf" issue raised in this 
morning's session is that it's not clear to some what is meant by "...a 
ResvConf message is forwarded to the receiver hop-by-hop, to accommodate 
the hop-by-hop integrity check mechanism."  [RFC2205].  RFC2205 is 
consistent in it's usage of hop-by-hop to mean from rsvp-aware node to 
rsvp-aware node, so an informed read should not need any further clarification.

Just to be absolutely clear, we can make an editorial change to GMPLS-RSVP, 
if the group/chairs/ADs agree.  Specifically we can add ResvConf to section 
10.2, i.e.:

10.2 Addressing Path, PathTear and ResvConf Messages

RSVP was designed to handle dynamic (non-explicit) path changes and non 
RSVP hops along the path.  To this end, the Path, PathTear and ResvConf 
messages carry the destination address of the session in the IP header.  In 
generalized signaling, routes are usually explicitly signaled.  Further, 
hops that cannot allocate labels cannot exist in the path of an LSP.  A 
further difference with traditional RSVP is that at times, an RSVP message 
may travel out of band with respect to an LSP's data channel.

When a node is sending a Path, PathTear or ResvConf message to a node that 
it knows to be adjacent at the data plane (i.e. along the path of the LSP) 
it SHOULD address the message directly to  an address associated with the 
adjacent node's control plane. In this case the router-alert option SHOULD 
not be included.

Lou

Delivery-date: Mon, 18 Nov 2002 17:01:38 -0800
Date: Mon, 18 Nov 2002 18:58:44 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: ccamp <[email-masked]>
Subject: J0/J1 encoding issues

All -

As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
have restrictions not only on the length of a trace message and on
the bits usable in a octet, but also on whether the payload in the
message uses printable ASCII characters.

The requirements for J0/J1/J2 (found in G.707) state the trace
message payload must utilize the printable characters defined in
T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
consistant with this requirement.

This message is being sent to document this issue.  It is not a
statement that no other issues exist -- I expect that the appropriate
experts in the ITU will review the rest of these two drafts and
provide appropriate comment.

Jonathan Sadler
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Mon, 18 Nov 2002 14:37:50 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Bala Rajagopalan <[email-masked]>, "'Lin, Zhi-Wei (Zhi)'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Location of ITU-T Information
Date: Mon, 18 Nov 2002 23:35:20 +0100

Bala, if these assignments are indeed needed by Jan for ITU,
then you better hurry. There is the holiday season and all that
and that does not help to move things fast.

Thanks,
Bert 

> -----Original Message-----
> From: Bala Rajagopalan [mailto:[email-masked]]
> Sent: maandag 18 november 2002 21:53
> To: 'Lin, Zhi-Wei (Zhi)'; Stephen Trowbridge; ccamp
> Subject: RE: Location of ITU-T Information
> 
> 
> hello,
> 
> The IESG has requested some (mostly editorial) changes in the draft
> towards publication as an informational RFC. I'll hopefully be able
> to submit a revised draft soon.
> 
> Regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Pl.
> Ocean Port, NJ 07757
> USA
> Ph: +1-732-923-4237
> Email: [email-masked]
> 
> 
> > -----Original Message-----
> > From: Lin, Zhi-Wei (Zhi) [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 10:45 AM
> > To: Stephen Trowbridge; ccamp
> > Subject: RE: Location of ITU-T Information
> > 
> > 
> > Hi Steve,
> > 
> > There is another document that will be needed for the ITU-T 
> > work. This is the I-D that Bala has posted and submitted for 
> > informational RFC status:
> > 
> > draft-bala-uni-ldp-rsvp-extensions-02.txt
> > 
> > I'm not sure where in the process this document is, so 
> > hopefully Bala can comment.
> > 
> > Thanks
> > Zhi
> > 
> > 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Monday, November 18, 2002 10:10 AM
> > To: ccamp
> > Subject: Location of ITU-T Information
> > 
> > 
> > All,
> > From this morning's presentation:
> > 
> > For access to incoming liaisons to IETF:
> > http://www.ietf.org/IESG/liaison.html 
> > 
> > For access to specific communications to external 
> > organizaitons from ITU-T Study Group 15:
> > ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> /COMMUNICATIONS/index.html
> 
> On this page, select the link for IETF-ccamp, acknowledge the ITU-T
> copyright, and
> you will see a list of all communications sent from ITU-T 
> Study Group 15 to
> ccamp
> during this study period (2001-2004).
> 
> For the recent communication, select the link for "Signaling 
> Protocol work
> in Q.14/15"
> dated 11 October 2002. This communication has links from which you can
> download the
> current draft Recommendations G.7713.2 and G.7713.3. These 
> documents are
> planned for
> consent at the 20-31 January 2003 Study Group 15 meeting.
> 
> Prerequisites for approval of these documents include:
> Publication of base GMPLS documents for normative references:
> draft-ietf-mpls-generalized-signaling-09.txt
> draft-ietf-mpls-generalized-cr-ldp-07.txt
> draft-ietf-mpls-generalized-rsvp-te-09.txt
> 
> IANA code point assignments for ASON extensions to rsvp-te and cr-ldp.
> Information
> is captured in documents proposed for informational RFCs to 
> expedite these
> assignments:
> draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
> draft-aboulmagd-ccamp-crldp-ason-ext-01.txt
> 
> Regards,
> Steve Trowbridge
> 

Delivery-date: Mon, 18 Nov 2002 12:55:29 -0800
From: Bala Rajagopalan <[email-masked]>
To: "'Lin, Zhi-Wei (Zhi)'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Location of ITU-T Information
Date: Mon, 18 Nov 2002 15:52:39 -0500

hello,

The IESG has requested some (mostly editorial) changes in the draft
towards publication as an informational RFC. I'll hopefully be able
to submit a revised draft soon.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: Lin, Zhi-Wei (Zhi) [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 10:45 AM
> To: Stephen Trowbridge; ccamp
> Subject: RE: Location of ITU-T Information
> 
> 
> Hi Steve,
> 
> There is another document that will be needed for the ITU-T 
> work. This is the I-D that Bala has posted and submitted for 
> informational RFC status:
> 
> draft-bala-uni-ldp-rsvp-extensions-02.txt
> 
> I'm not sure where in the process this document is, so 
> hopefully Bala can comment.
> 
> Thanks
> Zhi
> 
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 10:10 AM
> To: ccamp
> Subject: Location of ITU-T Information
> 
> 
> All,
> From this morning's presentation:
> 
> For access to incoming liaisons to IETF:
> http://www.ietf.org/IESG/liaison.html 
> 
> For access to specific communications to external 
> organizaitons from ITU-T Study Group 15:
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
/COMMUNICATIONS/index.html

On this page, select the link for IETF-ccamp, acknowledge the ITU-T
copyright, and
you will see a list of all communications sent from ITU-T Study Group 15 to
ccamp
during this study period (2001-2004).

For the recent communication, select the link for "Signaling Protocol work
in Q.14/15"
dated 11 October 2002. This communication has links from which you can
download the
current draft Recommendations G.7713.2 and G.7713.3. These documents are
planned for
consent at the 20-31 January 2003 Study Group 15 meeting.

Prerequisites for approval of these documents include:
Publication of base GMPLS documents for normative references:
draft-ietf-mpls-generalized-signaling-09.txt
draft-ietf-mpls-generalized-cr-ldp-07.txt
draft-ietf-mpls-generalized-rsvp-te-09.txt

IANA code point assignments for ASON extensions to rsvp-te and cr-ldp.
Information
is captured in documents proposed for informational RFCs to expedite these
assignments:
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
draft-aboulmagd-ccamp-crldp-ason-ext-01.txt

Regards,
Steve Trowbridge

Delivery-date: Mon, 18 Nov 2002 11:23:08 -0800
From: "Adrian Farrel" <[email-masked]>
To: "Bradford, Richard" <[email-masked]>
Cc: <[email-masked]>
Subject: Comments on draft-rbradfor-ccamp-lmp-lol-00.txt
Date: Mon, 18 Nov 2002 14:21:14 -0500

This is a multi-part message in MIME format.

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

Richard,
This looks like a useful draft.

I have a few comments and nits in line (look for >>).
Please let me know if you'd like me to clarify any of my points or =
provide text.

Cheers,
Adrian

CCAMP Working Group                    Richard Bradford
Internet Draft                    Dimitri Papadimitriou
Expires: April 2003                          Dan Tappan
                                           October 2002

    LMP Extensions for Link discovery Using Loss of Light
>> I think you'll get asked to expand the acronym in the title

              draft-rbradfor-ccamp-lmp-lol-00.txt

[SNIP]
Abstract

   This document proposes an enhanced mechanism for LMP link

>> I think you'll get asked to expand the acronym in the abstract

   verification that is independent of the data encoding

>> need to say that this is for use in verifying optical links

   type.  The general proposal is to use the transmission of
   light by the sender and recognition of the presence or
   absence of light by the receiver to identify port
   mapping.  The proposal includes minor extensions to the
   existing messages to implement this extension to the link
   verification procedure.

Bradford et al                                               [Page 1]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

1. Introduction

>> I'd suggest that section 1 is too long and the bulk of the
   text should be moved to a new "Overview" section between
   the current sections 2 and 3

   Optical networks are being developed to include optical
   cross-connects, routers and DWDMs that are configured
   with control channels and data links.  LMP was created to
   provide, among other features, link discovery between

>> and link verification

   these devices.  Currently, LMP requires the ability to
   terminate data in these links in order to perform this
   link discovery. Many of these devices, such as DWDMs, do
   not currently have these capabilities and the addition of
   these capabilities could be expensive or even technically
   unfeasible.  This memo defines extensions to the LMP Link
   Verification Procedure to allow neighbors to determine
   their interface mappings using the presence and absence
   (a.k.a loss of light or LoL)loss of light on those

>> /re-write
   Verification Procedure to allow neighbors to determine
   their interface mappings using the presence or absence
   of received light on those
>> /re-write off

   interfaces, a capability that is simpler, does not
   require optical/electrical conversion cheaper, and is

>> add ", is"
   require optical/electrical conversion, is cheaper, and is

   within the existing functional requirements of many of
   these devices.  A common name for the signal indicating
   presence and absence of light is Loss-of-Light, (LOL), so
   that name is used throughout this document.  The proposed
   mechanism provides a more scalable solution than the
   existing link verification mechanisms.

1.1.  Current Limitations

   [LMP] Link Verification requires optical devices to
   provide link termination of each port and provides a wide
   variety of transport mechanisms for possible termination.
   This requirement leads to several challengeshe LMP link

>> typo
   This requirement leads to several challenges. The LMP link

   termination requirement prevents adoption on devices
   which do not already electrically terminate links and
   presents difficult engineering challenges for
   incorporation in many other devices. Another limitation
   is the scalability of the current link verification
   procedure. These are discussed in detail below.

1.1.1 Link Termination.  Issues
   This section raises issues of possible additional
   complexity, performance impacts, reliability impacts
   and potentially prohibitive cost issues which could
   limit the applicability of LMP for certain devices. Many
   of the issues are implementation specific and not all
   issues affect all types of optical devices.

   1)  First, X-transparent devices have no reason, other than

>> do you need to explain x-transparent and X-aspect?

     supporting LMP link verification, to terminate the X-aspect
     of the data link. Support for such termination can greatly
     increase the complexity, and cost, and power consumption of
     some devices and the additional components could affect such
     important aspects of a device as MTBF. A DWDM that is

Bradford et al                                               [Page 2]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
     electrically transparent, for example, would need to add the

>> do you mean "optically" transparent?

     ability to switch every port between its operational pass-
     through mode and its termination mode.

   2)  Second, the addition of link termination can increase
     the signal loss through certain devices even when the link
     is not terminated, due to the additional switching
     requirement. An example of this is a DWDM, which normally
     does not need to switch the incoming light to an internal
     termination module. While this is very implementation
     dependent, the ability to losslessly add this cabability

>> typo
   "capability"

     could present a roadblock to support for link verification.
   3) Third, an electrically transparent OXC would need to add
     one or more termination modules and could and would lose the
     switching capacity required for those termination modules
     (e.g. a 16x16 port fabric mightwould need to have at least

>> "mightwould" :-)

     one of those ports connected to the link termination module,
     preventing its connection to an external interface).
   4) Fourth, is the problem of supporting the "right" set of
     termination capabilities. For example, a electrically

>> "an" electrically
   but, again, do you mean optically transparent?
   Actually, I think you mean that the data plane is transparent
   to the control plane. That is, the control plane cannot=20
   extract packets or overhead information from the data plane.
   This is a superset of optically transparent.  =20

     transparent switch may be able to support connections
     carrying SONET or Gigabit Ethernet. In addition, that switch
     may be able to switch wavelengths, which are carrying
     anything from OC483 through OC768 and beyond. It would be
     costly and difficult to provide termination capabilities for
     even a small subset of these transport mechanisms.

1.1.2 Link Verification Scalability

   1)  In addition to the above, the many of theexisting

>> typo "the existing"

     mechanisms for LMP LV calls for the link verification
     initiator to send in-band messages from each port. If the
     link-verification target switch is incapable of
     simultaneously terminating all its ports, it must then cycle
     through termination of its ports to find the interface
     connected to each source. This does not scale well for large
     switches. If a group of 512 port OXCs is connected together,
     then each target switch will need to cycle through an
     average of 256 ports before finding its mate. This requires
     an average of 131,072 (256x512) combinations to try, a large
     number, especially if the combinations must be tested
     serially(i.e. one termination at a time).

>> FWIW the average is less than this for point-to-point connectivity
   in stable systems because you don't need to scan ports that are
   already known to be connected

   The solution proposed in this document limits the
   excessive link termination costs, both in terms of added
   hardware and the potentially increased reduce optical
   lossbudgets to support that hardware. It also provides a
   mechanism that scales much better for large numbers of
   interconnects.

Bradford et al                                               [Page 3]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
1.2.  Proposed Solution Overview and Benefits.

   The solution must address the issue of link termination
   compatibility as well as the scalability limitation of
   the existing LMP link verification procedure.

   The ability to switch light on for the transmit side of
   an interface and the ability to detect the presence of
   light on the receive side of an interface is already
   present in many optical devices, regardless of the
   optical encoding mechanisms used. A link verification
   mechanism based on LOL puts a minimal requirement on an
   interface and provides universal compatibility.

   For scalability, the enhanced procedure allows testing of
   all ports in parallel and without terminating the line.
   This avoids the limitation of testing ports serially,
   which requires terminating one source port at a time,
   then the destination will need to terminate a line, wait
   some interval which is greater than the inter-message
   arrival time, and move to the next. This requires the
   source to send on the order of n-squared messages. The
   method described in this document reduces this to a
   number on the order of ln(n) for large numbers of
   interconnects. Note that the scalability problem is only
   an issue for devices which cannot terminate multiple
   ports simultaneously.

   Here is an overview of the procedure. For brevity, the
   initiator of link verification will be referred to as LV-
   src and the destination node accepting the link
   verification request will be referred to as LV-dst.

>> You need to clarify "pattern". I think you should say
   something like...
   The LV-Src may set some of its ports to transmit light
   and others to not transmit light. Given a well-known
   ordering of ports, the ports may be represented as a
   bit sequence with a zero bit representing no light and
   a one representing a port transmitting light. The
   resultant bit sequence represents the 'pattern' of
   enabled interfaces.
>> /end suggested text

   LV-Src sets the interfaces it is verifying to emit light
   in a particular pattern and then sends that pattern to LV-
   Dst over the control channel. LV-Dst looks for light on
   all its available interfaces and reports back over the
   control channel. Initially every one of LV-dst's
   interfaces can be "possibly-connected" to all of LV-src's
   interfaces, since no possibilities have yet been
   eliminated. However, each time LV-Src changes the
   combination light on its interfaces, some of LV-dst's
   interfaces will not see the corresponding change, and
   connectivity between those two ports will be eliminated
   as a possibility.

>> I would suggest moving all example material out to a new section
   at the end of the draft. I don't think that you need to give the
   comparison with port-by-port scalability again - you have already
   covered this.

   Using this mechanism, the port connectivity can be
   established through a series of interface/light-emission
   patterns. For an eight port example, the pattern 0xF0,
   0x0F, 0xCC, and 0xAA, would be more than sufficient to
   provide the mapping of eight ports to eight ports. These
   4 messages will actually each require an acknowledgement,
   totaling 8 messages. To verify eight-port connectivity

Bradford et al                                               [Page 4]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

   using the existing LMP Link verification procedure
   requires the source to terminate each source port in
   turn. For each source port, the destination must
   terminate each potential destination until a test message
   is received. On average, half the ports will need to be
   tested before discovering the right one. This requires a
   minimum of 8*4=3D 32 test messages, on average, and
   probably many more, perhaps 64, since port termination
   and waiting for a packet will typically require waiting
   for more than a single packet transmission interval. For
   eight ports, the number of test messages is reduced from
   between 32 and 63 messages, to just 8. For 64 ports, this
   method reduces the number of test messages from
   (64*63)/2=3D2016 (or twice that), to 6+2=3D8 (or 16 including
   acknowledgments..

   Once LV-Src has completed its entire pattern, LV-Dst will
   report which interfaces, if any, map to its local
   interfaces.

   The pattern of lights emissions must cause each interface
   to change and must uniquely differentiate between all the
   ports. The algorithm used in the above sequences is as
   follows. For N ports. Pattern 1 =3D first N/2 ports on,
   second N/2 ports off. Pattern 2 =3D First N/2 ports off
   second N/2 on. Patterns 3-maximium, (where M=3D pattern #)
   =3D Alternate on and off in groups of N/(2**(M-1)).

>> You should stress that this is an example, but that the
   behavior is entirely an implementation matter for the
   LV-Src.

2. Terminology

   This document uses terminology from the MPLS architecture
   document [MPLSArch] and the LMP Draft [LMP].

>> if you move the bulk of the text in section 1 downwards, you=20
   can add terminology for 'pattern' and for 'transparent'.

3. Link Verification Extensions.

   The following extensions are needed to support this
   method of Link Verification:

     .  A new flag is defined to identify LOL in the Verify
        Transport Mechanism field of the BEGIN_VERIFY object and the
        Verify Transport Response field of the BEGIN_VERIFY_ACK
        object. This field is defined across all LSP encoding types
        and does not interfere with specification of the existing
        transport mechanisms.
     .  Extension of the Test Message to include the LOL Status.
     .  Extension of the TestStatusSuccess message, which is
        similar to the modified Test Message.

>> "similar"? :-)=20
   see my note in message format below
   there is an asymmetry between the messages

     .  Addition of a LOL_TEST_STATUS Object.
>> Assume this is the object included in the previous two bullets?

Bradford et al                                               [Page 5]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

3.1.  LOL Link Verification Walkthrough

   Here is a walkthrough of the procedure.  LV-src sends a
   BeginVerify message indicating LOL as the transport
   mechanism.  LV-dst responds with a BeginVerifyAck
   message, selecting LOL as the transport mechanism.

   LV-src sets its interfaces to emit light in pattern 1.
   For example, where 8 ports are being verified, and where
   a one represents "transmit light", the pattern of light
   emissions could be represented by the eight bit number
   0xF0.  LV-src then creates a test message, which includes
   the light emission status and local-interface-id for
   every interface being tested.

>> So I have a question...
   Can I do link verification without impacting existing traffic?
   I don't suppose I can verify in-use links in this way, but what
   if I want to do verification on those links that are not
   currently active? Can I do this?
   I think the text below for "stuck" ports handles this but we
   should expose it explicitly.
   Note discovery and verification are different in this question.

   LV-dst, on receipt of a test message, records the status
   of light for every port and if at least one port has
   light it replies with a TestStatusSuccess message,
   containing the the local Interface_ID for each port that

>> typo "the the"

   has light. Otherwise, it sends a TestStatusFailure
   message indicating that no light was seen on any ports.

   On receipt of a TestStatusSuccess message, the LV-src
   sends a TestStatusAck message and changes the light
   emission to the next pattern and continues the process.

   When the LV-src has completed its test patterns and
   received the TestStatusSucccess messages for those Test
   Messages, it will send an EndVerify message to end the
   process.

   Using this mechanism, the port connectivity can be
   established through a series of interface light-emission
   patterns.

>> Should we handle the case where the LV-Src believes it has collected
   sufficient information to resolve the links but the LV-Dst believes
   it needs more information?
   This would probably reflect an implementation issue at Src or Dst,
   but could be addressed in the EndVerify response allowing the Dst
   to refuse EndVerify and to request a specific pattern.

>> Move example out?

   For an eight port example, the pattern 0xF0,
   0x0F, 0xCC, and 0xAA, would be sufficient to provide the
   mapping of eight ports to eight ports using only four
   patterns. For a switch with 64 ports the bitmap would
   have to be enlarged to eight bytes, and could use the
   patterns 0xFFFFFFFF00000000, 0x00000000FFFFFFFF,
   0xFFFF0000FFFF0000, 0xFF00FF00FF00FF00,
   0xF0F0F0F0F0F0F0F0, 0xCCCCCCCCCCCCCCCC,
   0xAAAAAAAAAAAAAAAA - performing the mapping using only
   seven patterns.

[BIG SNIP]

3.2 LOL support for multiple neighbors
   A weakness in the LOL mechanism occurs when (a) multiple
neighbors simultaneously use the mechanism to verify their
ports and (b) multiple links between a pair of nodes are
verified simultaneously.  This section describes the first
weakness and an enhanced algorithm that can overcome this

>> and the second weakness is described where?

weakness.  Note that any given node may only be performing
LOL link verification with one neighbor at a time.  The

[SNIP]

4. LMP LOL Message Definitions

4.1.  Test Message (Msg Type =3D 10)

   The LOL Test message is transmitted over the control
channel and not the data link and is used to verify its
physical connectivity. This is transmitted in the standard
LMP UDP/IP packet with payload format as follows:

     <Test Message> ::=3D <Common Header> <VERIFY_ID>
          <MESSAGE_ID> <LOL_TEST_STATUS>

4.2.  TestStatusSuccess Message (Msg Type =3D 11)

       The TestStatusSuccess message is transmitted over the
   control channel and is used to transmit the mapping
   between the local Interface Id and the Interface Id that
   was received in the Test messageTest Message once the
   exchange of Test and TestStatusSuccess messages is
   complete.

   <TestStatusSuccess Message> ::=3D <Common Header>
                    <LOCAL_LINK_ID> <MESSAGE_ID> <VERIFY_ID>
                    <LOCAL_INTERFACE_ID1>
                    <LOCAL_INTERFACE_ID2>. . .
                    <LOCAL_INTERFACE_IDn>

>> Why two different mechanisms?
   If you put LOL_TEST_STATUS in this message you have symmetry
   and don't have to worry about ordering of the LOCAL_INTERFACE_ID
   objects.

   The above transmission order SHOULD be followed, but the
   location of the VERIFY_ID in the message is unimportant.

>> Surely the order of LOCAL_INTERFACE_IDs is very important

Bradford et al                                               [Page 10]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

5. LMP Object Definitions

5.1.  BEGIN_VERIFY Class modifications.

   Verify Transport Mechanism:  16 bits

      This defines the transport mechanism for the Test
      Messages. The scope of this bit mask is restricted to
      each link encoding type. The local node will set the
      bits corresponding to the various mechanisms it can
      support for transmitting LMP test

      0x100 LOL: Loss Of Light and out-of-band Test
      messages

>> Why this choice of value? LMP-07 only defines 0x8000

              Capable of supporting link verification
              through the Presence and Loss of Light. In
              this case, the Test messageTest Messages are
              exchanged over the same IP control channel as
              standard LMP control messages. The Test
              messageTest Messages identify the Data
              Link(s) where Light is being emitted.
              TestStatusSuccess messages identify the Data
              Link(s) where Light has been detected.

>> The following paragraph is duplicate information.
   Just refer to section 4.1

The format of the Test message is as follows:

             <Test Message> ::=3D <Common Header>
                   <MESSAGE_ID> <VERIFY_ID>
                   <LOL_TEST_STATUS>

5.2.  LOL_TEST_STATUS Class

   Class =3D 21

Bradford et al                                               [Page 11]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

 o    IPv4, C-Type =3D 1

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Interface Id (4 bytes)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         LOL Status                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              :                                |
 //                             :                               //
 |                              :                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Interface Id (4 bytes)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         LOL Status                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[SNIP]

 LOL_Status: 32 bits

  This indicates the status condition of a data channel.  The
  following values are defined.  All other values are reserved.

  1   Signal Okay (OK): Interface Sent or Detected Light
  2   Signal Inconsistent: The Interface did sometimes
        detected light, sometimes did not
This Object contains one or more Interface Ids followed by an
   LOL_Status field.

>> Given that so few values are defined and that they are used as
   counting integers not flags can we reduce the size of the field
   and have some reserved bits?
   I suggest that we don't need more than one byte for LOL_status.
   Two if you are *really* pessimistic.

Bradford et al                                               [Page 13]
=0C
Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002

6. Acknowledgments

7. References

>> Need to split into Normative and Informational references

[SNIP]

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Richard,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This looks like a useful =
draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I have a few comments and nits in =
line (look for=20
&gt;&gt;)</FONT><FONT face=3DCourier size=3D2>.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Please let me know if you'd like me =
to clarify=20
any of my points or provide text.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>CCAMP Working=20
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Richard Bradford<BR>Internet=20
Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Dimitri Papadimitriou<BR>Expires: April=20
2003&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
Dan=20
Tappan<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
October 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; LMP Extensions =
for Link=20
discovery Using Loss of Light<BR>&gt;&gt; I think you'll get asked to =
expand the=20
acronym in the title</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[SNIP]<BR></FONT><FONT face=3DCourier =

size=3D2>Abstract</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This document proposes =
an enhanced=20
mechanism for LMP link</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; I think you'll get asked to =
expand the=20
acronym in the abstract</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; verification that is =
independent of=20
the data encoding</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; need to say that this is for =
use in=20
verifying optical links</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; type.&nbsp; The general =
proposal is=20
to use the transmission of<BR>&nbsp;&nbsp; light by the sender and =
recognition=20
of the presence or<BR>&nbsp;&nbsp; absence of light by the receiver to =
identify=20
port<BR>&nbsp;&nbsp; mapping.&nbsp; The proposal includes minor =
extensions to=20
the<BR>&nbsp;&nbsp; existing messages to implement this extension to the =

link<BR>&nbsp;&nbsp; verification procedure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 1]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>1. Introduction</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; I'd suggest that section 1 =
is too long=20
and the bulk of the<BR>&nbsp;&nbsp; text should be moved to a new =
"Overview"=20
section between<BR>&nbsp;&nbsp; the current sections 2 and =
3</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Optical networks are =
being developed=20
to include optical<BR>&nbsp;&nbsp; cross-connects, routers and DWDMs =
that are=20
configured<BR>&nbsp;&nbsp; with control channels and data links.&nbsp; =
LMP was=20
created to<BR>&nbsp;&nbsp; provide, among other features, link discovery =

between</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; and link =
verification</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; these devices.&nbsp; =
Currently, LMP=20
requires the ability to<BR>&nbsp;&nbsp; terminate data in these links in =
order=20
to perform this<BR>&nbsp;&nbsp; link discovery. Many of these devices, =
such as=20
DWDMs, do<BR>&nbsp;&nbsp; not currently have these capabilities and the =
addition=20
of<BR>&nbsp;&nbsp; these capabilities could be expensive or even=20
technically<BR>&nbsp;&nbsp; unfeasible.&nbsp; This memo defines =
extensions to=20
the LMP Link<BR>&nbsp;&nbsp; Verification Procedure to allow neighbors =
to=20
determine<BR>&nbsp;&nbsp; their interface mappings using the presence =
and=20
absence<BR>&nbsp;&nbsp; (a.k.a loss of light or LoL)loss of light on=20
those</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; /re-write<BR>&nbsp;&nbsp; =
Verification=20
Procedure to allow neighbors to determine<BR>&nbsp;&nbsp; their =
interface=20
mappings using the presence or absence<BR>&nbsp;&nbsp; of received light =
on=20
those<BR>&gt;&gt; /re-write off</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; interfaces, a capability =
that is=20
simpler, does not<BR>&nbsp;&nbsp; require optical/electrical conversion =
cheaper,=20
and is</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; add ", is"<BR>&nbsp;&nbsp; =
require=20
optical/electrical conversion, is cheaper, and is</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; within the existing =
functional=20
requirements of many of<BR>&nbsp;&nbsp; these devices.&nbsp; A common =
name for=20
the signal indicating<BR>&nbsp;&nbsp; presence and absence of light is=20
Loss-of-Light, (LOL), so<BR>&nbsp;&nbsp; that name is used throughout =
this=20
document.&nbsp; The proposed<BR>&nbsp;&nbsp; mechanism provides a more =
scalable=20
solution than the<BR>&nbsp;&nbsp; existing link verification=20
mechanisms.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>1.1.&nbsp; Current =
Limitations</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; [LMP] Link Verification =
requires=20
optical devices to<BR>&nbsp;&nbsp; provide link termination of each port =
and=20
provides a wide<BR>&nbsp;&nbsp; variety of transport mechanisms for =
possible=20
termination.<BR>&nbsp;&nbsp; This requirement leads to several =
challengeshe LMP=20
link</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; typo<BR>&nbsp;&nbsp; This =
requirement=20
leads to several challenges. The LMP link</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; termination requirement =
prevents=20
adoption on devices<BR>&nbsp;&nbsp; which do not already electrically =
terminate=20
links and<BR>&nbsp;&nbsp; presents difficult engineering challenges=20
for<BR>&nbsp;&nbsp; incorporation in many other devices. Another=20
limitation<BR>&nbsp;&nbsp; is the scalability of the current link=20
verification<BR>&nbsp;&nbsp; procedure. These are discussed in detail=20
below.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>1.1.1 Link Termination.&nbsp;=20
Issues<BR>&nbsp;&nbsp; This section raises issues of possible=20
additional<BR>&nbsp;&nbsp; complexity, performance impacts, reliability=20
impacts<BR>&nbsp;&nbsp; and potentially prohibitive cost issues which=20
could<BR>&nbsp;&nbsp; limit the applicability of LMP for certain =
devices.=20
Many<BR>&nbsp;&nbsp; of the issues are implementation specific and not=20
all<BR>&nbsp;&nbsp; issues affect all types of optical =
devices.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; 1)&nbsp; First, =
X-transparent=20
devices have no reason, other than</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; do you need to explain =
x-transparent and=20
X-aspect?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; supporting =
LMP link=20
verification, to terminate the X-aspect<BR>&nbsp;&nbsp;&nbsp;&nbsp; of =
the data=20
link. Support for such termination can =
greatly<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
increase the complexity, and cost, and power consumption=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp; some devices and the additional =
components could=20
affect such<BR>&nbsp;&nbsp;&nbsp;&nbsp; important aspects of a device as =
MTBF. A=20
DWDM that is</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 2]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September=20
2002<BR>&nbsp;&nbsp;&nbsp;&nbsp; electrically transparent, for example, =
would=20
need to add the</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; do you mean "optically"=20
transparent?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; ability to =
switch every=20
port between its operational pass-<BR>&nbsp;&nbsp;&nbsp;&nbsp; through =
mode and=20
its termination mode.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&nbsp;&nbsp; 2)&nbsp; Second, the =
addition of=20
link termination can increase<BR>&nbsp;&nbsp;&nbsp;&nbsp; the signal =
loss=20
through certain devices even when the link<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
is not=20
terminated, due to the additional switching<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
requirement. An example of this is a DWDM, which=20
normally<BR>&nbsp;&nbsp;&nbsp;&nbsp; does not need to switch the =
incoming light=20
to an internal<BR>&nbsp;&nbsp;&nbsp;&nbsp; termination module. While =
this is=20
very implementation<BR>&nbsp;&nbsp;&nbsp;&nbsp; dependent, the ability =
to=20
losslessly add this cabability</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; typo</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;"capability"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><BR>&nbsp;&nbsp;&nbsp;&nbsp; could =
present a=20
roadblock to support for link verification.<BR>&nbsp;&nbsp; 3) Third, an =

electrically transparent OXC would need to =
add<BR>&nbsp;&nbsp;&nbsp;&nbsp; one=20
or more termination modules and could and would lose=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp; switching capacity required for those=20
termination modules<BR>&nbsp;&nbsp;&nbsp;&nbsp; (e.g. a 16x16 port =
fabric=20
mightwould need to have at least</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; "mightwould" =
:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; one of those =
ports=20
connected to the link termination module,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
preventing=20
its connection to an external interface).<BR>&nbsp;&nbsp; 4) Fourth, is =
the=20
problem of supporting the "right" set of<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
termination=20
capabilities. For example, a electrically</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; "an" electrically<BR>&nbsp; =
&nbsp;but,=20
again, do you mean optically transparent?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;Actually, I think =
you mean that=20
the data plane is transparent</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; to the control=20
plane.&nbsp;</FONT><FONT face=3DCourier size=3D2>That is,&nbsp;the =
control plane=20
cannot&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; extract packets or =
overhead=20
information from the data plane.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This is a superset of =
optically=20
transparent. &nbsp;&nbsp;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; transparent =
switch may=20
be able to support connections<BR>&nbsp;&nbsp;&nbsp;&nbsp; carrying =
SONET or=20
Gigabit Ethernet. In addition, that switch<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
may be=20
able to switch wavelengths, which are =
carrying<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
anything from OC483 through OC768 and beyond. It would=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp; costly and difficult to provide =
termination=20
capabilities for<BR>&nbsp;&nbsp;&nbsp;&nbsp; even a small subset of =
these=20
transport mechanisms.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>1.1.2 Link Verification =
Scalability</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; 1)&nbsp; In addition to =
the above,=20
the many of theexisting</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; typo "the =
existing"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; mechanisms =
for LMP LV=20
calls for the link verification<BR>&nbsp;&nbsp;&nbsp;&nbsp; initiator to =
send=20
in-band messages from each port. If the<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
link-verification target switch is incapable =
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
simultaneously terminating all its ports, it must then=20
cycle<BR>&nbsp;&nbsp;&nbsp;&nbsp; through termination of its ports to =
find the=20
interface<BR>&nbsp;&nbsp;&nbsp;&nbsp; connected to each source. This =
does not=20
scale well for large<BR>&nbsp;&nbsp;&nbsp;&nbsp; switches. If a group of =
512=20
port OXCs is connected together,<BR>&nbsp;&nbsp;&nbsp;&nbsp; then each =
target=20
switch will need to cycle through an<BR>&nbsp;&nbsp;&nbsp;&nbsp; average =
of 256=20
ports before finding its mate. This requires<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
an=20
average of 131,072 (256x512) combinations to try, a=20
large<BR>&nbsp;&nbsp;&nbsp;&nbsp; number, especially if the combinations =
must be=20
tested<BR>&nbsp;&nbsp;&nbsp;&nbsp; serially(i.e. one termination at a=20
time).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; FWIW the average is less =
than this for=20
point-to-point connectivity<BR>&nbsp;&nbsp; in stable systems because =
you don't=20
need to scan ports that are<BR>&nbsp;&nbsp; already known to be=20
connected</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The solution proposed in =
this=20
document limits the<BR>&nbsp;&nbsp; excessive link termination costs, =
both in=20
terms of added<BR>&nbsp;&nbsp; hardware and the potentially increased =
reduce=20
optical<BR>&nbsp;&nbsp; lossbudgets to support that hardware. It also =
provides=20
a<BR>&nbsp;&nbsp; mechanism that scales much better for large numbers=20
of<BR>&nbsp;&nbsp; interconnects.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 3]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002<BR>1.2.&nbsp; =
Proposed=20
Solution Overview and Benefits.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The solution must =
address the issue=20
of link termination<BR>&nbsp;&nbsp; compatibility as well as the =
scalability=20
limitation of<BR>&nbsp;&nbsp; the existing LMP link verification=20
procedure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The ability to switch =
light on for=20
the transmit side of<BR>&nbsp;&nbsp; an interface and the ability to =
detect the=20
presence of<BR>&nbsp;&nbsp; light on the receive side of an interface is =

already<BR>&nbsp;&nbsp; present in many optical devices, regardless of=20
the<BR>&nbsp;&nbsp; optical encoding mechanisms used. A link=20
verification<BR>&nbsp;&nbsp; mechanism based on LOL puts a minimal =
requirement=20
on an<BR>&nbsp;&nbsp; interface and provides universal=20
compatibility.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; For scalability, the =
enhanced=20
procedure allows testing of<BR>&nbsp;&nbsp; all ports in parallel and =
without=20
terminating the line.<BR>&nbsp;&nbsp; This avoids the limitation of =
testing=20
ports serially,<BR>&nbsp;&nbsp; which requires terminating one source =
port at a=20
time,<BR>&nbsp;&nbsp; then the destination will need to terminate a =
line,=20
wait<BR>&nbsp;&nbsp; some interval which is greater than the=20
inter-message<BR>&nbsp;&nbsp; arrival time, and move to the next. This =
requires=20
the<BR>&nbsp;&nbsp; source to send on the order of n-squared messages.=20
The<BR>&nbsp;&nbsp; method described in this document reduces this to=20
a<BR>&nbsp;&nbsp; number on the order of ln(n) for large numbers=20
of<BR>&nbsp;&nbsp; interconnects. Note that the scalability problem is=20
only<BR>&nbsp;&nbsp; an issue for devices which cannot terminate=20
multiple<BR>&nbsp;&nbsp; ports simultaneously.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Here is an overview of =
the=20
procedure. For brevity, the<BR>&nbsp;&nbsp; initiator of link =
verification will=20
be referred to as LV-<BR>&nbsp;&nbsp; src and the destination node =
accepting the=20
link<BR>&nbsp;&nbsp; verification request will be referred to as=20
LV-dst.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; You need to clarify =
"pattern". I think=20
you should say<BR>&nbsp;&nbsp; something like...<BR>&nbsp;&nbsp; The =
LV-Src may=20
set some of its ports to transmit light<BR>&nbsp;&nbsp; and others to =
not=20
transmit light. Given a well-known<BR>&nbsp;&nbsp; ordering of ports, =
the ports=20
may be represented as a<BR>&nbsp;&nbsp; bit sequence with a zero bit=20
representing no light and<BR>&nbsp;&nbsp; a one representing a port =
transmitting=20
light. The<BR>&nbsp;&nbsp; resultant bit sequence represents the =
'pattern'=20
of<BR>&nbsp;&nbsp; enabled interfaces.<BR>&gt;&gt; /end suggested=20
text</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; LV-Src sets the =
interfaces it is=20
verifying to emit light<BR>&nbsp;&nbsp; in a particular pattern and then =
sends=20
that pattern to LV-<BR>&nbsp;&nbsp; Dst over the control channel. LV-Dst =
looks=20
for light on<BR>&nbsp;&nbsp; all its available interfaces and reports =
back over=20
the<BR>&nbsp;&nbsp; control channel. Initially every one of=20
LV-dst's<BR>&nbsp;&nbsp; interfaces can be "possibly-connected" to all =
of=20
LV-src's<BR>&nbsp;&nbsp; interfaces, since no possibilities have yet=20
been<BR>&nbsp;&nbsp; eliminated. However, each time LV-Src changes=20
the<BR>&nbsp;&nbsp; combination light on its interfaces, some of=20
LV-dst's<BR>&nbsp;&nbsp; interfaces will not see the corresponding =
change,=20
and<BR>&nbsp;&nbsp; connectivity between those two ports will be=20
eliminated<BR>&nbsp;&nbsp; as a possibility.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&gt;&gt; I would suggest moving =
all example=20
material out to a new section<BR>&nbsp;&nbsp; at the end of the draft. I =
don't=20
think that you need to give the<BR>&nbsp;&nbsp; comparison with =
port-by-port=20
scalability again - you have already<BR>&nbsp;&nbsp; covered =
this.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Using this mechanism, =
the port=20
connectivity can be<BR>&nbsp;&nbsp; established through a series of=20
interface/light-emission<BR>&nbsp;&nbsp; patterns. For an eight port =
example,=20
the pattern 0xF0,<BR>&nbsp;&nbsp; 0x0F, 0xCC, and 0xAA, would be more =
than=20
sufficient to<BR>&nbsp;&nbsp; provide the mapping of eight ports to =
eight ports.=20
These<BR>&nbsp;&nbsp; 4 messages will actually each require an=20
acknowledgement,<BR>&nbsp;&nbsp; totaling 8 messages. To verify =
eight-port=20
connectivity</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 4]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&nbsp;&nbsp; using the existing =
LMP Link=20
verification procedure<BR>&nbsp;&nbsp; requires the source to terminate =
each=20
source port in<BR>&nbsp;&nbsp; turn. For each source port, the =
destination=20
must<BR>&nbsp;&nbsp; terminate each potential destination until a test=20
message<BR>&nbsp;&nbsp; is received. On average, half the ports will =
need to=20
be<BR>&nbsp;&nbsp; tested before discovering the right one. This =
requires=20
a<BR>&nbsp;&nbsp; minimum of 8*4=3D 32 test messages, on average,=20
and<BR>&nbsp;&nbsp; probably many more, perhaps 64, since port=20
termination<BR>&nbsp;&nbsp; and waiting for a packet will typically =
require=20
waiting<BR>&nbsp;&nbsp; for more than a single packet transmission =
interval.=20
For<BR>&nbsp;&nbsp; eight ports, the number of test messages is reduced=20
from<BR>&nbsp;&nbsp; between 32 and 63 messages, to just 8. For 64 =
ports,=20
this<BR>&nbsp;&nbsp; method reduces the number of test messages=20
from<BR>&nbsp;&nbsp; (64*63)/2=3D2016 (or twice that), to 6+2=3D8 (or 16 =

including<BR>&nbsp;&nbsp; acknowledgments..</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Once LV-Src has =
completed its entire=20
pattern, LV-Dst will<BR>&nbsp;&nbsp; report which interfaces, if any, =
map to its=20
local<BR>&nbsp;&nbsp; interfaces.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The pattern of lights =
emissions must=20
cause each interface<BR>&nbsp;&nbsp; to change and must uniquely =
differentiate=20
between all the<BR>&nbsp;&nbsp; ports. The algorithm used in the above =
sequences=20
is as<BR>&nbsp;&nbsp; follows. For N ports. Pattern 1 =3D first N/2 =
ports=20
on,<BR>&nbsp;&nbsp; second N/2 ports off. Pattern 2 =3D First N/2 ports=20
off<BR>&nbsp;&nbsp; second N/2 on. Patterns 3-maximium, (where M=3D =
pattern=20
#)<BR>&nbsp;&nbsp; =3D Alternate on and off in groups of=20
N/(2**(M-1)).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; You should stress that this =
is an=20
example, but that the<BR>&nbsp;&nbsp; behavior is entirely an =
implementation=20
matter for the<BR>&nbsp;&nbsp; LV-Src.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>2. Terminology</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This document uses =
terminology from=20
the MPLS architecture<BR>&nbsp;&nbsp; document [MPLSArch] and the LMP =
Draft=20
[LMP].</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; if you move the bulk of the =
text in=20
section 1 downwards, you </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; can add terminology for =
'pattern'=20
and for 'transparent'.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>3. Link Verification =
Extensions.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The following extensions =
are needed=20
to support this<BR>&nbsp;&nbsp; method of Link =
Verification:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; A =
new flag is=20
defined to identify LOL in the=20
Verify<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Transport Mechanism =
field=20
of the BEGIN_VERIFY object and =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Verify Transport Response field of the=20
BEGIN_VERIFY_ACK<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object. =
This=20
field is defined across all LSP encoding=20
types<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and does not =
interfere with=20
specification of the =
existing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
transport mechanisms.<BR>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; Extension of =
the Test=20
Message to include the LOL Status.<BR>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; =
Extension=20
of the TestStatusSuccess message, which=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; similar to the modified =
Test=20
Message.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; "similar"? :-) </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; see my note in message =
format=20
below</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; there is an asymmetry =
between the=20
messages</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; =
Addition of a=20
LOL_TEST_STATUS Object.<BR>&gt;&gt; Assume this is the object included =
in the=20
previous two bullets?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 5]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>3.1.&nbsp; LOL Link Verification=20
Walkthrough</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Here is a walkthrough of =
the=20
procedure.&nbsp; LV-src sends a<BR>&nbsp;&nbsp; BeginVerify message =
indicating=20
LOL as the transport<BR>&nbsp;&nbsp; mechanism.&nbsp; LV-dst responds =
with a=20
BeginVerifyAck<BR>&nbsp;&nbsp; message, selecting LOL as the transport=20
mechanism.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; LV-src sets its =
interfaces to emit=20
light in pattern 1.<BR>&nbsp;&nbsp; For example, where 8 ports are being =

verified, and where<BR>&nbsp;&nbsp; a one represents "transmit light", =
the=20
pattern of light<BR>&nbsp;&nbsp; emissions could be represented by the =
eight bit=20
number<BR>&nbsp;&nbsp; 0xF0.&nbsp; LV-src then creates a test message, =
which=20
includes<BR>&nbsp;&nbsp; the light emission status and =
local-interface-id=20
for<BR>&nbsp;&nbsp; every interface being tested.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; So I have a =
question...<BR>&nbsp;&nbsp;=20
Can I do link verification without impacting existing =
traffic?<BR>&nbsp;&nbsp; I=20
don't suppose I can verify in-use links in this way, but =
what<BR>&nbsp;&nbsp; if=20
I want to do verification on those links that are not<BR>&nbsp;&nbsp; =
currently=20
active? Can I do this?<BR>&nbsp;&nbsp; I think the text below for =
"stuck" ports=20
handles this but we<BR>&nbsp;&nbsp; should expose it =
explicitly.<BR>&nbsp;&nbsp;=20
Note discovery and verification are different in this =
question.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&nbsp;&nbsp; LV-dst, on receipt =
of a test=20
message, records the status<BR>&nbsp;&nbsp; of light for every port and =
if at=20
least one port has<BR>&nbsp;&nbsp; light it replies with a =
TestStatusSuccess=20
message,<BR>&nbsp;&nbsp; containing the the local Interface_ID for each =
port=20
that</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; typo "the the"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; has light. Otherwise, it =
sends a=20
TestStatusFailure<BR>&nbsp;&nbsp; message indicating that no light was =
seen on=20
any ports.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; On receipt of a =
TestStatusSuccess=20
message, the LV-src<BR>&nbsp;&nbsp; sends a TestStatusAck message and =
changes=20
the light<BR>&nbsp;&nbsp; emission to the next pattern and continues the =

process.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; When the LV-src has =
completed its=20
test patterns and<BR>&nbsp;&nbsp; received the TestStatusSucccess =
messages for=20
those Test<BR>&nbsp;&nbsp; Messages, it will send an EndVerify message =
to end=20
the<BR>&nbsp;&nbsp; process.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Using this mechanism, =
the port=20
connectivity can be<BR>&nbsp;&nbsp; established through a series of =
interface=20
light-emission<BR>&nbsp;&nbsp; patterns.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; Should we handle the case =
where the=20
LV-Src believes it has collected<BR>&nbsp;&nbsp; sufficient information =
to=20
resolve the links but the LV-Dst believes<BR>&nbsp;&nbsp; it needs more=20
information?<BR>&nbsp;&nbsp; This would probably reflect an =
implementation issue=20
at Src or Dst,<BR>&nbsp;&nbsp; but could be addressed in the EndVerify =
response=20
allowing the Dst<BR>&nbsp;&nbsp; to refuse EndVerify and to request a =
specific=20
pattern.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&gt;&gt; Move example =
out?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; For an eight port =
example, the=20
pattern 0xF0,<BR>&nbsp;&nbsp; 0x0F, 0xCC, and 0xAA, would be sufficient =
to=20
provide the<BR>&nbsp;&nbsp; mapping of eight ports to eight ports using =
only=20
four<BR>&nbsp;&nbsp; patterns. For a switch with 64 ports the bitmap=20
would<BR>&nbsp;&nbsp; have to be enlarged to eight bytes, and could use=20
the<BR>&nbsp;&nbsp; patterns 0xFFFFFFFF00000000,=20
0x00000000FFFFFFFF,<BR>&nbsp;&nbsp; 0xFFFF0000FFFF0000,=20
0xFF00FF00FF00FF00,<BR>&nbsp;&nbsp; 0xF0F0F0F0F0F0F0F0,=20
0xCCCCCCCCCCCCCCCC,<BR>&nbsp;&nbsp; 0xAAAAAAAAAAAAAAAA - performing the =
mapping=20
using only<BR>&nbsp;&nbsp; seven patterns.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[BIG SNIP]</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>3.2 LOL support for multiple=20
neighbors<BR>&nbsp;&nbsp; A weakness in the LOL mechanism occurs when =
(a)=20
multiple<BR>neighbors simultaneously use the mechanism to verify =
their<BR>ports=20
and (b) multiple links between a pair of nodes are<BR>verified=20
simultaneously.&nbsp; This section describes the first<BR>weakness and =
an=20
enhanced algorithm that can overcome this</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; and the second weakness is =
described=20
where?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>weakness.&nbsp; Note that any given =
node may only=20
be performing<BR>LOL link verification with one neighbor at a =
time.&nbsp;=20
The</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[SNIP]</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>4. LMP LOL Message =
Definitions</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>4.1.&nbsp; Test Message (Msg Type =
=3D=20
10)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The LOL Test message is =
transmitted=20
over the control<BR>channel and not the data link and is used to verify=20
its<BR>physical connectivity. This is transmitted in the standard<BR>LMP =
UDP/IP=20
packet with payload format as follows:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; &lt;Test =
Message&gt; ::=3D=20
&lt;Common Header&gt;=20
&lt;VERIFY_ID&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
&lt;MESSAGE_ID&gt; &lt;LOL_TEST_STATUS&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>4.2.&nbsp; TestStatusSuccess =
Message (Msg=20
Type =3D 11)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The=20
TestStatusSuccess message is transmitted over the<BR>&nbsp;&nbsp; =
control=20
channel and is used to transmit the mapping<BR>&nbsp;&nbsp; between the =
local=20
Interface Id and the Interface Id that<BR>&nbsp;&nbsp; was received in =
the Test=20
messageTest Message once the<BR>&nbsp;&nbsp; exchange of Test and=20
TestStatusSuccess messages is<BR>&nbsp;&nbsp; complete.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; &lt;TestStatusSuccess =
Message&gt;=20
::=3D &lt;Common=20
Header&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;LOCAL_LINK_ID&gt; &lt;MESSAGE_ID&gt;=20
&lt;VERIFY_ID&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;LOCAL_INTERFACE_ID1&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

&lt;LOCAL_INTERFACE_ID2&gt;. .=20
.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;LOCAL_INTERFACE_IDn&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; Why two different=20
mechanisms?<BR>&nbsp;&nbsp; If you put LOL_TEST_STATUS in this message =
you have=20
symmetry<BR>&nbsp;&nbsp; and don't have to worry about ordering of the=20
LOCAL_INTERFACE_ID<BR>&nbsp;&nbsp; objects.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; The above transmission =
order SHOULD=20
be followed, but the<BR>&nbsp;&nbsp; location of the VERIFY_ID in the =
message is=20
unimportant.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; Surely the order of =
LOCAL_INTERFACE_IDs=20
is very important</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 10]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>5. LMP Object =
Definitions</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>5.1.&nbsp; BEGIN_VERIFY Class=20
modifications.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Verify Transport =
Mechanism:&nbsp; 16=20
bits</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
defines the=20
transport mechanism for the Test<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Messages. The=20
scope of this bit mask is restricted =
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; each=20
link encoding type. The local node will set=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bits corresponding to the various=20
mechanisms it can<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support for =
transmitting LMP=20
test</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x100 =
LOL: Loss Of=20
Light and out-of-band Test<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
messages</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; Why this choice of value? =
LMP-07 only=20
defines 0x8000</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
Capable of supporting link=20
verification<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
through the Presence and Loss of Light.=20
In<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
this case, the Test messageTest Messages=20
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
exchanged over the same IP control channel=20
as<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
standard LMP control messages. The=20
Test<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
messageTest Messages identify the=20
Data<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
Link(s) where Light is being=20
emitted.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
TestStatusSuccess messages identify the=20
Data<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
Link(s) where Light has been detected.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; The following paragraph is =
duplicate=20
information.<BR>&nbsp;&nbsp; Just refer to section 4.1</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The format of the Test message is as=20
follows:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
&lt;Test Message&gt; ::=3D &lt;Common=20
Header&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;MESSAGE_ID&gt;=20
&lt;VERIFY_ID&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;LOL_TEST_STATUS&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>5.2.&nbsp; LOL_TEST_STATUS =
Class</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Class =3D =
21</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 11]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;o&nbsp;&nbsp;&nbsp; IPv4, =
C-Type =3D=20
1</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
3<BR>&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =
0=20
1<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
Interface Id (4=20
bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
LOL=20
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
//<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
Interface Id (4=20
bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<BR>&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
LOL=20
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[SNIP]</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;LOL_Status: 32 =
bits</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; This indicates the status =
condition of a=20
data channel.&nbsp; The<BR>&nbsp; following values are defined.&nbsp; =
All other=20
values are reserved.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; 1&nbsp;&nbsp; Signal Okay =
(OK): Interface=20
Sent or Detected Light<BR>&nbsp; 2&nbsp;&nbsp; Signal Inconsistent: The=20
Interface did sometimes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
detected=20
light, sometimes did not<BR>This Object contains one or more Interface =
Ids=20
followed by an<BR>&nbsp;&nbsp; LOL_Status field.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&gt;&gt; Given that so few values =
are defined=20
and that they are used as<BR>&nbsp;&nbsp; counting integers not flags =
can we=20
reduce the size of the field<BR>&nbsp;&nbsp; and have some reserved=20
bits?<BR>&nbsp;&nbsp; I suggest that we don't need more than one byte =
for=20
LOL_status.<BR>&nbsp;&nbsp; Two if you are *really* =
pessimistic.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Bradford et=20
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[Page 13]<BR>=0C<BR>Internet Draft&nbsp;&nbsp;&nbsp;=20
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>6. Acknowledgments</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>7. References</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&gt; Need to split into Normative =
and=20
Informational references</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[SNIP]</FONT></DIV></BODY></HTML>

------=_NextPart_000_0037_01C28F0D.C0A43910--

Delivery-date: Mon, 18 Nov 2002 07:45:45 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Stephen Trowbridge <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Location of ITU-T Information
Date: Mon, 18 Nov 2002 10:44:38 -0500

Hi Steve,

There is another document that will be needed for the ITU-T work. This is the I-D that Bala has posted and submitted for informational RFC status:

draft-bala-uni-ldp-rsvp-extensions-02.txt

I'm not sure where in the process this document is, so hopefully Bala can comment.

Thanks
Zhi

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, November 18, 2002 10:10 AM
To: ccamp
Subject: Location of ITU-T Information

All,
>From this morning's presentation:

For access to incoming liaisons to IETF:
http://www.ietf.org/IESG/liaison.html 

For access to specific communications to external organizaitons from ITU-T Study Group 15:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

On this page, select the link for IETF-ccamp, acknowledge the ITU-T copyright, and
you will see a list of all communications sent from ITU-T Study Group 15 to ccamp
during this study period (2001-2004).

For the recent communication, select the link for "Signaling Protocol work in Q.14/15"
dated 11 October 2002. This communication has links from which you can download the
current draft Recommendations G.7713.2 and G.7713.3. These documents are planned for
consent at the 20-31 January 2003 Study Group 15 meeting.

Prerequisites for approval of these documents include:
Publication of base GMPLS documents for normative references:
draft-ietf-mpls-generalized-signaling-09.txt
draft-ietf-mpls-generalized-cr-ldp-07.txt
draft-ietf-mpls-generalized-rsvp-te-09.txt

IANA code point assignments for ASON extensions to rsvp-te and cr-ldp. Information
is captured in documents proposed for informational RFCs to expedite these assignments:
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
draft-aboulmagd-ccamp-crldp-ason-ext-01.txt

Regards,
Steve Trowbridge

Delivery-date: Mon, 18 Nov 2002 07:12:32 -0800
Date: Mon, 18 Nov 2002 08:09:57 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: Location of ITU-T Information

All,
>From this morning's presentation:

For access to incoming liaisons to IETF:
http://www.ietf.org/IESG/liaison.html 

For access to specific communications to external organizaitons from ITU-T Study Group 15:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

On this page, select the link for IETF-ccamp, acknowledge the ITU-T copyright, and
you will see a list of all communications sent from ITU-T Study Group 15 to ccamp
during this study period (2001-2004).

For the recent communication, select the link for "Signaling Protocol work in Q.14/15"
dated 11 October 2002. This communication has links from which you can download the
current draft Recommendations G.7713.2 and G.7713.3. These documents are planned for
consent at the 20-31 January 2003 Study Group 15 meeting.

Prerequisites for approval of these documents include:
Publication of base GMPLS documents for normative references:
draft-ietf-mpls-generalized-signaling-09.txt
draft-ietf-mpls-generalized-cr-ldp-07.txt
draft-ietf-mpls-generalized-rsvp-te-09.txt

IANA code point assignments for ASON extensions to rsvp-te and cr-ldp. Information
is captured in documents proposed for informational RFCs to expedite these assignments:
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
draft-aboulmagd-ccamp-crldp-ason-ext-01.txt

Regards,
Steve Trowbridge

Envelope-to: [email-masked]
Delivery-date: Sun, 17 Nov 2002 15:42:20 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: version number correction for ccamp agenda
Date: Sun, 17 Nov 2002 18:40:24 -0500

Please ignore me!
That was the July agenda.
Adrian
----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, November 17, 2002 6:28 PM
Subject: version number correction for ccamp agenda

> All,
>
> please note that...
>
> 10:15-10:25       draft-lee-ccamp-rsvp-te-exclude-route-00
>                           (Lee)
>
> should read draft-lee-ccamp-rsvp-te-exclude-route-01
>
> Thanks,
> Adrian
>
>
>
>

Envelope-to: [email-masked]
Delivery-date: Sun, 17 Nov 2002 15:31:34 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: version number correction for ccamp agenda
Date: Sun, 17 Nov 2002 18:28:32 -0500

All,

please note that...

10:15-10:25       draft-lee-ccamp-rsvp-te-exclude-route-00
                          (Lee)

should read draft-lee-ccamp-rsvp-te-exclude-route-01

Thanks,
Adrian

Delivery-date: Fri, 15 Nov 2002 07:03:32 -0800
From: "Naidu, Venkata" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06 (fwd)
Date: Fri, 15 Nov 2002 09:57:43 -0500

Jonathan,

-> Venkata,
->   I'm sorry I missed your earlier email.
-> 
->   The HelloInterval/HelloDeadInterval timers were debated 
-> among the authors
-> and multiple models (including the IS-IS and OSPF models) 
-> were considered.
-> LMP does require that the timer settings are synchronized to avoid
-> overloading the receiver, but it is a bit more flexible than 
-> some other
-> models that require parameter synchronization. 
-> 
-> LMP allows you to bring up multiple control channels 
-> simultaneously (these
-> can be over the same interface if desired). This can be used 
-> to change the
-> timers dynamically without risking that your original 
-> adjacency is lost.
-> (once a second control channel is brought up with new 
-> parameters you can
-> bring down the first). As an additional note, LMP allows 
-> negotiation of
-> these parameters with the ConfigNack message which includes 
-> an acceptable
-> value for the parameters. One thing you could do (and it's 
-> supported in the
-> LMP-MIB) is to configure a range of values that are 
-> acceptable. If your
-> neighbor proposes anything within the range, you have agreement.

  Fair enough. Thank you.

--
Venkata.

Delivery-date: Thu, 14 Nov 2002 16:12:25 -0800
From: Jonathan Lang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06 (fwd)
Date: Thu, 14 Nov 2002 16:09:44 -0800

Venkata,
  I'm sorry I missed your earlier email.

  The HelloInterval/HelloDeadInterval timers were debated among the authors
and multiple models (including the IS-IS and OSPF models) were considered.
LMP does require that the timer settings are synchronized to avoid
overloading the receiver, but it is a bit more flexible than some other
models that require parameter synchronization. 

LMP allows you to bring up multiple control channels simultaneously (these
can be over the same interface if desired). This can be used to change the
timers dynamically without risking that your original adjacency is lost.
(once a second control channel is brought up with new parameters you can
bring down the first). As an additional note, LMP allows negotiation of
these parameters with the ConfigNack message which includes an acceptable
value for the parameters. One thing you could do (and it's supported in the
LMP-MIB) is to configure a range of values that are acceptable. If your
neighbor proposes anything within the range, you have agreement.

Thanks,
Jonathan

> Date: Thu, 26 Sep 2002 18:45:40 -0400
> From: "Naidu, Venkata" <[email-masked]>
> To: "'Ong, Lyndon'" <[email-masked]>, 'Ron Bonica' 
> <[email-masked]>,
>      [email-masked]
> Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
> 
> LMP guys,
> 
> -> 1)  3.2.1 states that HelloInterval and HelloDeadInterval
> -> MUST be agreed upon by the local and remote nodes, but I
> -> am still looking for a description of how they agree, if
> -> it's there would appreciate a pointer to this (e.g., shortest
> -> value wins?)
> 
>   I have something to say regarding this point.
> 
>   Synchronized Parameter settings are sometimes harmful.
>   Most of the LMP Hello protocol fundamentals are derived
>   from OSPF. But, inherently there are some issues with
>   the OSPF Hello protocol parameter exchange.
> 
>   Radia's 1991 paper reads (FYI):
> 
>   In OSPF, there are several parameters that must be
>   configured identically in routers, or else the router will
>   refuse to communicate with each other. This creates a
>   problem because it is virtually impossible to change the
>   parameter setting via network management. Once a router's
>   parameter setting is changed, it is cut off from the
>   rest of the network since no other routers will be able
>   to communicate with it.
>   . . .
> 
>    - HelloTime and DeadTime:
>      . . .
>      ISIS reports only DeadTime in its Hello messages (not
>      HelloTime). As a result, the ratio between DeadTime and
>      HelloTime is fixed in ISIS, but can be configured in
>      different ways by OSPF. ISIS uses the information solely
>      to determine how long to wait between receipt of Hellos
>      from a particular neighbor before declaring the link
>      to that neighbor down. There is no necessity for
>      neighboring nodes to have the same value.
> 
>      Being able to change these timers in a running network is
>      important. As a LAN becomes larger it might be decided
>      that the overhead from hellos is too great. It also
>      might be important in some configurations to be able to
>      run with different hello timers for different routers.
>      There might be some routers for which quick deletion
>      of failure would be very desirable, whereas for other
>      routers quick deletion of failure might not be as
>      important. To lower overhead these routers might be
>      configured with a longer HelloTime. This cannot be done
>      in OSPF since all routers must have identical timers.
> 
>   Moreover, please remember that LMP hellos are very very
>   granular. The scalability requirements for LMP are little
>   strict when compared to traditional protocols.
> 
>   So, please revisit the LMP hello protocol timer configurations.
> 
>   After all, my 2 cents... :)
> 
> --
> Venkata.
> 

Delivery-date: Thu, 14 Nov 2002 03:23:17 -0800
Date: Thu, 14 Nov 2002 06:41:22 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Vikram Anantha <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: GMPLS Protection and Restoration Design Team - Report

hi

from the ccamp wg effort perspective, i think that the 
section 5.5.2 Dynamic LSP Restoration in the analysis 
i-d addresses your concern, it was not within the scope 
to preclude such capability, thus may i ask here what has 
in the current set of ccamp i-d implied such deduction, 
this may help us for further clarification

thanks,
- dimitri.

Vikram Anantha wrote:
> 
> It appears that the drafts produced by the TEWG design team and the
> GMPLS protection and restoration design team refer mainly to
> protection/restoration schemes where the protection capacity is either
> pre-calculated or is pre-established. This precludes dynamic restoration
> schemes like "dynamic mesh restoration".
> 
> IMHO this needs to be spelled out. If it has already been spelt out, I
> would appreciate a pointer to it. This would also be inline with the
> "Expected Document # 3" mentioned below.
> 
> Vik
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 7:39 AM
> To: [email-masked]
> Subject: GMPLS Protection and Restoration Design Team - Report
> 
> ccamp'ers,
> 
> Here below the report of the GMPLS protection and restoration design
> team:
> 
> Team goals were defined as follows:
> 
> Starting point Protection & Restoration produced by the TEWG
> Design Team. The produced functionality should satisfy these
> requirements; content that goes beyond these requirements or
> doesn't meet some of them should be called out so that the
> wg can re-evaluate.
> 
> Expected documents:
> 
> 1. Produce a terminology document, delivering a decoder ring to
>    translate to terminology in current drafts as well as the TE
>    WG document.
> 
> 2. Produce an (interim) analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
> 
>    note: from this perspective a decoder table on the current
>    methodologies/mechanisms may be additionally delivered in (1)
> 
> 3. Produce a functional spec delineating
> 
>    - What's in scope, out of scope, what's for future study, which
>    of the TEWG reqts have been met, which not, and what goes beyond.
> 
>    - This document should detail the overall approach objects/
>    procedures/... needed in a protocol-independent fashion
> 
>    note: point one will be translated by delineating content and
>    definition included in (1)
> 
> 4. Produce protocol specification
> 
>    4.1 Produce a document detailing the changes for RSVP-TE
> 
>    4.2 Produce a document detailing the changes for OSFP-TE and IS-IS-TE
> 
> Timeline:
> 
> - Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
>   the terminology i-d) had become upon community agreement wg
>   i-d
> 
>   note: nearly on time with the initially expected timeline for
>   this first step
> 
> - Ietf54 (july'02) decision upon closing content to be
>   included in the analysis i-d two weeks after the meeting
> 
>   => A version -02.txt of the analysis i-d had been submitted
>      end of august. Also a functional specification has been
>      delivered at the same time (had not been submitted on time
>      to be discussed during ietf54 meeting)
> 
>   note: compared to the initially expected timeline, this was
>   delayed by one ietf meeting
> 
> - Ietf55 (nov'02) decision upon analysis and signalling
>   functional specification to be discussed, once agreed
>   work on 4.1 and 4.2 should started first discussion to
>   be expected for Ietf56 (stabilizing protocol specification
>   should be achievable during '03 time it would be take
>   greatly depends upon the what's in/what's out/what's for
>   the next step decision)
> 
>   note: compared to the initially expected timeline, this was
>   delayed by two ietf meetings
> 
> Intermediate Conclusion:
> 
> - Still some work to be produced in particular with respect
>   to the protocol specification (expectation within a year
>   for a first phase)
> 
> - Delay can be explained in several ways 1) over time, the
>   more we get into the details the more time it took to
>   described and analyze the situation - as such the fact
>   the scope is closed now will help in achieving a tolerable
>   complexity level and allow for a first phase completion 2)
>   the timeline was probably too tight in order to allow for
>   any delay which has been accumulated after ietf'53
> 
> See we in atlanta,
> 
> thanks,
> - dimitri (for the p&r dt).

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 13 Nov 2002 19:45:55 -0800
content-class: urn:content-classes:message
Subject: RE: GMPLS Protection and Restoration Design Team - Report
Date: Wed, 13 Nov 2002 10:36:16 -0800
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

spamassassin -r
d
GMPLS protection and restoration design team refer mainly to
protection/restoration schemes where the protection capacity is either
pre-calculated or is pre-established. This precludes dynamic restoration
schemes like "dynamic mesh restoration".

IMHO this needs to be spelled out. If it has already been spelt out, I
would appreciate a pointer to it. This would also be inline with the
"Expected Document # 3" mentioned below.

Vik

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]=20
Sent: Monday, November 11, 2002 7:39 AM
To: [email-masked]
Subject: GMPLS Protection and Restoration Design Team - Report

ccamp'ers,

Here below the report of the GMPLS protection and restoration design
team:

Team goals were defined as follows:=20

Starting point Protection & Restoration produced by the TEWG=20
Design Team. The produced functionality should satisfy these=20
requirements; content that goes beyond these requirements or=20
doesn't meet some of them should be called out so that the
wg can re-evaluate.=20

Expected documents:

1. Produce a terminology document, delivering a decoder ring to=20
   translate to terminology in current drafts as well as the TE=20
   WG document.=20

2. Produce an (interim) analysis document, comparing and contrasting=20
   approaches (i.e., the above drafts, published and ongoing work =20
   at the ITU/T1-X1/...)=20

   note: from this perspective a decoder table on the current=20
   methodologies/mechanisms may be additionally delivered in (1)

3. Produce a functional spec delineating=20

   - What's in scope, out of scope, what's for future study, which=20
   of the TEWG reqts have been met, which not, and what goes beyond.

   - This document should detail the overall approach objects/
   procedures/... needed in a protocol-independent fashion=20

   note: point one will be translated by delineating content and
   definition included in (1)=20

4. Produce protocol specification

   4.1 Produce a document detailing the changes for RSVP-TE=20

   4.2 Produce a document detailing the changes for OSFP-TE and IS-IS-TE

Timeline:

- Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
  the terminology i-d) had become upon community agreement wg=20
  i-d=20

  note: nearly on time with the initially expected timeline for=20
  this first step

- Ietf54 (july'02) decision upon closing content to be=20
  included in the analysis i-d two weeks after the meeting
 =20
  =3D> A version -02.txt of the analysis i-d had been submitted=20
     end of august. Also a functional specification has been=20
     delivered at the same time (had not been submitted on time=20
     to be discussed during ietf54 meeting)

  note: compared to the initially expected timeline, this was=20
  delayed by one ietf meeting

- Ietf55 (nov'02) decision upon analysis and signalling=20
  functional specification to be discussed, once agreed
  work on 4.1 and 4.2 should started first discussion to
  be expected for Ietf56 (stabilizing protocol specification
  should be achievable during '03 time it would be take
  greatly depends upon the what's in/what's out/what's for
  the next step decision)

  note: compared to the initially expected timeline, this was=20
  delayed by two ietf meetings

Intermediate Conclusion:

- Still some work to be produced in particular with respect
  to the protocol specification (expectation within a year
  for a first phase)

- Delay can be explained in several ways 1) over time, the
  more we get into the details the more time it took to=20
  described and analyze the situation - as such the fact
  the scope is closed now will help in achieving a tolerable
  complexity level and allow for a first phase completion 2)
  the timeline was probably too tight in order to allow for
  any delay which has been accumulated after ietf'53=20

See we in atlanta,

thanks,
- dimitri (for the p&r dt).

Delivery-date: Wed, 13 Nov 2002 06:57:58 -0800
Date: Wed, 13 Nov 2002 09:52:20 -0500
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Meeting Slot Request
Cc: "Adrian Farrel" <[email-masked]>, "Tim Hall" <[email-masked]>

         Hi,

         I would like a slot to summarize and then discuss the outcome
of the MPLS MIB meeting and how this might affect the CCAMP
MIBs.   Adrien Farrel, Tim Hall and I will put together the slides
for the slot.

         --Tom

Success is relative; the more success, the more relatives. -Anonymous

Delivery-date: Tue, 12 Nov 2002 10:13:09 -0800
Date: Tue, 12 Nov 2002 12:22:15 -0500
From: Ron Bonica <[email-masked]>
Subject: IETF 55 Agenda
To: [email-masked]
Cc: [email-masked]

Folks,

The following is a preliminary agenda for IETF 55:

0900 - 0905    Agenda Bashing
0905 - 0915    WG Status
                 Kompella
0915 - 0925    ITU Status
                 Alanqar
0925 - 0935    Charter
                Kompella
0935 - 0950
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
                Lang
0950 - 1000
http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
                Swallow
1000 - 1010    Interoperability Presentation
                Swallow
1010 - 1025
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-00.txt
                Nadeau
1025 - 1040    Protection and Restoration Design Team Report
                Papadimitriou
1040 - 1050*
http://www.ietf.org/internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn
-00.txt
                Papadimitriou
1050 - 1100
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-00.txt

http://www.ietf.org/internet-drafts/draft-bonica-tunproto-03.txt
                Bonica

Again, this is just a preliminary draft.

*Although this draft does not fall strictly within the WG charter, the WG
chairs have examined it and find its content to be of general interest.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Mon, 11 Nov 2002 07:38:12 -0800
Date: Mon, 11 Nov 2002 16:38:33 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: "[email-masked]" <[email-masked]>
Subject: GMPLS Protection and Restoration Design Team - Report

ccamp'ers,

Here below the report of the GMPLS protection and restoration
design team:

Team goals were defined as follows: 

Starting point Protection & Restoration produced by the TEWG 
Design Team. The produced functionality should satisfy these 
requirements; content that goes beyond these requirements or 
doesn't meet some of them should be called out so that the
wg can re-evaluate. 

Expected documents:

1. Produce a terminology document, delivering a decoder ring to 
   translate to terminology in current drafts as well as the TE 
   WG document. 

2. Produce an (interim) analysis document, comparing and contrasting 
   approaches (i.e., the above drafts, published and ongoing work  
   at the ITU/T1-X1/...) 

   note: from this perspective a decoder table on the current 
   methodologies/mechanisms may be additionally delivered in (1)

3. Produce a functional spec delineating 

   - What's in scope, out of scope, what's for future study, which 
   of the TEWG reqts have been met, which not, and what goes beyond.     
   - This document should detail the overall approach objects/
   procedures/... needed in a protocol-independent fashion 

   note: point one will be translated by delineating content and
   definition included in (1) 

4. Produce protocol specification

   4.1 Produce a document detailing the changes for RSVP-TE 

   4.2 Produce a document detailing the changes for OSFP-TE and IS-IS-TE 

Timeline:

- Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
  the terminology i-d) had become upon community agreement wg 
  i-d 

  note: nearly on time with the initially expected timeline for 
  this first step

- Ietf54 (july'02) decision upon closing content to be 
  included in the analysis i-d two weeks after the meeting
  
  => A version -02.txt of the analysis i-d had been submitted 
     end of august. Also a functional specification has been 
     delivered at the same time (had not been submitted on time 
     to be discussed during ietf54 meeting)

  note: compared to the initially expected timeline, this was 
  delayed by one ietf meeting

- Ietf55 (nov'02) decision upon analysis and signalling 
  functional specification to be discussed, once agreed
  work on 4.1 and 4.2 should started first discussion to
  be expected for Ietf56 (stabilizing protocol specification
  should be achievable during '03 time it would be take
  greatly depends upon the what's in/what's out/what's for
  the next step decision)

  note: compared to the initially expected timeline, this was 
  delayed by two ietf meetings

Intermediate Conclusion:

- Still some work to be produced in particular with respect
  to the protocol specification (expectation within a year
  for a first phase)

- Delay can be explained in several ways 1) over time, the
  more we get into the details the more time it took to 
  described and analyze the situation - as such the fact
  the scope is closed now will help in achieving a tolerable
  complexity level and allow for a first phase completion 2)
  the timeline was probably too tight in order to allow for
  any delay which has been accumulated after ietf'53 

See we in atlanta,

thanks,
- dimitri (for the p&r dt).

Delivery-date: Sun, 10 Nov 2002 04:20:49 -0800
content-class: urn:content-classes:message
Subject: Ccamp@Ops. you have a greeting card from .
Date: Sun, 10 Nov 2002 14:11:04 +0200
From: "Nitsan Elfassy" <[email-masked]>
To: "Ccamp@Ops. Org (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C288B2.3DDFDC34
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ccamp@Ops.,

 has sent you a greeting card -- a postcard from Friend-Greetings.com. =
You can pickup your greeting card at Friend-Greetings.com by clicking on =
the link below.

http://www.friend-greeting.com/203746/pickup.html?code=3DCcamp@Ops.&id=3D=
1011021

Message:
------------------------------------------------------------
Ccamp@Ops.
I just sent you a greeting card - please pick it up.

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

------_=_NextPart_001_01C288B2.3DDFDC34
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Ccamp@Ops. you have a greeting card from .</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Ccamp@Ops.,</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;has sent you a greeting =
card -- a postcard from Friend-Greetings.com. You can pickup your =
greeting card at Friend-Greetings.com by clicking on the link =
below.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.friend-greeting.com/203746/pickup.html?code=3DCcamp@Op=
s.&id=3D1011021">http://www.friend-greeting.com/203746/pickup.html?code=3D=
Ccamp@Ops.&id=3D1011021</A></FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Message:</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
--</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Ccamp@Ops.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">I just sent you a greeting =
card - please pick it up.</FONT></P>

<P DIR=3DLTR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
--</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C288B2.3DDFDC34--

Delivery-date: Fri, 08 Nov 2002 04:35:30 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-01.txt
Date: Fri, 08 Nov 2002 07:30:35 -0500

--NextPart

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

	Title		: Recovery (Protection and Restoration) Terminology for 
                          GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-01.txt
	Pages		: 16
	Date		: 2002-11-7
	
This document defines a common terminology for Generalized MPLS
(GMPLS) based recovery mechanisms (i.e. protection and restoration)
that are under consideration by the CCAMP Working Group.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-terminology-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-recovery-terminology-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-recovery-terminology-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-01.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, 08 Nov 2002 04:35:02 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-07.txt
Date: Fri, 08 Nov 2002 07:30:32 -0500

--NextPart

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

	Title		: Link Management Protocol (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-07.txt
	Pages		: 74
	Date		: 2002-11-7
	
For scalability purposes, multiple data links can be combined to 
form a single traffic engineering (TE) link.  Furthermore, the 
management of TE links is not restricted to in-band messaging, but 
instead can be done using out-of-band techniques.  This document 
specifies a link management protocol (LMP) that runs between 
neighboring nodes and is used to manage TE links.  Specifically, LMP 
will be used to maintain control channel connectivity, verify the 
physical connectivity of the data links, correlate the link property 
information, suppress downstream alarms, and localize link failures 
for protection/restoration purposes in multiple kinds of networks.

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

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

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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-07.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: Thu, 07 Nov 2002 12:16:12 -0800
Message-Id: <[email-masked]>
From: The IESG <[email-masked]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
Date: Thu, 07 Nov 2002 15:11:40 -0500

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

Delivery-date: Thu, 07 Nov 2002 09:44:37 -0800
From: [email-masked]
Date: Thu, 7 Nov 2002 05:20:00 +0000 (GMT)
To: "Helvoort, Huub van" <[email-masked]>, Steve Gorshe <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Virtual concatenation: a clarification on sequence numbers

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

Dear Steve,

  This leads me to another doubt.  What is the use of dSQM when
there is no expected sequence number? What is the mismatch?  Or is
the dSQM modified to mean something like "If 3-5 consecutive received
sequence numbers on a link are not the same, dSQM is declared" ?

Is it possible for you to send a copy of the revised text which
clarifies these points?

>From all the mails that I've received on this topic, it seems that
people are divided on this.  Hope the standard clarifies it without
any ambiguity.

Greg: I was referring to the internal sequence numbers of the virtual
concatenation and not the timeslot numbering...

thanx
gopi

On Wed, 6 Nov 2002, Steve Gorshe wrote:

> Dear Gopi,
>
> We have noted that the language describing Virtual Concatenation is not
> clear some of these points.  The G.707 editor (Huub van Helvoort) and I
> are working on some revised text for G.707 and ANSI T1.105 (for which I
> am the editor) to clarify these points.  The answer to your question is
> that the sequence number is automatically assigned by the transmitting
> equipment and followed by the receiving equipment.  The LCAS protocol
> (ITU-T G.7042) for adjusting the bandwidth of a Virtually Concatenated
> channel depends on this.
>
> Best regards,
> Steve
>
> Steve Gorshe, Ph.D.
> Principal Engineer - Product Research
> PMC-Sierra, Inc.
> 10565 S.W. Nimbus Ave.
> Portland, OR 97223
> Tel: +1 503 431 7440
> Fax: +1 503 431 7400
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 5:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Virtual concatenation: a clarification on sequence numbers
>
>
> hi..
>
> I was going through the thread
>         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
>         subject: "concatenation extensions in sonet/sdh"
>
> I needed a small clarification on virtual concatenation sequencing
>
> Sequence number is sent by the transmitter and receiver checks for
> the sequence number to perform interleaving.
>
>   IS this sequence number "Provisioned"(on both terminating equipments) ?
>    OR
>   Is it automatically assigned by the transmitting equipment in some
>   sequence and the receiver synchronizes with the transmitters sequence number?
>
>
> I read the following relevant standards on virtual concatenation, but couldn't
> clearly understand how the receiver knows the sequencing of the
> individual links.
> + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
>     Description including Multiplex Structure, Rates and Formats,
>     put up on ftp.t1.org/..../1X150620.DOC)
> + G.707, G.783(virtual concatenation)
> + G.7042(LCAS)
>
> Thanx in advance
> Gopi
>

Delivery-date: Thu, 07 Nov 2002 07:51:33 -0800
Date: Thu, 07 Nov 2002 16:22:30 +0100
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: "[email-masked]" <[email-masked]>
Subject: GMPLS Protection and Restoration Team - Status Report

ccamp'ers,

the progress of the GMPLS Protection and Restoration team were
as follows since the last ietf54 meeting:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-01.txt 

- clarify definition on Full versus Partial Span Recovery Switching

=> still to be provided: the definitions of protection and 
   restorations schemes (to be delivered when other documents 
   settled)

http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt 

- text clarification and alignment (section 1 to 4) 
- new sub-section 5.1 Transport vs. Control Plane Responsibilities
  as discussed during last june, this has been now agreed
- review of section 6 (normalization/reversion) most of the input
  came from itu/t1 contribution and incorporated in this i-d for
  alignment 
- new sub-section 8.4.2 on Resource Sharing and Diversity (was
  missing between resource sharing and admission control issues)

=> most of the targeted items for a first phase have been tackled
   closing the last meeting decisions (we have enough for a first
   phase) the conclusion will be delivered in terms of a summary 
   wrt to additional gmpls control plane mechanisms

http://www.ietf.org/internet-drafts/draft-bala-gmpls-recovery-functional-01.txt 

- discussions on bulk recovery scheme and related functional
  signalling aspects (notification, switching request/response)

=> basis for the signalling specification (to be submitted
   after the ietf55 meeting)

any comment very welcome,
- dimitri (for the p&r team)

Delivery-date: Thu, 07 Nov 2002 07:09:24 -0800
Date: Thu, 07 Nov 2002 09:45:07 -0500
From: Ron Bonica <[email-masked]>
Subject: FW: I-D ACTION:draft-bonica-tunproto-03.txt
To: [email-masked]

FYI

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, November 07, 2002 6:22 AM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-bonica-tunproto-03.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Generic Tunnel Tracing Protocol (GTTP) 
> Specification
> 	Author(s)	: R. Bonica et al.
> 	Filename	: draft-bonica-tunproto-03.txt
> 	Pages		: 0
> 	Date		: 2002-11-6
> 	
> This document describes the Generic Tunnel Tracing Protocol (GTTP).
> GTTP supports enhanced route-tracing applications. Network operators
> use enhanced route-tracing applications to trace the path between any
> two points on an IP network. Enhanced route-tracing applications can
> trace through a network's forwarding plane, its control plane or
> both. Furthermore, enhanced route-tracing applications can reveal
> details concerning tunnels that support the traced path. Tunnel
> details can be revealed regardless of tunneling technology. For
> example, enhanced route-tracing applications can trace through an
> MPLS LSP as well as they can trace through an IP-in-IP tunnel.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-03.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of 
> the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with 
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bonica-tunproto-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bonica-tunproto-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

Delivery-date: Thu, 07 Nov 2002 05:52:22 -0800
Cc: "Helvoort, Huub van" <[email-masked]>, Steve Gorshe <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Thu, 07 Nov 2002 14:46:21 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: "Helvoort, Huub van" <[email-masked]>, Steve Gorshe <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Virtual concatenation: a clarification on sequence numbers

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

Gopi,

As you will have noticed from the figures I emailed yesterday, there is a
possibility to end up with the wrong sequence order (e.g. incorrect path setup
or faulty selector circuit). In such case dSQM will identify this and when
persistent (fSQM) it will initiate corrective actions.

Regards,

Maarten

[email-masked] wrote:
> 
> Dear Steve,
> 
>   This leads me to another doubt.  What is the use of dSQM when
> there is no expected sequence number? What is the mismatch?  Or is
> the dSQM modified to mean something like "If 3-5 consecutive received
> sequence numbers on a link are not the same, dSQM is declared" ?
> 
> Is it possible for you to send a copy of the revised text which
> clarifies these points?
> 
> From all the mails that I've received on this topic, it seems that
> people are divided on this.  Hope the standard clarifies it without
> any ambiguity.
> 
> Greg: I was referring to the internal sequence numbers of the virtual
> concatenation and not the timeslot numbering...
> 
> thanx
> gopi
> 
> On Wed, 6 Nov 2002, Steve Gorshe wrote:
> 
> > Dear Gopi,
> >
> > We have noted that the language describing Virtual Concatenation is not
> > clear some of these points.  The G.707 editor (Huub van Helvoort) and I
> > are working on some revised text for G.707 and ANSI T1.105 (for which I
> > am the editor) to clarify these points.  The answer to your question is
> > that the sequence number is automatically assigned by the transmitting
> > equipment and followed by the receiving equipment.  The LCAS protocol
> > (ITU-T G.7042) for adjusting the bandwidth of a Virtually Concatenated
> > channel depends on this.
> >
> > Best regards,
> > Steve
> >
> > Steve Gorshe, Ph.D.
> > Principal Engineer - Product Research
> > PMC-Sierra, Inc.
> > 10565 S.W. Nimbus Ave.
> > Portland, OR 97223
> > Tel: +1 503 431 7440
> > Fax: +1 503 431 7400
> > [email-masked]
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, November 06, 2002 5:58 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Virtual concatenation: a clarification on sequence numbers
> >
> >
> > hi..
> >
> > I was going through the thread
> >         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
> >         subject: "concatenation extensions in sonet/sdh"
> >
> > I needed a small clarification on virtual concatenation sequencing
> >
> > Sequence number is sent by the transmitter and receiver checks for
> > the sequence number to perform interleaving.
> >
> >   IS this sequence number "Provisioned"(on both terminating equipments) ?
> >    OR
> >   Is it automatically assigned by the transmitting equipment in some
> >   sequence and the receiver synchronizes with the transmitters sequence number?
> >
> >
> > I read the following relevant standards on virtual concatenation, but couldn't
> > clearly understand how the receiver knows the sequencing of the
> > individual links.
> > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> >     Description including Multiplex Structure, Rates and Formats,
> >     put up on ftp.t1.org/..../1X150620.DOC)
> > + G.707, G.783(virtual concatenation)
> > + G.7042(LCAS)
> >
> > Thanx in advance
> > Gopi
> >
--------------B8B74D50F2AFDECEB8A19A05
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard

--------------B8B74D50F2AFDECEB8A19A05--

Delivery-date: Thu, 07 Nov 2002 03:26:01 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-lee-ccamp-rsvp-te-exclude-route-01.txt
Date: Thu, 07 Nov 2002 06:21:51 -0500

--NextPart

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

	Title		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: C. Lee, A. Farrel, S. De Cnodder
	Filename	: draft-lee-ccamp-rsvp-te-exclude-route-01.txt
	Pages		: 14
	Date		: 2002-11-6
	
The current RSVP-TE specification [RSVP-TE] and GMPLS extensions
[GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly
included in a path setup, but not to be explicitly excluded.
In some systems where precise explicit paths are not computed at the
head end it may be useful to specify and signal abstract nodes and
resources that are to be explicitly excluded from routes.  These
exclusions may apply to the whole of a path, or to parts of a path
between two abstract nodes specified in an explicit route.
Shared Risk Link Groups (SRLGs) allow the definition of resources or
groups of resources that share the same risk of failure.  The
knowledge of SRLGs may be used to compute diverse paths that can be
used for protection.  In systems where it is useful to signal
exclusions, it may be useful to signal SRLGs to indicate groups of
resources that should be excluded on the whole of a path or between
two abstract nodes specified in an explicit path.
This draft specifies ways to communicate route exclusions during path
setup using RSVP-TE.
These approaches are equally applicable to other MPLS TE signaling
protocols such as CR-LDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lee-ccamp-rsvp-te-exclude-route-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-lee-ccamp-rsvp-te-exclude-route-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-lee-ccamp-rsvp-te-exclude-route-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-lee-ccamp-rsvp-te-exclude-route-01.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, 07 Nov 2002 02:05:23 -0800
Date: Thu, 07 Nov 2002 09:46:20 +0100
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], "Bernstein, Greg" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Virtual concatenation: a clarification on sequence numbers

hi,

i would rephrase your statement as "in case no flexibility
is delivered if it identifies the sequence number of the=20
VC (used as convention) does it 1) remove any capability=20
2) when provisioned and an event occurs such as a failure=20
does it imply any processing", for 1) response is clear it
simply follows the capabilities of the data plane and for 2)
no more than what the data plane requires such that the
control keeps track of it, in conclusion you deliver the
capability to follow the usage of the data plane of the
corresponding components, it becomes a very good fallback
mechanism (see section 5.2 for more details). However, what=20
i got with this discussion is that i have to refine a bit=20
the flexible case (idea is to keep the same definition
and refer to the entry point of the selector, thus for
a locked selection the definition stays unchanged)

note for the community, we are discussing here the following
http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-04.txt

hope this clarifies,
- dimitri.

"Ong, Lyndon" wrote:
>=20
> Hi Dimitri,
>=20
> The signaling protocol should be able to identify the particular VC
> and also the virtual concatenation group it belongs to, but it's not
> still clear why it needs to identify the sequence number of the VC.
> One concern is that the sequence number may change in response to failure
> but there is no need for the signaling protocol to be aware of this
> for the remaining VCs, unless you tie the two together.
>=20
> Cheers,
>=20
> Lyndon
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 10:49 AM
> To: Ong, Lyndon
> Cc: 'Heiles Juergen'; [email-masked]';
> [email-masked]; [email-masked]; Bernstein, Greg;
> [email-masked]; [email-masked]
> Subject: Re: Virtual concatenation: a clarification on sequence numbers
>=20
> hi,
>=20
> in any case you need a number, the reason why this
> has been proposed is to avoid yet another translation
> (mapping) table at the edges, these numbers must be
> unique in their applicability scope, thus there will
> always be a consistency check;
>=20
> - dimitri.
>=20
> "Ong, Lyndon" wrote:
> >
> > Hi Juergen,
> >
> > I was wondering about this, if the order of the VC-Ns is specified
> > twice (once by the automated path setup, and again by the
> > sequence number in the overhead) this could provide an additional
> > consistency check or it could be a source of error.  For automated
> > path setup, might it not be better to leave the
> > sequence number out of the GMPLS/ASON signaling and have it only in the
> > overhead?  Then there is no need for a consistency check.
> >
> > Thanks,
> >
> > Lyndon
> >
> > -----Original Message-----
> > From: Heiles Juergen [mailto:[email-masked]]
> > Sent: Wednesday, November 06, 2002 8:41 AM
> > To: [email-masked]'; [email-masked]
> > Cc: [email-masked]; Bernstein, Greg; [email-masked];
> > [email-masked]
> > Subject: AW: Virtual concatenation: a clarification on sequence numbers
> >
> > Gopi,
> >
> > the sequence number always reflects the order of the VC-Ns within a
> virtual
> > concatenation and is never provisioned directly. In a SDH/SONET
> environment
> > with TMN provisioning and without LCAS the order is set by the TMN at t=
he
> > source and sink. If the sink receives sequence numbers in the wrong ord=
er
> it
> > will alarm. With LCAS the order can change dynamical for example if one=
 VC
> > fails and is removed from the group and later on added again. In case of
> > automatic path setup (GMPLS/ASON) this process has to define the order =
of
> > the VCs and as such the sequence numbers.
> >
> > Regards
> >
> > Juergen
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: [email-masked]
> > > [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 6. November 2002 14:58
> > > An: [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked];
> > > [email-masked]
> > > Betreff: Virtual concatenation: a clarification on sequence numbers
> > >
> > >
> > > [ post by non-subscriber.  with the massive amount of spam,
> > > it is easy to
> > >   miss and therefore delete mis-posts.  so fix subscription
> > > addresses! ]
> > >
> > > hi..
> > >
> > > I was going through the thread
> > >         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
> > >         subject: "concatenation extensions in sonet/sdh"
> > >
> > > I needed a small clarification on virtual concatenation sequencing
> > >
> > > Sequence number is sent by the transmitter and receiver checks for
> > > the sequence number to perform interleaving.
> > >
> > >   IS this sequence number "Provisioned"(on both terminating
> > > equipments) ?
> > >    OR
> > >   Is it automatically assigned by the transmitting equipment in some
> > >   sequence and the receiver synchronizes with the
> > > transmitters sequence number?
> > >
> > >
> > > I read the following relevant standards on virtual
> > > concatenation, but couldn't
> > > clearly understand how the receiver knows the sequencing of the
> > > individual links.
> > > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> > >     Description including Multiplex Structure, Rates and Formats,
> > >     put up on ftp.t1.org/..../1X150620.DOC)
> > > + G.707, G.783(virtual concatenation)
> > > + G.7042(LCAS)
> > >
> > > Thanx in advance
> > > Gopi
> > >
> > >
> > >
> > >
>=20
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

--=20
Papadimitriou Dimitri=20
E-mail : [email-masked]=20
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 06 Nov 2002 15:13:29 -0800
To: "Ong, Lyndon" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Date: Thu, 07 Nov 2002 00:10:05 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: "Ong, Lyndon" <[email-masked]>, "[email-masked]'" <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Virtual concatenation: a clarification on sequence numbers

This is a multi-part message in MIME format.
--------------C19CF9CE5E529711D4A89A7D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Gopi, Lyndon,

Attached is a short document describing some virtual concatenation and LC=
AS
details. There can be different architectures, each with its specific
characteristics with respect to sequence numbers.

When there is no flexibility at the two virtconc end points (e.g. combina=
tion of
figures 1 and 4), the path setup process (either network management or co=
ntrol
plane) has only one way to connect the VC-n trail termination fucntions
together; otherwise no transmission.

When there is flexibility in both virtconc end points (e.g. figure 3 base=
d
adaptation or figure 3/4 based adaptation and figure 2 (IIa) architecture=
), the
path setup process can connect any two VC-n trail termination fucntions
together; the adaptation sink (receiver) will be able to follow automatic=
ally.

Sequence identifiers don't need to be provisioned under connection manage=
ment
control (network management or control plane). These numbers are under co=
ntrol
of the network element. For the case of no flexibility these numbers need=
 to be
known by the connection management process (network management or control=
 plane)
in order to be able to connect the correct VC-n trail termination functio=
ns. For
the case of flexibility, connection management can ignore these sequence
identifiers completely. Network elements will take care of correct orderi=
ng of
received streams. For the case one end is flexible and the other end has =
no
flexibility, I need to do a further check... =

Regards,

Maarten

"Ong, Lyndon" wrote:
> =

> Hi Juergen,
> =

> I was wondering about this, if the order of the VC-Ns is specified
> twice (once by the automated path setup, and again by the
> sequence number in the overhead) this could provide an additional
> consistency check or it could be a source of error.  For automated
> path setup, might it not be better to leave the
> sequence number out of the GMPLS/ASON signaling and have it only in the=

> overhead?  Then there is no need for a consistency check.
> =

> Thanks,
> =

> Lyndon
> =

> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 8:41 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; Bernstein, Greg; [email-masked];=

> [email-masked]
> Subject: AW: Virtual concatenation: a clarification on sequence numbers=

> =

> Gopi,
> =

> the sequence number always reflects the order of the VC-Ns within a vir=
tual
> concatenation and is never provisioned directly. In a SDH/SONET environ=
ment
> with TMN provisioning and without LCAS the order is set by the TMN at t=
he
> source and sink. If the sink receives sequence numbers in the wrong ord=
er it
> will alarm. With LCAS the order can change dynamical for example if one=
 VC
> fails and is removed from the group and later on added again. In case o=
f
> automatic path setup (GMPLS/ASON) this process has to define the order =
of
> the VCs and as such the sequence numbers.
> =

> Regards
> =

> Juergen
> =

> > -----Urspr=FCngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]]
> > Gesendet: Mittwoch, 6. November 2002 14:58
> > An: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked];
> > [email-masked]
> > Betreff: Virtual concatenation: a clarification on sequence numbers
> >
> >
> > [ post by non-subscriber.  with the massive amount of spam,
> > it is easy to
> >   miss and therefore delete mis-posts.  so fix subscription
> > addresses! ]
> >
> > hi..
> >
> > I was going through the thread
> >         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295=

> >         subject: "concatenation extensions in sonet/sdh"
> >
> > I needed a small clarification on virtual concatenation sequencing
> >
> > Sequence number is sent by the transmitter and receiver checks for
> > the sequence number to perform interleaving.
> >
> >   IS this sequence number "Provisioned"(on both terminating
> > equipments) ?
> >    OR
> >   Is it automatically assigned by the transmitting equipment in some
> >   sequence and the receiver synchronizes with the
> > transmitters sequence number?
> >
> >
> > I read the following relevant standards on virtual
> > concatenation, but couldn't
> > clearly understand how the receiver knows the sequencing of the
> > individual links.
> > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> >     Description including Multiplex Structure, Rates and Formats,
> >     put up on ftp.t1.org/..../1X150620.DOC)
> > + G.707, G.783(virtual concatenation)
> > + G.7042(LCAS)
> >
> > Thanx in advance
> > Gopi
> >
> >
> >
> >
--------------C19CF9CE5E529711D4A89A7D
Content-Type: application/pdf;
 name="lcas-model.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="lcas-model.pdf"

--------------C19CF9CE5E529711D4A89A7D
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard

--------------C19CF9CE5E529711D4A89A7D--

Delivery-date: Wed, 06 Nov 2002 12:44:23 -0800
From: Steve Gorshe <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], "Helvoort, Huub van" <[email-masked]>
Subject: RE: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 10:16:16 -0800

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

Dear Gopi,

We have noted that the language describing Virtual Concatenation is not 
clear some of these points.  The G.707 editor (Huub van Helvoort) and I 
are working on some revised text for G.707 and ANSI T1.105 (for which I 
am the editor) to clarify these points.  The answer to your question is 
that the sequence number is automatically assigned by the transmitting 
equipment and followed by the receiving equipment.  The LCAS protocol 
(ITU-T G.7042) for adjusting the bandwidth of a Virtually Concatenated 
channel depends on this.  

Best regards,
Steve

Steve Gorshe, Ph.D.
Principal Engineer - Product Research
PMC-Sierra, Inc.
10565 S.W. Nimbus Ave.
Portland, OR 97223
Tel: +1 503 431 7440
Fax: +1 503 431 7400
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 5:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Virtual concatenation: a clarification on sequence numbers

hi..

I was going through the thread
        http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
        subject: "concatenation extensions in sonet/sdh"

I needed a small clarification on virtual concatenation sequencing

Sequence number is sent by the transmitter and receiver checks for
the sequence number to perform interleaving.

  IS this sequence number "Provisioned"(on both terminating equipments) ?
   OR
  Is it automatically assigned by the transmitting equipment in some
  sequence and the receiver synchronizes with the transmitters sequence number?

I read the following relevant standards on virtual concatenation, but couldn't
clearly understand how the receiver knows the sequencing of the
individual links.
+ T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
    Description including Multiplex Structure, Rates and Formats,
    put up on ftp.t1.org/..../1X150620.DOC)
+ G.707, G.783(virtual concatenation)
+ G.7042(LCAS)

Thanx in advance
Gopi

Delivery-date: Wed, 06 Nov 2002 11:42:12 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], "Bernstein, Greg" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 11:32:33 -0800 

Hi Dimitri,

The signaling protocol should be able to identify the particular VC
and also the virtual concatenation group it belongs to, but it's not
still clear why it needs to identify the sequence number of the VC.
One concern is that the sequence number may change in response to =
failure
but there is no need for the signaling protocol to be aware of this
for the remaining VCs, unless you tie the two together.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 10:49 AM
To: Ong, Lyndon
Cc: 'Heiles Juergen'; [email-masked]';
[email-masked]; [email-masked]; Bernstein, Greg;
[email-masked]; [email-masked]
Subject: Re: Virtual concatenation: a clarification on sequence numbers

hi,

in any case you need a number, the reason why this
has been proposed is to avoid yet another translation=20
(mapping) table at the edges, these numbers must be
unique in their applicability scope, thus there will
always be a consistency check;

- dimitri.

"Ong, Lyndon" wrote:
>=20
> Hi Juergen,
>=20
> I was wondering about this, if the order of the VC-Ns is specified
> twice (once by the automated path setup, and again by the
> sequence number in the overhead) this could provide an additional
> consistency check or it could be a source of error.  For automated
> path setup, might it not be better to leave the
> sequence number out of the GMPLS/ASON signaling and have it only in =
the
> overhead?  Then there is no need for a consistency check.
>=20
> Thanks,
>=20
> Lyndon
>=20
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 8:41 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; Bernstein, Greg; =
[email-masked];
> [email-masked]
> Subject: AW: Virtual concatenation: a clarification on sequence =
numbers
>=20
> Gopi,
>=20
> the sequence number always reflects the order of the VC-Ns within a
virtual
> concatenation and is never provisioned directly. In a SDH/SONET
environment
> with TMN provisioning and without LCAS the order is set by the TMN at =
the
> source and sink. If the sink receives sequence numbers in the wrong =
order
it
> will alarm. With LCAS the order can change dynamical for example if =
one VC
> fails and is removed from the group and later on added again. In case =
of
> automatic path setup (GMPLS/ASON) this process has to define the =
order of
> the VCs and as such the sequence numbers.
>=20
> Regards
>=20
> Juergen
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]]
> > Gesendet: Mittwoch, 6. November 2002 14:58
> > An: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked];
> > [email-masked]
> > Betreff: Virtual concatenation: a clarification on sequence numbers
> >
> >
> > [ post by non-subscriber.  with the massive amount of spam,
> > it is easy to
> >   miss and therefore delete mis-posts.  so fix subscription
> > addresses! ]
> >
> > hi..
> >
> > I was going through the thread
> >         =
http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
> >         subject: "concatenation extensions in sonet/sdh"
> >
> > I needed a small clarification on virtual concatenation sequencing
> >
> > Sequence number is sent by the transmitter and receiver checks for
> > the sequence number to perform interleaving.
> >
> >   IS this sequence number "Provisioned"(on both terminating
> > equipments) ?
> >    OR
> >   Is it automatically assigned by the transmitting equipment in =
some
> >   sequence and the receiver synchronizes with the
> > transmitters sequence number?
> >
> >
> > I read the following relevant standards on virtual
> > concatenation, but couldn't
> > clearly understand how the receiver knows the sequencing of the
> > individual links.
> > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> >     Description including Multiplex Structure, Rates and Formats,
> >     put up on ftp.t1.org/..../1X150620.DOC)
> > + G.707, G.783(virtual concatenation)
> > + G.7042(LCAS)
> >
> > Thanx in advance
> > Gopi
> >
> >
> >
> >

--=20
Papadimitriou Dimitri=20
E-mail : [email-masked]=20
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 06 Nov 2002 10:49:45 -0800
Date: Wed, 06 Nov 2002 19:49:01 +0100
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], "Bernstein, Greg" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Virtual concatenation: a clarification on sequence numbers

hi,

in any case you need a number, the reason why this
has been proposed is to avoid yet another translation=20
(mapping) table at the edges, these numbers must be
unique in their applicability scope, thus there will
always be a consistency check;

- dimitri.

"Ong, Lyndon" wrote:
>=20
> Hi Juergen,
>=20
> I was wondering about this, if the order of the VC-Ns is specified
> twice (once by the automated path setup, and again by the
> sequence number in the overhead) this could provide an additional
> consistency check or it could be a source of error.  For automated
> path setup, might it not be better to leave the
> sequence number out of the GMPLS/ASON signaling and have it only in the
> overhead?  Then there is no need for a consistency check.
>=20
> Thanks,
>=20
> Lyndon
>=20
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 8:41 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; Bernstein, Greg; [email-masked];
> [email-masked]
> Subject: AW: Virtual concatenation: a clarification on sequence numbers
>=20
> Gopi,
>=20
> the sequence number always reflects the order of the VC-Ns within a virtu=
al
> concatenation and is never provisioned directly. In a SDH/SONET environme=
nt
> with TMN provisioning and without LCAS the order is set by the TMN at the
> source and sink. If the sink receives sequence numbers in the wrong order=
 it
> will alarm. With LCAS the order can change dynamical for example if one VC
> fails and is removed from the group and later on added again. In case of
> automatic path setup (GMPLS/ASON) this process has to define the order of
> the VCs and as such the sequence numbers.
>=20
> Regards
>=20
> Juergen
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]]
> > Gesendet: Mittwoch, 6. November 2002 14:58
> > An: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked];
> > [email-masked]
> > Betreff: Virtual concatenation: a clarification on sequence numbers
> >
> >
> > [ post by non-subscriber.  with the massive amount of spam,
> > it is easy to
> >   miss and therefore delete mis-posts.  so fix subscription
> > addresses! ]
> >
> > hi..
> >
> > I was going through the thread
> >         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
> >         subject: "concatenation extensions in sonet/sdh"
> >
> > I needed a small clarification on virtual concatenation sequencing
> >
> > Sequence number is sent by the transmitter and receiver checks for
> > the sequence number to perform interleaving.
> >
> >   IS this sequence number "Provisioned"(on both terminating
> > equipments) ?
> >    OR
> >   Is it automatically assigned by the transmitting equipment in some
> >   sequence and the receiver synchronizes with the
> > transmitters sequence number?
> >
> >
> > I read the following relevant standards on virtual
> > concatenation, but couldn't
> > clearly understand how the receiver knows the sequencing of the
> > individual links.
> > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> >     Description including Multiplex Structure, Rates and Formats,
> >     put up on ftp.t1.org/..../1X150620.DOC)
> > + G.707, G.783(virtual concatenation)
> > + G.7042(LCAS)
> >
> > Thanx in advance
> > Gopi
> >
> >
> >
> >

--=20
Papadimitriou Dimitri=20
E-mail : [email-masked]=20
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 06 Nov 2002 10:37:16 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], "Bernstein, Greg" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 10:28:07 -0800 

Hi Juergen,

I was wondering about this, if the order of the VC-Ns is specified
twice (once by the automated path setup, and again by the
sequence number in the overhead) this could provide an additional
consistency check or it could be a source of error.  For automated
path setup, might it not be better to leave the
sequence number out of the GMPLS/ASON signaling and have it only in the
overhead?  Then there is no need for a consistency check.

Thanks,

Lyndon=20

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 8:41 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; Bernstein, Greg; [email-masked];
[email-masked]
Subject: AW: Virtual concatenation: a clarification on sequence numbers

Gopi,

the sequence number always reflects the order of the VC-Ns within a =
virtual
concatenation and is never provisioned directly. In a SDH/SONET =
environment
with TMN provisioning and without LCAS the order is set by the TMN at =
the
source and sink. If the sink receives sequence numbers in the wrong =
order it
will alarm. With LCAS the order can change dynamical for example if one =
VC
fails and is removed from the group and later on added again. In case =
of
automatic path setup (GMPLS/ASON) this process has to define the order =
of
the VCs and as such the sequence numbers.

Regards

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]]
> Gesendet: Mittwoch, 6. November 2002 14:58
> An: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked];
> [email-masked]
> Betreff: Virtual concatenation: a clarification on sequence numbers
>=20
>=20
> [ post by non-subscriber.  with the massive amount of spam,=20
> it is easy to
>   miss and therefore delete mis-posts.  so fix subscription=20
> addresses! ]
>=20
> hi..
>=20
> I was going through the thread
>         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
>         subject: "concatenation extensions in sonet/sdh"
>=20
> I needed a small clarification on virtual concatenation sequencing
>=20
> Sequence number is sent by the transmitter and receiver checks for
> the sequence number to perform interleaving.
>=20
>   IS this sequence number "Provisioned"(on both terminating=20
> equipments) ?
>    OR
>   Is it automatically assigned by the transmitting equipment in some
>   sequence and the receiver synchronizes with the=20
> transmitters sequence number?
>=20
>=20
> I read the following relevant standards on virtual=20
> concatenation, but couldn't
> clearly understand how the receiver knows the sequencing of the
> individual links.
> + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
>     Description including Multiplex Structure, Rates and Formats,
>     put up on ftp.t1.org/..../1X150620.DOC)
> + G.707, G.783(virtual concatenation)
> + G.7042(LCAS)
>=20
> Thanx in advance
> Gopi
>=20
>=20
>=20
>=20

Delivery-date: Wed, 06 Nov 2002 10:05:07 -0800
content-class: urn:content-classes:message
Subject: RE: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 13:02:14 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Heiles Juergen" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Gopi,

Just to clarify Juergen's comment, his comment is on the sequence =
numbers used at the VC (path layer) source and sink to align the =
payloads of the VCs. These sequence numbers have no relation to the =
timeslots used on the next level i.e. the STS-48 (OC-48 line level). For =
an end-to-end path over multiple connections, i.e. not physically =
adjacent, the timeslots used at each end will have no dependencies as =
they are assigned at the line layer.
Deborah

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 11:41 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: AW: Virtual concatenation: a clarification on sequence numbers

Gopi,

the sequence number always reflects the order of the VC-Ns within a =
virtual concatenation and is never provisioned directly. In a SDH/SONET =
environment with TMN provisioning and without LCAS the order is set by =
the TMN at the source and sink. If the sink receives sequence numbers in =
the wrong order it will alarm. With LCAS the order can change dynamical =
for example if one VC fails and is removed from the group and later on =
added again. In case of automatic path setup (GMPLS/ASON) this process =
has to define the order of the VCs and as such the sequence numbers.

Regards

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]]
> Gesendet: Mittwoch, 6. November 2002 14:58
> An: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked];
> [email-masked]
> Betreff: Virtual concatenation: a clarification on sequence numbers
>=20
>=20
> [ post by non-subscriber.  with the massive amount of spam,=20
> it is easy to
>   miss and therefore delete mis-posts.  so fix subscription=20
> addresses! ]
>=20
> hi..
>=20
> I was going through the thread
>         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
>         subject: "concatenation extensions in sonet/sdh"
>=20
> I needed a small clarification on virtual concatenation sequencing
>=20
> Sequence number is sent by the transmitter and receiver checks for
> the sequence number to perform interleaving.
>=20
>   IS this sequence number "Provisioned"(on both terminating=20
> equipments) ?
>    OR
>   Is it automatically assigned by the transmitting equipment in some
>   sequence and the receiver synchronizes with the=20
> transmitters sequence number?
>=20
>=20
> I read the following relevant standards on virtual=20
> concatenation, but couldn't
> clearly understand how the receiver knows the sequencing of the
> individual links.
> + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
>     Description including Multiplex Structure, Rates and Formats,
>     put up on ftp.t1.org/..../1X150620.DOC)
> + G.707, G.783(virtual concatenation)
> + G.7042(LCAS)
>=20
> Thanx in advance
> Gopi
>=20
>=20
>=20
>=20

Delivery-date: Wed, 06 Nov 2002 08:50:12 -0800
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 17:40:52 +0100 

Gopi,

the sequence number always reflects the order of the VC-Ns within a =
virtual concatenation and is never provisioned directly. In a SDH/SONET =
environment with TMN provisioning and without LCAS the order is set by =
the TMN at the source and sink. If the sink receives sequence numbers =
in the wrong order it will alarm. With LCAS the order can change =
dynamical for example if one VC fails and is removed from the group and =
later on added again. In case of automatic path setup (GMPLS/ASON) this =
process has to define the order of the VCs and as such the sequence =
numbers.

Regards

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]]
> Gesendet: Mittwoch, 6. November 2002 14:58
> An: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked];
> [email-masked]
> Betreff: Virtual concatenation: a clarification on sequence numbers
>=20
>=20
> [ post by non-subscriber.  with the massive amount of spam,=20
> it is easy to
>   miss and therefore delete mis-posts.  so fix subscription=20
> addresses! ]
>=20
> hi..
>=20
> I was going through the thread
>         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
>         subject: "concatenation extensions in sonet/sdh"
>=20
> I needed a small clarification on virtual concatenation sequencing
>=20
> Sequence number is sent by the transmitter and receiver checks for
> the sequence number to perform interleaving.
>=20
>   IS this sequence number "Provisioned"(on both terminating=20
> equipments) ?
>    OR
>   Is it automatically assigned by the transmitting equipment in some
>   sequence and the receiver synchronizes with the=20
> transmitters sequence number?
>=20
>=20
> I read the following relevant standards on virtual=20
> concatenation, but couldn't
> clearly understand how the receiver knows the sequencing of the
> individual links.
> + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
>     Description including Multiplex Structure, Rates and Formats,
>     put up on ftp.t1.org/..../1X150620.DOC)
> + G.707, G.783(virtual concatenation)
> + G.7042(LCAS)
>=20
> Thanx in advance
> Gopi
>=20
>=20
>=20
>=20

Delivery-date: Wed, 06 Nov 2002 08:20:53 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Virtual concatenation: a clarification on sequence numbers
Date: Wed, 6 Nov 2002 08:12:13 -0800 

Hi Gopi, I'm not sure if this is the right place to ask the question. So let
me ask you a question back.  Are you talking about (1) the "internal"
sequence number that virtual concatenation uses to keep track of the
relative positions of the payloads?  Or (2) the time slot numbering of the
"component signals" in a virtually concatenated group?

(1) Is done in the hardware of a Path Termination Chip that originates the
Virtual concatenated group.  And hence not really a question for this forum.

(2) Indicating the timeslots used (to the other end) can be done with a
signaling protocol such as RSVP-TE.  The exact method for indicating which
signals are components of which virtual concatenation groups, hopefully is
explained in the new SDH/SONET extensions draft.

Greg B.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 5:58 AM
To: [email-masked]
Cc: [email-masked]; Bernstein, Greg; [email-masked];
[email-masked]
Subject: Virtual concatenation: a clarification on sequence numbers

hi..

I was going through the thread
        http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
        subject: "concatenation extensions in sonet/sdh"

I needed a small clarification on virtual concatenation sequencing

Sequence number is sent by the transmitter and receiver checks for
the sequence number to perform interleaving.

  IS this sequence number "Provisioned"(on both terminating equipments) ?
   OR
  Is it automatically assigned by the transmitting equipment in some
  sequence and the receiver synchronizes with the transmitters sequence
number?

I read the following relevant standards on virtual concatenation, but
couldn't
clearly understand how the receiver knows the sequencing of the
individual links.
+ T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
    Description including Multiplex Structure, Rates and Formats,
    put up on ftp.t1.org/..../1X150620.DOC)
+ G.707, G.783(virtual concatenation)
+ G.7042(LCAS)

Thanx in advance
Gopi

Delivery-date: Wed, 06 Nov 2002 07:57:38 -0800
Date: Wed, 6 Nov 2002 13:57:48 +0000 (GMT)
From: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Virtual concatenation: a clarification on sequence numbers

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

hi..

I was going through the thread
        http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
        subject: "concatenation extensions in sonet/sdh"

I needed a small clarification on virtual concatenation sequencing

Sequence number is sent by the transmitter and receiver checks for
the sequence number to perform interleaving.

  IS this sequence number "Provisioned"(on both terminating equipments) ?
   OR
  Is it automatically assigned by the transmitting equipment in some
  sequence and the receiver synchronizes with the transmitters sequence number?

I read the following relevant standards on virtual concatenation, but couldn't
clearly understand how the receiver knows the sequencing of the
individual links.
+ T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
    Description including Multiplex Structure, Rates and Formats,
    put up on ftp.t1.org/..../1X150620.DOC)
+ G.707, G.783(virtual concatenation)
+ G.7042(LCAS)

Thanx in advance
Gopi

Delivery-date: Wed, 06 Nov 2002 03:34:09 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-matsuura-reverse-lsp-01.txt
Date: Wed, 06 Nov 2002 06:29:30 -0500

--NextPart

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

	Title		: Signaling Reverse-directional LSP in Generalized MPLS
	Author(s)	: N. Matsuura, E. Oki
	Filename	: draft-matsuura-reverse-lsp-01.txt
	Pages		: 6
	Date		: 2002-11-5
	
Generalized MPLS extends the MPLS control plane to encompass 
bidirectional LSPs. This document defines related extensions to 
Generalized MPLS signaling to support the establishment of 
reverse-directional LSPs. This document presents a functional 
description of the extensions for signaling reverse-directional 
LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-matsuura-reverse-lsp-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-matsuura-reverse-lsp-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-matsuura-reverse-lsp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-matsuura-reverse-lsp-01.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, 06 Nov 2002 03:33:39 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-04.txt
Date: Wed, 06 Nov 2002 06:27:16 -0500

--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-04.txt
	Pages		: 79
	Date		: 2002-11-5
	
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-04.txt

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 05 Nov 2002 03:10:21 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-03.txt
Date: Tue, 05 Nov 2002 06:03:37 -0500

--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 Signaling - Implementation Survey
	Author(s)	: L. Berger, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-signaling-survey-03.txt
	Pages		: 101
	Date		: 2002-11-4
	
This document provides a survey of GMPLS signaling implementations.
The primary focus of this survey are the signaling protocol
mechanisms specified in the Generalized MPLS signaling documents.
Other specifications and documents are listed if included in the
submitted form.  The survey form and latest version of this document
are available from http://www.labn.net/gmpls-survey.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-03.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 05 Nov 2002 03:09:54 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-03.txt
Date: Tue, 05 Nov 2002 06:03:41 -0500

--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 Signalling Extensions for G.709 
                          Optical Transport Networks Control
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-g709-03.txt
	Pages		: 21
	Date		: 2002-11-4
	
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-03.txt

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--