Subject: Re: [CCAMP] g709 signaling discussion (was: comment on draft-ietf-ccamp-gmpls-g709-framework-06)

From: Lou Berger <[email-masked]>
Date: Tue, 12 Jun 2012 07:54:28 -0400

All,
    We had a follow up call with some of the G.709 authors and others
who expressed interest last Friday. The following are *my notes* from
the call as well as one correction based on e-mail from Sergio.  This
mail is to let others know what was discussed, and to move any
subsequent/resulting discussion to this list.

Lou

Attendees:

Sergio Belotti <[email-masked]>
Lou Berger <[email-masked]>
Daniele Ceccarelli <[email-masked]>
Cyril Margaria <[email-masked]>
Khuzema Pithewan <[email-masked]>
Zhangxian (Xian) <[email-masked]>

Topic 1: How to represent TSG?

- Authors stated TSG is needed for penultimate hop outgoing
  interface selection by path computation / loose ERO expansion

- This means G-PID is not the right choice

- Simply using PT values doesn't work as of the ODU0/OPU1 case
  (see G.709 Table 7-10)

- Agreed upon approach: Have Encoding Type represent AMP & GMP.
  o Per G.709 Table 7-10, when combined with signal type, can
    understand TSG.
  o Existing type 12 (from rfc4328) will represents AMP
  o A new type will be assigned from IANA (15?) to represent GMP

[After the call Sergio pointed out that there is one case where AMP
 is ambiguous -- ODU2/OPU3 so now considering to per PT values]

- Sergio had an open question:
  Is a type needed to represent both 1.25 & 2.5 TSG, i.e., is
  there a case where AMP/GMP is changed after LSP establishment?

  Action: Authors/all to consider question. (presumed answer is no.)

Topic 2: How to represent G.709 Payload Types (See Table 15-8)?

- Agreed that PT should be represented in G-PID.  This follows
  the approach taken by RFC4328 section 3.1.3.

- Lou had an open question:
  Are there any missing G-PID values based on G.709 (see
  Table 15-18)?

  Action: Authors/all to consider question.
          (Authors must confirm.)

Topic 3: ADAPTATION Object

- Agreed Type=1 is no longer needed

- Agreed Type 2 applies to H-LSPs when H-LSPs/LSPs
  terminate on same egress.

- Authors will add an example in the routing draft for
  such a case, and will be referenced by signaling draft

- Agreed that the draft scope is intra-layer hierarchy,
  inter-layer is MLN. (Based on discussion on interface
  selection based on client adaptation.)

- Agreed that Mapping field will be replaced by a reserved
  field

- Lou had an open question:
  Can the Hierarchy TLV be carried in an existing object,
  e.g., LSP_REQUIRED_ATTRIBUTES Object?

  Action: Authors/all to consider question.

On 5/24/2012 10:06 AM, Lou Berger wrote:
> Daniele,
> 	Given the number of authors involved in the thread and us clearly not
> quickly converging, perhaps it's time for a higher bandwidth exchange.
> I propose that we setup a conference call to discuss and report back our
> conclusion to the list.  I'll contact the authors off-list to coordinate
> (if anyone else wants to join the phone call, just drop me or the
> authors mail.)
> 
> Lou
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 13 Jun 2012 15:08:37 +0200

Hi Lou,

Just one comment on the utilization of the Encoding type for AMG/GMP configuration. When we agreed on using Exising type 12 for AMP and a new code for GMP we didn't take into account this MUST from RFC4328.

   A transit or an egress node (receiving a Path
   message containing a GENERALIZED_LABEL_REQUEST object) MUST generate
   a PathErr message, with a "Routing problem/Unsupported Encoding"
   indication, if the requested LSP Encoding Type cannot be supported on
   the corresponding incoming interface.

I'm not sure we can still use the Encoding type.

BR
Daniele

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Lou Berger
>Sent: martedì 12 giugno 2012 13.54
>To: CCAMP
>Cc: [email-masked]
>Subject: Re: [CCAMP] g709 signaling discussion (was: comment 
>on draft-ietf-ccamp-gmpls-g709-framework-06)
>
>
>All,
>    We had a follow up call with some of the G.709 authors and 
>others who expressed interest last Friday. The following are 
>*my notes* from the call as well as one correction based on 
>e-mail from Sergio.  This mail is to let others know what was 
>discussed, and to move any subsequent/resulting discussion to 
>this list.
>
>Lou
>
>Attendees:
>
>Daniele Ceccarelli <[email-masked]> Cyril 
>Margaria <[email-masked]> Khuzema Pithewan 
><[email-masked]> Zhangxian (Xian) <[email-masked]>
>
>[After the call Sergio pointed out that there is one case 
>where AMP  is ambiguous -- ODU2/OPU3 so now considering to per 
>PT values]
>
>> I propose that we setup a conference call to discuss and report back 
>> our conclusion to the list.  I'll contact the authors off-list to 
>> coordinate (if anyone else wants to join the phone call, 
>just drop me 
>> or the authors mail.)
>> 
>> Lou
>> 
>_______________________________________________
>CCAMP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Jun 2012 09:42:23 -0400

