Subject: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

From: Lou Berger <[email-masked]>
Date: Sat, 02 Aug 2014 11:30:18 -0400

All, (WG, Authors, Young, Giovanni),
	It looks like an unintended encoding change made it into -08 of the
draft, or there remains some confusion in the intended encoding.  The
topic traces back to a discussion in March, see
http://www.ietf.org/mail-archive/web/ccamp/current/msg15894.html.  To
move forward, I'd like to ensure that the authors and any other
interested party, i.e., existing and future implementors, are on the
same page.

I'd like to focus on the intent and the what document should says as
opposed to how we got here, i.e., past confusion.  We need to ensure
that the draft accurately documents the Authors/WG intent.  I am not
trying to propose any technical changes at this very late date.

The area of the document in question is sections 4.2-4.4 and relates to
how the so called sub-TLVs are encoded and processed.  The key text in
question, from rev -07 is:
   To target a specific node, this section defines a WSON_Processing
   object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
   defined in [RSVP-RO].

Looking back on the -07 and the March mail thread, the "sub-TLVs"
defined in Section 4.3 and 4.4 should be carried as Attribute TLVs in
LSP_REQUIRED_ATTRIBUTES Objects, and not in ERO_HOP_ATTRIBUTE
Subobjects. Also that there actually is no WSON_Processing object
carried on the wire.

Authors, Young, Giovanni:

    Please confirm if this is correct.  If not, please clarify what was
    intended in the -07 rev of the document.

Assuming it is correct I think it remains unclear what it means for a
LSP_REQUIRED_ATTRIBUTES Object (and not an ERO_HOP_ATTRIBUTE subobject)
to "follows procedures defined in [RSVP-RO]."

Authors, Young, Giovanni:

   Can you clarify what specific procedures defined in [RSVP-RO] are
   to be applied to the LSP_REQUIRED_ATTRIBUTES Objects?

I think it should be possible to align the draft text fairly easily once
the intent is clear, and I'm happy/plan to propose specific text.

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Mon, 4 Aug 2014 20:29:04 +0000

Hi,

Lou, here's my comment on your comment. In a nutshell replacing [RSVP-RO] with [RFC5420] will solve the confusion. 

Please see in-line for details.

Thanks,

Young

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, August 02, 2014 10:30 AM
To: CCAMP; [email-masked]
Subject: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

All, (WG, Authors, Young, Giovanni),
	It looks like an unintended encoding change made it into -08 of the draft, or there remains some confusion in the intended encoding.  The topic traces back to a discussion in March, see http://www.ietf.org/mail-archive/web/ccamp/current/msg15894.html.  To move forward, I'd like to ensure that the authors and any other interested party, i.e., existing and future implementors, are on the same page.

I'd like to focus on the intent and the what document should says as opposed to how we got here, i.e., past confusion.  We need to ensure that the draft accurately documents the Authors/WG intent.  I am not trying to propose any technical changes at this very late date.

YOUNG>> Agree. 

The area of the document in question is sections 4.2-4.4 and relates to how the so called sub-TLVs are encoded and processed.  The key text in question, from rev -07 is:
   To target a specific node, this section defines a WSON_Processing
   object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
   defined in [RSVP-RO].

Looking back on the -07 and the March mail thread, the "sub-TLVs"
defined in Section 4.3 and 4.4 should be carried as Attribute TLVs in LSP_REQUIRED_ATTRIBUTES Objects, and not in ERO_HOP_ATTRIBUTE Subobjects. Also that there actually is no WSON_Processing object carried on the wire.

YOUNG>> Correct. It looks like there was a confusion between [RFC5420] and [RSVP-RO]. It seems that it makes no sense associating LSP_REQUIRED_ATTRIBUTES Object with [RSVP-RO] as [RSVP-RO] talks only about ERO_HOP_ATTRIBUTE subobject which is completely irrelevant with LSP_REQUIRED_ATTRIBUTES object. 

Assuming it is correct I think it remains unclear what it means for a LSP_REQUIRED_ATTRIBUTES Object (and not an ERO_HOP_ATTRIBUTE subobject) to "follows procedures defined in [RSVP-RO]."

YOUNG>> Yes. Please see my comment below. 

I think it should be possible to align the draft text fairly easily once the intent is clear, and I'm happy/plan to propose specific text.

YOUNG>> Replacing [RSVP-RO] with [RFC5420] will solve the problem discussed here. 

Thanks,
Lou

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Aug 2014 16:43:52 -0400

Young,
   
> Please see in-line for details.
So you are saying that Resource Block Information and Wavelength
Assignment Method are encoded end-to-end and *never* have
hop/node/interface specific meaning (as they are each encoded as an
Attribute TLV in an LSP_REQUIRED_ATTRIBUTE object), is this correct?

