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

From: Leeyoung <[email-masked]>
Date: Fri, 31 Jan 2014 00:17:40 +0000

Hi Acee,

Thanks for providing valuable comments. Please see inline for my response.

Best Regards,

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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. 

       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. 

       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." 

       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-tlvs.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

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Acee Lindem <[email-masked]>
Date: Fri, 31 Jan 2014 18:00:07 +0000

Hi Young,

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

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

>       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]."
>

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

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?
>
>       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.
>       

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

---

From: Leeyoung <[email-masked]>
Date: Fri, 31 Jan 2014 18:56:27 +0000

Hi Acee,

In the Gen-Encode, we have specified the following format for the Link Set Field in Section 2.3:

   Format: The format of the link identifier (6 bits)

         0 -- Link Local Identifier

   Indicates that the links in the Link Set are identified by link
   local identifiers. All link local identifiers are supplied in the
   context of the advertising node.

         1 -- Local Interface IPv4 Address

         2 -- Local Interface IPv6 Address

   Indicates that the links in the Link Set are identified by Local
   Interface IP Address. All Local Interface IP Address are supplied in
   the context of the advertising node.

         Others TBD.

Do you feel we need to specify unnumbered links? If so, would please suggest some text?

Thanks,
Young

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Friday, January 31, 2014 12:00 PM
To: Leeyoung; CCAMP
Subject: Re: [CCAMP] WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints

Hi Young,

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

>       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 
>YOUNG>> encoding;
>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.
>[GEN-Encode] to enhance the Traffic Engineering (TE) properties of 
>GMPLS TE which are defined in [RFC3630], [RFC4202], and [RFC4203]."
>

Yes.

>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.
>

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

>       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 
>YOUNG>> and
>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

>being extended. Since you are adding a new TLV, you will also need a 
>new registry for the sub-TLVs. See 

Thanks,
Acee

>
>Editorial:
>
>       Section 3.1 - What does the sentence "More dynamic information 
>is contained in the information on available labels." mean?
>