Subject: [CCAMP] Merging of the WSON specific OSPF extensions

From: Young Lee <[email-masked]>
Date: Thu, 28 Oct 2010 11:50:12 -0500

Hi Pierre, 

This email is to discuss the pending issues in regard to merging two drafts
that discusses WSON specific OSPF extensions: 

Currently we have one WG draft:

http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/.

And your individual draft:

http://datatracker.ietf.org/doc/draft-peloso-ccamp-wson-ospf-oeo/

We are more than happy to incorporate any new addition from your draft into
the aforementioned existing WG draft. Let me summarized the key issues we
need to discuss in the following: 

*	I think we agreed on the encoding of the TLV's that are necessary
for WSON specific information according to:
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ 

*	Let me try to understand your rationale to create a new Top Level
RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to
differentiate dynamic information from static. But I don't see your original
rationale in your revision. If that is still an implicit rationale, you need
to clearly state that. 

*	If so, Fatai's draft clearly state the way to differentiate dynamic
info from static info using an Opaque LSA mechanism discussed in Section 4
of
http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/.
In such as, we don't need to create a new TOP Level TLV. 

*	If not, I am still not sure why we need a new TOP TLV. 

*	Why not just use the Top Level OSPF TE LSA node attribute TLV which
is existing TOP level TLV?  Please let me know why this TLV would not be
proper? 

*         Our approach is to RE-use the OSPF TE LSA node attribute TLV under
which we define all the necessary sub-TLVs. 
 
*         I still have some problem as to why you still have these sub-TLV:

Sub-TLV Type       Length     Name

     TBD        4 Bytes    TE-metric [alike RFC3630]

     TBD        4 Bytes    Administrative Group [alike RFC3630]

     TBD        8 Bytes    Link Local/Remote Identifiers [alike RFC4203]

     TBD        variable   Shared Risk Link Group [alike RFC4203]

*         Section 2.4 is not clear to me.  You didn't include sub-TLV in
Section 2.  Are you saying that connectivity matrix is a part of your RBA
TLV? How is this connectivity matrix different from the one defined in
section 3.5 in
http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/
? 
 
Regards,
Greg & Young

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 29 Oct 2010 17:53:44 +0800

Hi Pierre and Young,

A few points for clarifciation.

There are three OSPF drafts related to WSON:

(1) draft-ietf-ccamp-wson-signal-compatibility-ospf
(2) draft-peloso-ccamp-wson-ospf-oeo/
(3) draft-zhang-ccamp-general-constraints-ospf-ext 

For (1) and (2), they are talking about WSON specific routing stuff, which (should) follow [WSON-Encode]. For (3), it is generic stuff, which follows [General-Encode].

So, to make things clear, I think we can divide the issues into two pieces. 

(1) Is there anything missed in [WSON-Encode] and [General-Encode]? 

     If yes, then list what is missed and go to these encoding drafts to refine them. 
     
     If no, then we go to (2).

(2) Follow the [WSON-Encode] and [General-Encode] drafts to define protocol 

Does [draft-ietf-ccamp-wson-signal-compatibility-ospf] follow [WSON-Encode]? What is missed? 
Does [draft-peloso-ccamp-wson-ospf-oeo] follow [WSON-Encode]? What should be added to  [draft-ietf-ccamp-wson-signal-compatibility-ospf]?

Does [draft-zhang-ccamp-general-constraints-ospf-ext] follow [General-Encode]? 

Yes. What else should be refined?

Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: Young Lee 
  To: 'CCAMP' 
  Sent: Friday, October 29, 2010 12:50 AM
  Subject: [CCAMP] Merging of the WSON specific OSPF extensions

  Hi Pierre, 

  This email is to discuss the pending issues in regard to merging two drafts that discusses WSON specific OSPF extensions: 

We are more than happy to incorporate any new addition from your draft into the aforementioned existing WG draft. Let me summarized the key issues we need to discuss in the following:  

    a.. I think we agreed on the encoding of the TLV's that are necessary for WSON specific information according to: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ 

    a.. Let me try to understand your rationale to create a new Top Level RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to differentiate dynamic information from static. But I don't see your original rationale in your revision. If that is still an implicit rationale, you need to clearly state that. 

      a.. If so, Fatai's draft clearly state the way to differentiate dynamic info from static info using an Opaque LSA mechanism discussed in Section 4 of http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/. In such as, we don't need to create a new TOP Level TLV. 

      a.. If not, I am still not sure why we need a new TOP TLV. 

        a.. Why not just use the Top Level OSPF TE LSA node attribute TLV which is existing TOP level TLV?  Please let me know why this TLV would not be proper? 

·         Our approach is to RE-use the OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs.  ·         I still have some problem as to why you still have these sub-TLV: Sub-TLV Type       Length     Name

·         Section 2.4 is not clear to me.  You didn't include sub-TLV in Section 2.  Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ ?  Regards,Greg & Young 

------------------------------------------------------------------------------

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