ARE YOU SURE?  

How do you envision the LSP_REQUIRED_ATTRIBUTE object conveying per-hop
information? (As discussed in section 3.2 and the first paragraph on
section 4.2.)

Lou
....

---

From: Leeyoung <[email-masked]>
Date: Mon, 4 Aug 2014 21:08:36 +0000

Hi Lou,

Since the LSP_REQUIRED_ATTRIBUTES object is meant to allow each transit node to inspect the TLV's under it, each transit node will inspect RBI or WA method and apply if it has relevance for the node; otherwise just pass to the next hop. (Section 5 of RFC 5420 has this clause: "This means that this object SHOULD only be
used for attributes that require support at some transit LSRs and so require examination at all transit LSRs.")

This may not be optimal but a way to get around technical changes as you pointed out not to do so at this moment. 

If we want this to be optimal and require technical changes to the draft, we can go with an alternative, utilizing [RSVP-RO] draft with ERO subobject/HOP Attributes to encode RBI or WA method as its TLVs. 

Whichever the WG wants, we can go either way. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, August 04, 2014 3:44 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,
   
> Please see in-line for details.
So you are saying that Resource Block Information and Wavelength Assignment Method are encoded end-to-end and *never* have hop/node/interface specific meaning (as they are each encoded as an Attribute TLV in an LSP_REQUIRED_ATTRIBUTE object), is this correct?

ARE YOU SURE?  

How do you envision the LSP_REQUIRED_ATTRIBUTE object conveying per-hop information? (As discussed in section 3.2 and the first paragraph on section 4.2.)

Lou
....

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Aug 2014 18:29:35 -0400

Young,
    Thanks for the quick response.  I "get" how WA method works, but am
less clear how Resource Block Information (e.g., Regeneration control
and  Attribute Conversion control) works per node. For example, how
would control of wavelength conversion at a particular node work?

Perhaps just running through this one simple case will help...

Again, as a reminder, the desire is to document existing intent rather
than redefining the solution.

Much thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Mon, 4 Aug 2014 23:00:26 +0000

Hi Lou,

Good point on RBI info! I can think of the RB Identifier (32 bit field) to imply the node/interface to which wavelength conversion would take place if we were to use LSP_REQUIRED_ATRIBUTES object. In other words, making the RB Identifier globally significant in a domain, per hop treatment of the RBs is possible. 

On the other hand, a better way to treat Resource Block Information seems to be using an alternative way (i.e., using HOP Attributes/ERO subobject per [RSVP-RO]). 

If making the RB ID globally significant creates a problem, we need to make some technical changes to the draft. Let me know what you think.

Regards,
Young 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, August 04, 2014 5:30 PM
To: Leeyoung
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,
    Thanks for the quick response.  I "get" how WA method works, but am less clear how Resource Block Information (e.g., Regeneration control and  Attribute Conversion control) works per node. For example, how would control of wavelength conversion at a particular node work?

Again, as a reminder, the desire is to document existing intent rather than redefining the solution.

Much thanks,
Lou