Daniele,
	This depends on how one reads "support".  Sure, a transit node may not
support 1.25 TSG (or GMP) *termination*, but it does support it for
transit signals/LSPs.  So, I don't see any issue with meeting the
encoding requirement on a transit node.  BTW transit nodes not
supporting termination of an LSP's encoding type is certainly not a new
issue/fature for GMPLS...

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 14 Jun 2012 06:06:09 +0000

Hi Lou,

In RFC3471, it says that LSP Encoding Type "indicates the encoding of the LSP being requested".  In my understanding, this encoding type should be end-to-end constraint, ie., every node along this "LSP" should support the requested encoding type. For example, when an LSP is being created with the requested encoding type X, all the nodes MUST support the encoding type X as what RFC4328 says, otherwise, the creation request should be denied.

Therefore, I am not sure what is meaning of this sentence "a transit node may not support 1.25 TSG (or GMP) *termination*, but it does support it for transit signals/LSPs.". 

Could you clarify further or give an example to explain that?

Thanks

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2012年6月13日 21:42
收件人: Daniele Ceccarelli
抄送: CCAMP; [email-masked]
主题: Re: [CCAMP] g709 signaling discussion

Daniele,

Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Jun 2012 06:32:58 -0700

Fatai,

I agree with you that LSP Encoding type is an end-to-end constraint.

Thanks,

John  

Sent from my iPhone

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Fatai Zhang
>Sent: Wednesday, June 13, 2012 11:06 PM
>To: Lou Berger; Daniele Ceccarelli
>Cc: CCAMP
>Subject: [CCAMP] 答复: g709 signaling discussion
>
>Hi Lou,
>
>In RFC3471, it says that LSP Encoding Type "indicates the encoding of
>the LSP being requested".  In my understanding, this encoding type
>should be end-to-end constraint, ie., every node along this "LSP" should
>support the requested encoding type. For example, when an LSP is being
>created with the requested encoding type X, all the nodes MUST support
>the encoding type X as what RFC4328 says, otherwise, the creation
>request should be denied.
>
>Therefore, I am not sure what is meaning of this sentence "a transit
>node may not support 1.25 TSG (or GMP) *termination*, but it does
>support it for transit signals/LSPs.".
>
>	This depends on how one reads "support".  Sure, a transit node may
>not support 1.25 TSG (or GMP) *termination*, but it does support it for
>> Just one comment on the utilization of the Encoding type for AMG/GMP
>configuration. When we agreed on using Exising type 12 for AMP and a new
>code for GMP we didn't take into account this MUST from RFC4328.
>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Lou Berger
>>> Subject: Re: [CCAMP] g709 signaling discussion (was: comment on
>>> draft-ietf-ccamp-gmpls-g709-framework-06)
>>>
>>>
>>> All,
>>> Daniele Ceccarelli <[email-masked]> Cyril Margaria
>>> <[email-masked]> Khuzema Pithewan <[email-masked]>
>>> - Simply using PT values doesn't work as of the ODU0/OPU1 case  (see
>>> G.709 Table 7-10)
>>>
>>>  o Existing type 12 (from rfc4328) will represents AMP  o A new type
>>> will be assigned from IANA (15?) to represent GMP
>>>
>>>  Is a type needed to represent both 1.25 & 2.5 TSG, i.e., is  there a
>>> case where AMP/GMP is changed after LSP establishment?
>>>
>>> - Agreed that PT should be represented in G-PID.  This follows  the
>>> approach taken by RFC4328 section 3.1.3.
>>>
>>>  Are there any missing G-PID values based on G.709 (see  Table
>>> 15-18)?
>>>
>>> - Agreed Type 2 applies to H-LSPs when H-LSPs/LSPs  terminate on same
>>> egress.
>>>
>>> - Authors will add an example in the routing draft for  such a case,
>>> and will be referenced by signaling draft
>>>
>>> - Agreed that the draft scope is intra-layer hierarchy,  inter-layer
>>> is MLN. (Based on discussion on interface  selection based on client
>>> adaptation.)
>>>
>>> - Agreed that Mapping field will be replaced by a reserved  field
>>>
>>>  Can the Hierarchy TLV be carried in an existing object,  e.g.,
>>> LSP_REQUIRED_ATTRIBUTES Object?
>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Jun 2012 09:54:16 -0400

