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

[Leeyoung <[e-mail]>]

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:[e-mail]] 
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,

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