On 8/4/2014 5:08 PM, Leeyoung wrote:
> Hi Lou,
>
> Since the LSP_REQUIRED_ATTRIBUTES object is meant to allow each 
> transit node to inspect the TLV's under it, each transit node will 
> inspect RBI or WA method and apply if it has relevance for the node; 
> otherwise just pass to the next hop. (Section 5 of RFC 5420 has this 
> clause: "This means that this object SHOULD only be used for 
> attributes that require support at some transit LSRs and so require 
> examination at all transit LSRs.")
>
> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>
> Young,
>    
> How do you envision the LSP_REQUIRED_ATTRIBUTE object conveying 
> per-hop information? (As discussed in section 3.2 and the first 
> paragraph on section 4.2.)
>
> Lou
> ....
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Aug 2014 21:27:39 -0400

Young,
    I think the text is inconsistent (looking back on -07 and the
emails).  My primary focus / desire at this time is clarifying the
existing text without making any substantive technical changes. 

The narrative implies [RSVP-RO], but the editors' intent was
LSP_REQUIRED_ATRIBUTES object.  I personally (all hats off) think
LSP_REQUIRED_ATTRIBUTES object is right for WA method and [RSVP-RO] is
right for RBI.  With hats on, I'd like the text to reflect
implementations and the LC.

At this point it might be useful to hear from others in the WG.

WG/All/Authors/Contributors,
    Does anyone else care to weigh in?

Thanks,
Lou

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 4 Aug 2014 23:38:11 -0400

Hi,

I think that making the RB identifier globally unique in a domain is strong
constraint.
32 bit RB identifier were introduced to follow the unnumbered if id space,
allowing nodes  to use the same logic.
RB identifier space are more likely (and easily) locally-assigned ids, not
domain-globally aligned.
In addition this would make node configuration much more complicated, it
would be more error prone, and merging those administrative domains far for
seamless.

I agree with Lou that the required attributes are right for
LSP_REQUIRED_ATTRIBUTES (and could be considered for RSVP-RO, to force it
on a know transparent section). I see RBI using only RSVP-RO and not
LSP-REQUIRED-ATTRIBUTES for the reason mentioned above.

Cyril

On 4 August 2014 21:27, Lou Berger <[email-masked]> wrote:

> > Good point on RBI info! I can think of the RB Identifier (32 bit field)
> to imply the node/interface to which wavelength conversion would take place
> if we were to use LSP_REQUIRED_ATRIBUTES object. In other words, making the
> RB Identifier globally significant in a domain, per hop treatment of the
> RBs is possible.
> >
> > On the other hand, a better way to treat Resource Block Information
> seems to be using an alternative way (i.e., using HOP Attributes/ERO
> subobject per [RSVP-RO]).
> >
> > If making the RB ID globally significant creates a problem, we need to
> make some technical changes to the draft. Let me know what you think.
> >
> > Regards,
> > Young
> >
> > Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute
> Encoding in draft-ietf-ccamp-wson-signaling-08
> >
> > Young,
> less clear how Resource Block Information (e.g., Regeneration control and
>  Attribute Conversion control) works per node. For example, how would
> control of wavelength conversion at a particular node work?
> >
> >> This may not be optimal but a way to get around technical changes as
> you pointed out not to do so at this moment.
> >>
> >> If we want this to be optimal and require technical changes to the
> draft, we can go with an alternative, utilizing [RSVP-RO] draft with ERO
> subobject/HOP Attributes to encode RBI or WA method as its TLVs.
> >>
> >>> Lou, here's my comment on your comment. In a nutshell replacing
> [RSVP-RO] with [RFC5420] will solve the confusion.
> >>>

---

From: Leeyoung <[email-masked]>
Date: Thu, 7 Aug 2014 20:08:17 +0000

Hi Lou,

Based on Cyril's comment on RBI TLV, it is reasonable to think of its encoding using HOP Attribute TLV/ERO subobject per [RVSP-RO] which is the current text. 

If, however, we were to separate RBI TLV from WA method TLV (i.e, putting this under LSP_REQUIRED_ATTRIBUTES Object), this adds more changes on current implementation. For a distributed WA perspective (which is the case this draft is dealing with), WA method need not be an LSP-level attribute, especially around Resource Blocks (Wavelength Conversion). If we can accept this, I think we can encode WA method TLV as HOP Attribute TLV encoded as ERO subobject. This implies the current 08 text is fine with some consistency check. 

Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, August 04, 2014 8:28 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,
    I think the text is inconsistent (looking back on -07 and the emails).  My primary focus / desire at this time is clarifying the existing text without making any substantive technical changes. 

The narrative implies [RSVP-RO], but the editors' intent was LSP_REQUIRED_ATRIBUTES object.  I personally (all hats off) think LSP_REQUIRED_ATTRIBUTES object is right for WA method and [RSVP-RO] is right for RBI.  With hats on, I'd like the text to reflect implementations and the LC.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Aug 2014 07:08:17 -0400

Young,

Stating with the unintended change documented in v 08 is fine with me. I am 
a bit disappointed that we haven't heard from more wg participants. Perhaps 
we're suffering from August vacations...

I'll send some purposed changes to -08.

Lou

On August 7, 2014 4:08:51 PM Leeyoung <[email-masked]> wrote:

> Hi Lou,
>
> Based on Cyril's comment on RBI TLV, it is reasonable to think of its 
> encoding using HOP Attribute TLV/ERO subobject per [RVSP-RO] which is the 
> current text.
>
> If, however, we were to separate RBI TLV from WA method TLV (i.e, putting 
> this under LSP_REQUIRED_ATTRIBUTES Object), this adds more changes on 
> current implementation. For a distributed WA perspective (which is the case 
> this draft is dealing with), WA method need not be an LSP-level attribute, 
> especially around Resource Blocks (Wavelength Conversion). If we can accept 
> this, I think we can encode WA method TLV as HOP Attribute TLV encoded as 
> ERO subobject. This implies the current 08 text is fine with some 
> consistency check.
>
> Young
>
>     I think the text is inconsistent (looking back on -07 and the emails).  My 
>     primary focus / desire at this time is clarifying the existing text without 
>     making any substantive technical changes.
>
> right for RBI.  With hats on, I'd like the text to reflect implementations 
> and the LC.
>
> > On the other hand, a better way to treat Resource Block Information seems 
> to be using an alternative way (i.e., using HOP Attributes/ERO subobject 
> per [RSVP-RO]).
> >