Fatai,

On 6/14/2012 2:06 AM, Fatai Zhang wrote:
> should be end-to-end constraint, ie., every node along this "LSP"
> should support the requested encoding type.
>
> For example, when an LSP
> is being created with the requested encoding type X, all the nodes
> MUST support the encoding type X as what RFC4328 says, otherwise, the
> creation request should be denied.
> 

Sure. As I said in my previous mail.  Support for transit is not the
same as support for termination.  Consider the case of an STM-64 carried
over a lambda over a WDM network.  Nothing precludes the ingress
signaling the LSP as SDH encoded, and the WDM network transparently
(from the SDH perspective) carrying the signal across the WDM links.

As RFC 3471 says:

   The Generalized Label Request carries an LSP encoding parameter,
   called LSP Encoding Type.  This parameter indicates the encoding
   type, e.g., SONET/SDH/GigE etc., that will be used with the data
   associated with the LSP.  The LSP Encoding Type represents the nature
   of the LSP, and not the nature of the links that the LSP traverses.

Keep in mind that the control plane just automates setup of the data
plane.  If the data plane can 'support' something the control plane
should also 'support' it.

Rather than talking theory, let's try to be specific:

What data plane case(s) are you concerned about?

What information is missing from the control messages to
setup/modify/etc, i.e., 'support', the data plane?

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 15 Jun 2012 08:12:38 +0000

Hi Lou,

Please see in-line below.

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2012年6月14日 21:54
收件人: Fatai Zhang
抄送: Daniele Ceccarelli; CCAMP
主题: Re: 答复: [CCAMP] g709 signaling discussion

Fatai,

> In RFC3471, it says that LSP Encoding Type "indicates the encoding of the LSP being requested".  In my understanding, this encoding type should be end-to-end constraint, ie., every node along this "LSP" should support the requested encoding type.

> For example, when an LSP is being created with the requested encoding type X, all the nodes MUST support the encoding type X as what RFC4328 says, otherwise, the

Sure. As I said in my previous mail.  Support for transit is not the same as support for termination.  Consider the case of an STM-64 carried over a lambda over a WDM network.  Nothing precludes the ingress signaling the LSP as SDH encoded, and the WDM network transparently (from the SDH perspective) carrying the signal across the WDM links.

[Fatai] I assume that you are talking about multi-layer scenario. When an SDH LSP is being created, every node should support SDH encoding type (encoding type =5 SDH ITU-T G.707) from SDH layer perspective no matter what server layer will be transmitted over. Regarding SDH over lambda case, if an SDH LSP needs to be carried over a lambda, a lambda LSP(FA-LSP) should be created with the requested encoding type = 8 Lambda (every node along this lambda LSP should support lambda encoding) before this SDH LSP (with encoding type = SDH) establishment is completed.

As RFC 3471 says:

The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP.  The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses.

[Fatai] Understood.

Keep in mind that the control plane just automates setup of the data plane.  If the data plane can 'support' something the control plane should also 'support' it.

What information is missing from the control messages to setup/modify/etc, i.e., 'support', the data plane?

[Fatai] Nothing is missed. I think the discussion is about where to carry the original TSG/PT information. As I said in another email, the TSG/PT information is the capability of the server layer (FA-LSP that is being created) that exports to its client layer (e.g, an ODU2 FA-LSP is being created to support subsequent ODU1s with TSG=1.25Gbps) and it only makes sense to the end points and penultimate hop of the FA-LSP (ie., TSG/PT should be transparent to the other transit nodes of the FA-LSP). Based on the role of the TSG/PT information, I suspect the Encoding Type is not the right place to carry the equivalent TSG/PT information, because I think Encoding type is an end-to-end constraint (at FA-LSP specific layer) (ie., the Encoding type should be supported by all the nodes instead of some of the nodes (e.g, end points and of penultimate hop) of the FA-LSP).

Lou

>>>>       Given the number of authors involved in the thread and

>>> us clearly not

>>>> quickly converging, perhaps it's time for a higher bandwidth

>>> exchange.

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 15 Jun 2012 10:44:30 +0200

Hi all,

