Re: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

[Dimitri Papadimitriou <dpapadimitriou@psg.com>]

hi deborah,

since you ask fo comment/clarifications, imho your summary 
translates very precisely the current situation - it goes
really to the point - 

also concerning the ansi j1 format, i would suggest that 
you include this comment as part of the meeting response 

thanks,
- dimitri.


> 
> Bert,
> 
> Sorry for the late response, I was out for vacation and just catching =
> up.
> 
> Lacking a formal liaison process for IETF to communicate with T1X1/ITU =
> (hopefully we will have a process soon;-)), I think the best approach to =
> handle your request will be for me to upload the draft to the t1x15 =
> files. As we have a meeting next week, I will introduce the draft for =
> discussion and provide you with a response asap.
> 
> At our September meeting, Jonathan was able to attend and present the =
> IETF lmp bootstrap proposal. It was extremely helpful to have him there, =
> as we all know, the difference in our terminology can be fatal to =
> communication. Lacking LMP representation at next week's meeting, it =
> would be helpful to ensure we understand your request. My understanding =
> is your request is to understand if there are any issues with the use of =
> the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 =
> understand the application, I've summarized as follows. Please =
> comment/clarify if I have misunderstood.
> 
> - lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage GMPLS =
> control plane neighboring nodes. Management includes managing of the =
> GMPLS control channel and TE links (GMPLS control plane logical =
> constructs).
> 
> - LMP test messages are defined for link verification and correlation. =
> Two options are defined, one using the Jx bytes, the other using an =
> "out-of-band" trace correlation. The out-of-band trace correlation =
> (using the LMP control channel) has no impact on the Jx bytes, Jx use is =
> per the currently defined T1.105/G.707 Access Point Identifier =
> application. In addition, a trace monitor capability is defined to =
> detect mis-connections, this capability also uses the currently defined =
> G.707/G.783 Jx and trace mismatch process.
> 
> - "in-band" test messages using the Jx bytes are defined based on the =
> G.707 16-byte multi-frame. The test messages are used to identify GMPLS =
> links i.e. populate the GMPLS database as links available for use =
> (routing/signalling). This process is a pre-service application i.e. the =
> method is used to determine the available links to use for routing user =
> traffic (i.e. the links are not carrying user traffic during this test =
> phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an =
> "in-service" application.
> 
> - an earlier draft version included the 64-byte J1 format. Was it =
> intentionally or unintentionally deleted as part of the updates to =
> remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the =
> ANSI defined format. The 16-byte format support is considered optional =
> to support international applications.
> 
> - LMP link verification and correlation are GMPLS-specific i.e. =
> different application than the G.7714.1 layer adjacency discovery.
> 
> Thanks,
> Deborah
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Tuesday, March 18, 2003 6:13 PM
> To: Dimitri Papadimitriou; sjtrowbridge@lucent.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
> 
> 
> Dimitri says:
> > hi steve,
> > =20
> > > All,
> > > Bert asked me to have a look at this from an ITU-T perspective.
> >=20
> > what does that really mean ?
> >=20
> This means that I got an IETF document from one of the WGs for which
> I am the responsible AD. It also means that this document is about
> using SONET/SDH overhead bytes, which I think are under control of ITU.
> So I want to check for such type of documents if there are issues
> from the "owning SDO" with the proposed use of such overhead bytes
> 
> Seems to be doing due diligence on my part.
> 
> And since Steve is often (one of) the interface people from SG15
> to IETF (he is vice chair of SG15), that is why I asked him.
> 
> I also asked Deborah Brungard (T1X1) with the same question.
> 
> Hope this explains.
> Bert
> 
> 
>