Re: [CCAMP] Updates on OTN signaling draft

[Lou Berger <[e-mail]>]

[Woops, this was stuck in my outbox from last week!]

Fatai/Authors,
	G-PID is a fine place to carry information about the format/type of
information carried by an LSP. An important consideration is that G-PID
information is not used as part of path computation, and is not used by
transit nodes except in the case of the penultimate hop (for PHP).

When we last discussed this, some authors stated that TSG was needed as
part of path computation, including at transit nodes doing loose ERO
expansion.  Hence the discussed inclusion of TSG in LSP Encoding Type.
If the authors are now willing to state that TSG isn't needed for loose
ERO expansion, then G-PID seems the perfect choice.

Do all the authors agree with such this statement (and change)?

As I mentioned on the on the conference call, and my mail of 6/18, the
use of G-PID as part of a path selection is really part of the general
issue seen in MLN. On the call we agreed that non-OTN MLN will be
handled as the standard MLN case, without OTN-specific additions.

Unless I'm misreading your mail, you are *not* proposing to treat the
intra-OTN (hierarchy) case as generic MLN but rather a special case by
bundling some upper OTN hierarchy information as part of a lower H-LSPs
(in Hierarchy TLV).

Correct?

If my reading is correct, then I think the authors need to discuss their
technical reasons for their "preference" and why the previously reached
compromise position (as articulated in my mail of 6/18) is not acceptable.

Speaking only as an individual contributor, given the difficulty in
reaching a consensus on how to treat intra-OTN (hierarchy) as a special
case, I personally now prefer to avoid any technology specific
co-mingling of layers and to address the intra-OTN (hierarchy) case via
generic MLN (or other generic mechanisms).  I think this position would
translate to removing the Hierarchy TLV from the OTN signaling draft and
spinning up a new draft to cover (OTN and generic) intra-technology MLN.

Lou

On 7/5/2012 9:25 PM, Fatai Zhang wrote:
> 
> Hi all,
> 
> We are updating OTN signaling draft. Since we had lots of discussion on
> the TSG stuff in the list, let's converge on the solution.
> 
> Based on the previous discussion between Lou and co-authors, the authors
> prefer the following changes:
> 
> (1) Extending GPID to carry TSG in signaling, since its purpose in
> signaling is to ensure that endpoints of the LSP being signaled have a
> consistent view of the TSG to be offered to its clients and LSP endpoint
> consistency is the purpose for which the GPID was designed.
> 
> (2)Extending LSPA to carry hierarchy information (ie., Type=2 -
> Hierarchy TLV).
> 
> Any comments?
> 
> Thanks
> 
> Fatai