I think what Fatai is going to stress is the basic assumption that bring us (as co-authors) to propose another way to carry TSG/PT info .
Also my understanding of Encoding Type was that, how to carry a payload (the sense of Encoding ) has to be checked along all the path and not only in penultimate/end points.
As explained by Fatai (and described in the g709INFO draft) the TSG/PT  information has a double face: one is the TSG used itself by the server at the creation , the other is what “provided” towards clients.
This information is needed to permit the right correspondence at the end points of the specific adaptation for the client LSP.
So , when the server exports this information ,this information does not need to be checked along the entire path. In the Encoding Field there will be information regarding “his nature” , that is not the type of information as TSG/PT.

So, it seems as though another type of construct should be more conceivable and correct to carry this info.

Thanks

Sergio

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Fatai Zhang
Inviato: venerdì 15 giugno 2012 10.13
A: Lou Berger
Cc: CCAMP
Oggetto: [CCAMP] 答复: 答复: g709 signaling discussion

Hi Lou,

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2012年6月14日 21:54
收件人: Fatai Zhang
抄送: Daniele Ceccarelli; CCAMP
主题: Re: 答复: [CCAMP] g709 signaling discussion

Fatai,

As RFC 3471 says:

[Fatai] Understood.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Jun 2012 08:47:45 -0400

So much for having a conference call to resolve issues.

This really shouldn't be that hard. As I mentioned in my previous
message (and on the call) our control plane representation/modeling
should follow the data plane.

If TSG is an attribute of signal encoding on *any* link, encoding type
is perfectly reasonable place to carry the information.

If TSG is purely an issue of adaptation, than I suspect it really is an
MLN issue.

you said:

> [Fatai] Nothing is missed. I think the discussion is about where to
> carry the original TSG/PT information. As I said in another email, the
> TSG/PT information is the capability of the server layer (FA-LSP that is
> being created) that exports to its client layer (e.g, an ODU2 FA-LSP is
> being created to support subsequent ODU1s with TSG=1.25Gbps) and it only
> makes sense to the end points and penultimate hop of the FA-LSP (ie.,
> TSG/PT should be transparent to the other transit nodes of the FA-LSP).

So, let's try to understand this a bit deeper.  What is happening *in
the data plane* on the penultimate link that it needs to understand TSG?

Lou

On 6/15/2012 4:12 AM, Fatai Zhang wrote:
> support the requested encoding type.
> 
>>  
> 
>> For example, when an LSP is being created with the requested encoding
> type X, all the nodes MUST support the encoding type X as what RFC4328
> says, otherwise, the
> 
> [Fatai] I assume that you are talking about multi-layer scenario. When
> an SDH LSP is being created, every node should support SDH encoding type
> (encoding type =5 SDH ITU-T G.707) from SDH layer perspective no matter
> what server layer will be transmitted over. Regarding SDH over lambda
> case, if an SDH LSP needs to be carried over a lambda, a lambda
> LSP(FA-LSP) should be created with the requested encoding type = 8
> Lambda (every node along this lambda LSP should support lambda encoding)
> before this SDH LSP (with encoding type = SDH) establishment is completed.
> 
>  
> 
> As RFC 3471 says:
> 
>  
> 
> The Generalized Label Request carries an LSP encoding parameter, called
> LSP Encoding Type. This parameter indicates the encoding type, e.g.,
> SONET/SDH/GigE etc., that will be used with the data associated with the
> LSP.  The LSP Encoding Type represents the nature of the LSP, and not
> the nature of the links that the LSP traverses.
> 
>  
> 
> [Fatai] Understood.
> 
>  
> 
> [Fatai] Nothing is missed. I think the discussion is about where to
> carry the original TSG/PT information. As I said in another email, the
> TSG/PT information is the capability of the server layer (FA-LSP that is
> being created) that exports to its client layer (e.g, an ODU2 FA-LSP is
> being created to support subsequent ODU1s with TSG=1.25Gbps) and it only
> makes sense to the end points and penultimate hop of the FA-LSP (ie.,
> TSG/PT should be transparent to the other transit nodes of the FA-LSP).
> Based on the role of the TSG/PT information, I suspect the Encoding Type
> is not the right place to carry the equivalent TSG/PT information,
> because I think Encoding type is an end-to-end constraint (at FA-LSP
> specific layer) (ie., the Encoding type should be supported by all the
> nodes instead of some of the nodes (e.g, end points and of penultimate
> hop) of the FA-LSP).
> 
>  
> 
>  
> 
> Lou
> 
>  
> 
>>
> 
>>
> 
>>
> 
>> Thanks
> 
>>
> 
>> Fatai
> 
>>
> 
>>
> 
>> -----邮件原件-----
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Jun 2012 08:52:02 -0400

