[CCAMP] R: A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

Hi Lou,

For question 1)

TSG is an adaptation information that has meaning only in the context of OTN multiplexing. Nothing to do with G-PID that obviously has to carry information regarding client so, ODUj. Moreover TSG information could not be done with G-PID, because this TSG information only makes sense to the penultimate hop and G-PID cannot specify 1.25 or 2.5G so far. In this case,47 (ODUj) will be carried in G-PID.

For question 2)

Hierarchy information has been introduced to help penultimate hop (always in case ERO information are not exhaustive) choosing the right interface e.g. two interfaces supporting both the correct TSG but not the same client hierarchy. This added information is used to guarantee the possibility about the correct multiplexing/demultiplexing process.

G-PID at the moment consider a number of codes that does not cover all the different “mapping” used for the same carried payload e.g. typical example is 10Gb Eth. So we added Swtiching Cap and Encoding information like the OTN layers + adaptation field , in order to better distinguish also the client OTN layer. Exploiting on the G-PID, can bring two problems:

a)    We would need to add G-PID information inside the new Type new object , having a not-homogeneous  format with respect the other layers.

b)    As said before, it wouldn’t be exhaustive with respect real mapping beyond the same payload.

Best Regards

Sergio and Daniele 

-----Messaggio originale-----
Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger
Inviato: martedì 17 aprile 2012 13.48
A: Fatai Zhang
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Oggetto: Re: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

Fatai,
	See below.

On 4/17/2012 5:34 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> Great points.
> 
> For point 1, the Adaption object in this draft is used to carry only
> OTN specific information that is needed to create an ODU FA-LSP to
> carry one specific ODU signal,

Well I can see this for Type 2 (Hierarchy signaling), but for FA/H-LSP +
Type 1 (Server TSG signaling) it seems that the same could be done with
G-PID.  If you disagree, what do you expect to carry in G-PID in the ODU
H-LSP case?

> but the other payload types (ie. other
> information in the table 15-8) should be still carried in G-PID as
> defined in RFC3471.

So what does it mean in a type 2 TLV to have a "non OTN signal types"
and GFP mappings?  It seems that these both cover cases beyond ODU
H-LSPs, am I wrong?

Lou

> 
> For point 2, good suggestion. I just checked RFC4420, I agree with
> you that it is better to put this information in LSP attributes,
> which is used to signal attributes required in   support of an LSP,
> or to indicate the nature or use of an LSP where that information is
> not required to be acted on by all transit LSRs.
> 
> 
> 
> 
> Thanks
>  
> Fatai
> 
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 2012年4月16日 22:56
> To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> Cc: CCAMP
> Subject: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02
> 
> Authors,
> 
> This message is a follow on to the discussion that we started to have in
> Paris on the ADAPTATION Object.  I have two comments, the second of
> which I didn't have time (during the presentation time period) to make:
> 
> 1) Can you explain/justify why you are proposing carrying a subset of
> the Payload type code points defined in G.709 (see Table 15-8) in the
> ADAPTATION Object, but not others?
> 
> I'm not questioning the need for an end-to-end adaptation check, but
> rather an apparent incomplete method for supporting this check.
> 
> 2) Given the very limited number of remaining RSVP c-type values, I'm
> struggling with justifying the definition of the new, perhaps not very
> generic, ADAPTATION Object rather than carrying this information in an
> existing (and more generic) object.  Have you considered carrying this
> information elsewhere, e.g., LSP attributes, and if so what's your
> thinking for not using such?
> 
> Lou (As WG participant)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp