Re: [CCAMP] WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints

[Acee Lindem <[e-mail]>]

Hi Young,

Looks good for this draft - one question on GEN-ENCODE. See inline.

On 1/30/14 4:17 PM, "Leeyoung" <[e-mail]> wrote:

>Hi Acee,
>
>Thanks for providing valuable comments. Please see inline for my response.
>
>Best Regards,
>
>Young
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Acee Lindem
>Sent: Tuesday, October 29, 2013 10:13 AM
>To: CCAMP
>Subject: [CCAMP] WG Last Call Comments on OSPF-TE Extensions for General
>Network Element Constraints
>
>I have the following comments on the subject drafts:
>
>       1. State explicitly why the general constraint encoding is broken
>off into a separate drafts. At first, it seems the decision is arbitrary
>but I guess it is to allow the same encoding to apply to OSPF, ISIS, and
>PCEP. 
>
>YOUNG>> Actually we have two separate encoding drafts: (i) WSON encoding;
>(ii) Generic encoding. This was a decision made by CCAMP WG. WSON
>encoding is basis for specific enhancements for optical related
>properties while Generic encoding is basis for generalized constraints
>such as connectivity and port constraints. In the latest draft, we have
>the following statements in the introduction of
>draft-ietf-ccamp-gmpls-general-constraints-ospf-te:
>
>"[GEN-Encode] provides efficient encodings of information needed by the
>routing and label assignment process in technologies such as WSON and are
>potentially applicable to a wider range of technologies. The encoding
>provided in [GEN-Encode] is protocol-neutral and can be used in routing,
>signaling and/or Path Computation Element communication protocol
>extensions.
>This document defines extensions to the OSPF routing protocol based on
>[GEN-Encode] to enhance the Traffic Engineering (TE) properties of GMPLS
>TE which are defined in [RFC3630], [RFC4202], and [RFC4203]."
>
>Let me know if this would be sufficient to your comment.

Yes.


> 
>
>       2. Section 5.1 - If one includes the Port Label Restrictions
>sub-TLV in a separate LSA, that LSA must also include the sub-TLVs
>necessary to identify the link unambiguously. To handle unnumbered links,
>I believe you'd need the Link-ID, Local Interface IP Address, and Remote
>Interface IP Address sub-TLVs.
>
>YOUNG>> In the encoding of the port label restriction (Section 2.2 of
>draft-ietf-ccamp-general-constraint-encode), we have association to the
>Link Set Field via the Matrix ID (which is used in the Connectivity ID)
>
>  0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   MatrixID    |RestrictionType| Switching Cap |     Encoding  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Additional Restriction Parameters per RestrictionType     |
>     :                                                               :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>And the Connectivity Matrix Field is defined as follow in Section 2.1 of
>the same draft:
>
>    0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Connectivity  |   MatrixID    |             Reserved          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Link Set A #1                         |
>      :                               :                               :
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Link Set B #1                         :
>      :                               :                               :
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Additional Link set pairs as needed     |
>      :                     to specify connectivity                   :
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Link Set Field unambiguously defines the link id's.

Ok - It seems the GEN-ENCODE draft doesn't handle unnumbered links where
the local IP(v6) address is not unique.


> 
>
>
>       3. Section 3.1 - Since the Port Label Restrictions sub-TLV is
>defined as a sub-TLV of the Link TLV, how is it used to define
>constraints for a specific connectivity matrix?
>
>YOUNG>> See my response above.
>
>       3. State the action to take if the new sub-TLVs or their attendant
>encodings are malformed. You should log the problem and ignore the entire
>LSA, subsuming TLV, or just the sub-TLV in GMPLS path computations.
>
>YOUNG>> I think the proper action in this case is to log the problem and
>ignore just the sub-TLV in GMPLS path computations. Would the following
>statement be satisfying your concern here:
>
>"In case where the new sub-TLVs or their attendant encodings are
>malformed, the proper action would be to log the problem and ignore just
>the sub-TLVs in GMPLS path computations rather than ignoring the entire
>LSA."

Ok

> 
>
>       4. Section 7 - Explicitly state which are IANA registries are
>being extended. Since you are adding a new TLV, you will also need a new
>registry for the sub-TLVs. See
>http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlv
>s.xhtml#top-level for examples.
>       
>From the IANA, would the following assignment be OK?
>
>7.1. Node Information
>This document introduces the following sub-TLVs of Node Attribute TLV
>(Value 5):
>   Type     sub-TLV
>   14        Connectivity Matrix
>
>7.2. Link Information
>This document introduces the following sub-TLV of TE Link TLV (Value 2):
>   Type     sub-TLV
>   26       Port Label Restrictions

Yes - this should suffice.

Thanks,
Acee