The only check required is that the encoding type can be supported in
the context of the LSP request, which is based on the node's role in
handling the LSP.  So "support" requirements can be completely different
for transit nodes than for edge/2nd/penultimate nodes.

Lou

On 6/15/2012 4:44 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Also my understanding of Encoding Type was that, how to carry a payload
> (the sense of Encoding ) has to be checked along all the path and not
> only in penultimate/end points.

---

From: John E Drake <[email-masked]>
Date: Fri, 15 Jun 2012 05:59:40 -0700

Fatai,

Snipped, comment inline.

Thanks,

John

Sent from my iPhone

JD:  The Encoding Type of ‘Photonic’ is meant to have a special meaning which is that because it is transparent, it supports a multiplicity of digital encoding schemes.  (One of the early GMPLS RFCs mentions this, but I can’t remember which.)

So, if you are dedicating an entire lambda  to an SDH LSP, there is no need to bring up a hierarchical lambda LSP whose endpoints support SDH switching.  Rather, the SDH LSP can be directly routed over links (more precisely interfaces) whose Encoding Type is ‘Photonic’ and whose ‘Switching Capability’ is ‘Lambda’.  This was routinely done when I was at Calient.

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 18 Jun 2012 01:22:32 +0000

Hi Lou,

Yes, you got it. 

This is why the authors used "ADAPTATIOPN" object and described how to use this object for FA-LSP creation in Section 7.

======================================================================================================
If TSG is purely an issue of adaptation, than I suspect it really is an MLN issue.

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2012年6月15日 20:48
收件人: Fatai Zhang
抄送: Daniele Ceccarelli; CCAMP
主题: Re: 答复: 答复: [CCAMP] g709 signaling discussion

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 18 Jun 2012 09:21:50 +0200

Hi Lou,

In fact this is why during our call we treid to explain that ADAPTATION object has the purpose  to be not only specific to OTN but used in the context of multi-layer /multi-technology . 
You remember discussion about not OTN fields. 

Thanks

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Fatai Zhang
Inviato: lunedì 18 giugno 2012 3.23
A: Lou Berger
Cc: CCAMP
Oggetto: [CCAMP] 答复: 答复: 答复: g709 signaling discussion

Hi Lou,

Yes, you got it. 

Thanks

Fatai

-----邮件原件-----
发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2012年6月15日 20:48
收件人: Fatai Zhang
抄送: Daniele Ceccarelli; CCAMP
主题: Re: 答复: 答复: [CCAMP] g709 signaling discussion

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Jun 2012 08:20:47 -0400

Sergio,
	see below.

> You remember discussion about not OTN fields. 

Right.  And we agreed that non-OTN MLN will be handled as MLN without
OTN-specific additions.  One of the other authors (Daniele) also
mentioned that there is another draft forthcoming on the topic.

To me, speaking as a WG contributor, there are really two possible
directions to take from the technical perspective:
1) Treat the intra-OTN (hierarchy) case as MLN
2) Bundle some upper OTN hierarchy information as part of a lower H-LSPs

I'm conflicted on this point.  I/some of us went down the path of 2 in
the early days of GMPLS as part of our implementation and, while
expedient, it really had long term drawbacks as compared to a clean
MLN/hierarchy solution.  That said, there seems to be support in the WG
for some form intra-OTN "optimization".

Assuming we're going down the path of 2, I think the approach from the
conference call is a reasonable middle ground, i.e.,
A) TSG represented in LSP encoding
B) higher level OTN (only) information carried when signaling an H-LSP
   (preferably in an existing object).

And this *is* a compromise position.  From a GMPLS-purest standpoint,
IMO this approach is co-mingling layers.

With respect to the concern raised by Fatai on LSP Encoding Type.  IMO a
node's support for a specific encoding type value has always had to be
determined in the context of the node's role (transit vs non-transit/PH)
as well as the switching type.  This is consistent with fielded GMPLS
implementations, the RFC text I previously quoted, and John's mail.  You
can also make this point explicit in the g709v3 document. So, I do *not*
agree that the proposed representation of TSG in LSP Encoding Type is
incompatible with the definition of the field.

There may be some other issue I missed, if so, please raise it!

Otherwise I propose that the WG move forward with the "A+B" approach as
the solution for an integrated-OTN "2" direction. Alternatively, and if
the author's prefer, I suggest revisiting a more traditional MLN-based
solution for intra-OTN hierarchy, i.e., a "1" type direction.

Lou (as WG contributor)