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

[Lou Berger <[e-mail]>]

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 <[e-mail]> 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
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Monday, August 04, 2014 8:28 PM
> To: Leeyoung; CCAMP; [e-mail]
> 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.
>
> 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
>
> On 8/4/2014 7:00 PM, Leeyoung wrote:
> > 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:[e-mail]]
> > Sent: Monday, August 04, 2014 5:30 PM
> > To: Leeyoung
> > Cc: CCAMP; [e-mail]
> > 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?
> >
> > 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
> >
> > 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.")
> >>
> >> 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:[e-mail]]
> >> Sent: Monday, August 04, 2014 3:44 PM
> >> To: Leeyoung; CCAMP; [e-mail]
> >> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP
> >> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
> >>
> >> Young,
> >>
> >> On 8/4/2014 4:29 PM, Leeyoung wrote:
> >>> 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
> >> 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
> >> ....
> >>
> >>
> >>
> >
>
>