>
>Editorial:
>
>       Section 3.1 - What does the sentence "More dynamic information is
>contained in the information on available labels." mean?
>
>Also some suggested edits for readability. These are optional and my
>apologies if I changed the meaning of any text.
>
>Acee-Lindems-iMac-3:Desktop ealflin$ diff
>draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt.orig
>draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt
>77c77
><    fiber). In some of these technologies network elements and links may
>---
>>    fiber). In some of these technologies, network elements and links may
>123,124c123,124
><    Some data plane technologies that wish to make use of a GMPLS
><    control plane contain additional constraints on switching capability
>---
>>    Some data plane technologies require the use of a GMPLS control
>>    plane which imposes additional constraints on switching capability
>141c141
><    TE links can be announced in OSPF TE LSAs. The TE LSA, which is an
>---
>>    TE links can be advertised in OSPF TE LSAs. The TE LSA, which is an
>157,158c157,158
><    representing node switching asymmetry constraints includes Node ID,
><    connectivity matrix. Except for the Node ID which should comply with
>---
>>    representing node switching asymmetry constraints includes Node ID
>>    and connectivity matrix. Except for the Node ID, which should comply
>167c167
><    Routing Address described in [RFC3630], the other pieces of
>---
>>    with Routing Address described in [RFC3630], the other pieces of
>172c172
><    This Generic Node Attribute TLV contains one or more sub-TLVs
>---
>>    This Generic Node Attribute TLV contains one or more sub-TLVs.
>174,175c174,175
><    Per [GEN-Encode], we have identified the following new Sub-TLVs to
><    the Generic Node Attribute TLV. Detail description for each newly
>---
>>    Per [GEN-Encode], we have identified the following new sub-TLVs to
>>    the Generic Node Attribute TLV. Detailed description for each newly
>182c182
><    In some specific technologies, e.g., WSON networks, Connectivity
>---
>>    In some specific technologies, e.g., WSON networks, the Connectivity
>184,188c184,188
><    implementations. Usually, for example, in WSON networks,
><    Connectivity Matrix sub-TLV may appear in the LSAs because WSON
><    switches are asymmetric at present. It is assumed that the switches
><    are symmetric switching, if there is no Connectivity Matrix sub-TLV
><    in the LSAs.
>---
>>    implementations. Usually, for example, in WSON networks, the
>>    Connectivity Matrix sub-TLV may be advertised in TE LSAs since WSON
>>    switches are currently asymmetric. If no Connectivity Matrix sub-TLV
>>    is included, It is assumed that the switches support symmetric
>>    switching. 
>192,194c192,194
><    It is necessary to identify which ingress ports and labels can be
><    switched to some specific labels on a specific egress port, if the
><    switching devices in some technology are highly asymmetric.
>---
>>    If the switching devices in a GMPLS technology are asymmetric,
>>    it is necessary to identify which ingress ports and labels can be
>>    switched to some specific labels on a specific egress port.
>198c198
><    asymmetric switches (e.g. ROADMs and such) or fixed connectivity for
>---
>>    asymmetric switches (e.g., ROADMs and such) or fixed connectivity for
>207,209c207,209
><    multi-matrices within the Generic Node Attribute TLV. In addition a
><    large connectivity matrix can be decomposed into smaller separate
><    matrices for transmission in multiple LSAs as described in Section 5.
>---
>>    multiple matrices within the Generic Node Attribute TLV. In addition
>>    a large connectivity matrix can be decomposed into smaller
>>    sub-matrices for transmission in multiple LSAs as described in
>>Section 5.
>223c223
><    The most common link sub-TLVs nested to link top-level TLV are
>---
>>    The most common link sub-TLVs nested in top-level Link TLVs are
>238,239c238,240
><    control plane implementations. If it is default no restrictions on
><    labels, Port Label Restrictions sub-TLV may not appear in the LSAs.
>---
>>    control plane implementations. The Port Label Restrictions sub-TLV
>>    will not be advertised when there are no restrictions on label
>>    assignment.
>247,249c248,250
><    is contained in the information on available labels. Port label
><    restrictions are specified relative to the port in general or to a
><    specific connectivity matrix for increased modeling flexibility.
>---
>>    is contained in the information on available labels. For increased
>>    modeling flexibility, port label restrictions may be specified
>>    relative to a port in general or to a specific connectivity matrix.
>251c252
><    For example, Port Label Restrictions describes the wavelength
>---
>>    For example, the Port Label Restrictions describes the wavelength
>258,263c259,264
><    The Port Label Restrictions is a sub-TLV (the type is TBD by IANA)
><    of the Link TLV. The length is the length of value field in octets.
><    The meaning and format of this sub-TLV are defined in Section 5.4 of
><    [GEN-Encode]. The Port Label Restrictions sub-TLV may occur more
><    than once to specify a complex port constraint within the link TLV.
>< 
>---
>>    The Port Label Restrictions sub-TLV is a sub-TLV (the type is TBD
>>    by IANA) of the Link TLV. The length is the length of value field
>>    in octets. The meaning and format of this sub-TLV are defined in
>>    Section 5.4 of [GEN-Encode]. The Port Label Restrictions sub-TLV
>>    may occur more than once to specify a complex port constraint within
>>    the link TLV.
>277c278
><    All the sub-TLVs are nested to top-level TLV(s) and contained in
>---
>>    All the sub-TLVs are nested in top-level TLV(s) and contained in
>285c286
><    is changed. A standard-compliant approach is to separate the dynamic
>---
>>    is changed. A standards-compliant approach is to separate the dynamic
>287,288c288,289
><    nested to top-level TLV ([RFC3630 and RFC5876]), and advertise them
><    in the separate OSPF TE LSAs.
>---
>>    nested in a separate top-level TLV ([RFC3630 and RFC5876]), and
>>    advertise them in the separate OSPF TE LSAs.
>297,298c298,299
><    information sub-TLV could be nested to the top level link TLVs and
><    advertised in the separate LSAs.
>---
>>    information sub-TLV could be nested in separate top-level Link
>>    TLVs and advertised in the separate LSAs.
>306,307c307,308
><    specific time. Such mechanisms MUST be configurable if they are
><    implemented.
>---
>>    specific time interval. Such mechanisms MUST be configurable if
>>    they are implemented.
>317c318
><    splitting of general constraint LSAs into smaller LSA that are under
>---
>>    splitting of general constraint LSAs into smaller LSAs that are under
>
>Thanks,
>Acee 
>    
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp