Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 May 2015 21:33:34 +0100

Hi,
 
Herewith my last call review. 
 
Cheers,
Adrian
 
The definition of a 4-octet ASN for the ERO has value: hard to believe that no-one has defined it before. I wonder whether the value is sufficient to pull it out of this Experimental (thanks for making the area ID work experimental) and placing it in a Standards track document.
 
---
 
I personally find the definition of ERO subobjects for IGP areas
even more peculiar for signaling than I did for PCEP. I have no
serious objection to experimentation with this, but I doubt its 
utility. The facts are that if you are:
- in the backbone area of an AS you know how to reach any
  destination within the same AS either because it is either in
  the backbone area or because you know with area border router to 
  use
- not in the backbone area of an AS you know how to reach any
  destination within the same AS either because it is either in
  the same area, or you know to go to an area border router to
  route through the backbone
- in a different AS from the destination in which case you will
  need to go to your backbone area and then (possibly via transit 
  ASes) to the backbone area of the destination AS.
I do not see how an abstract node that identifies the area is
any help.
 
Example A1 is, of course, simple as to be pointless because the 
border routers are synonymous with the choices of IGP area. But it
might be argued that in the case where Area A is dual-homed to Area
B the initiator might want to indicate a path through Area B without
selecting between the border routers. However, I would argue that a
loose hop to the destination or to the chosen border router into 
Area C is all the information that is needed to compute a path at
the Ingress (as far as Area B because the Egress is not in Area A),
at ABF1 (as far as Area C because Area B knows that the Egress is
in Area C through normal IGP information), and at BC1 (as far as
the Egress which lies in Area C).
 
Furthermore, in example A2.2 I don't see the value in including 
Area B in the ERO since the only entry points into AS200 are per
force via Area B.
 
Similarly in route exclusion it appears that an excluded IGP area
is either not conceivably on the route anyway (so it is harmless to
say "exclude it", but also pointless) or unavoidably on the route 
(so that asking to avoid it is like asking to not have a route). But
I suppose it is faintly possible that the originator does not know in
what area the destination lies and prefers no path than a path to the
destination if it lies in a specific area.
 
I fear I have made these points before (in CCAMP) and I don't want to
be guilty of bringing up the same issue repeatedly. I don't feel 
that my point was addressed, but that may be my fault for not really
caring about this work one way or the other.
 
---
 
The abstract suggests that the new subobjects can identify generic
domains and then says "such as IGP areas or ASes". But you are only
defining new subobjects for 4 byte ASN, and for IGP areas: you don't
have a generic domain identifier. So the abstract appears to be
over-stating the case.
 
---
 
I have no strong feelings, but I note that the subobjects in 3209 all
put any necessary padding at the end of the subobject (for example,
4.3.3.2. Subobject 1: IPv4 prefix). I believe it was determined during
the authorship of 3209 that 4-octet alignment was not needed and that
compact filling of data was preferred. You might want to stay in synch
with that.
 
---
 
3.2.1
 
Since this document is Experimental I assume that there is currently no
intent to deprecate subobject 32 (the 2-octet ASN). You give clear
explanation of how to encode a 2-octet ASN in the new subobject, but I
think you should give advice about which subobject should be the default
(at least in your experiment) for the use of a 2-octet ASN.
 
---
 
3.2.3.  Mode of Operation
 
   The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area
   could also be used in the ERO 
 
"also"? You haven't said anywhere else they could be used.
 
---
 
3.3.1 and 3.3.2
 
   The meaning of the L bit (similar to [RFC4874]).
 
"similar" or "identical"?
 
---
 
Question: Do you want the IANA assignments to be identical to those in
draft-ietf-pce-pcep-domain-sequence? That might make [PCE-DOMAIN] a 
normative reference to ensure that everything is synchronised.
 
From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 19 May 2015 22:20
To: [email-masked]
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01
 
All,
This starts a two week working group last call on draft-ietf-teas-rsvp-te-domain-subobjects-01.
This working group last call ends on Tuesday, June 2nd. Please send your comments to the TEAS mailing list.

Note, IPR has been disclosed on this draft. All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: 
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/history/
 
Pavan and Lou.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 22 May 2015 03:09:20 +0000

Hi Adrian,

Thanks for the comments…

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 21 May 2015 02:04
To: [email-masked]
Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01

Hi,

Cheers,
Adrian

[Dhruv]: Chairs, WG, Thoughts?

---

[Dhruv]: It should be no surprise (☺) that path computation (PCEP) was our primary motivation, with the need for extension for signalling identified to keep the protocol and registries in sync.
I agree that there are other ways, as you clearly mention above, that said - area subobject is just another tool in the toolkit, and can be useful in some cases -

-      Area based domain-sequence configuration to be applicable even when PCE are not used for path computation

-      To allow to and fro of subobjects between signalling and path computation if need be

I have added some text in the I-D for this.
---

[Dhruv]: Updated.

---

[Dhruv]: But I thought we moved away from that as we added more subobjects like Unnumbered Interface ID and SRLG :)

---

3.2.1

[Dhruv]: Added!
For the purpose of this experiment, it is advised to use 4-Byte AS number subobject as default.

---

3.2.3.  Mode of Operation

[Dhruv]: Yes, removed “also”!

---

3.3.1 and 3.3.2

[Dhruv]: Agreed, changed also to handle Xian’s comment!

---

[Dhruv]: Done!

Working copy, diff attached!
Thanks again for your comments!

Regards,
Dhruv

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 19 May 2015 22:20
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01

All,

Pavan and Lou.

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 May 2015 12:19:05 -0400

See below.

On 5/21/2015 11:09 PM, Dhruv Dhody wrote:
>
> Hi Adrian,
>
>  
>
> Thanks for the comments…
>
>  
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Adrian Farrel
> *Sent:* 21 May 2015 02:04
> *To:* [email-masked]
> *Subject:* Re: [Teas] WG Last Call on
> draft-ietf-teas-rsvp-te-domain-subobjects-01
>
>  
>
> Hi,
>
>  
>
> The definition of a 4-octet ASN for the ERO has value: hard to believe
> that no-one has defined it before. I wonder whether the value is
> sufficient to pull it out of this Experimental (thanks for making the
> area ID work experimental) and placing it in a Standards track document.
>
>  
>

I don't have a preference either way.  To me it comes down to if anyone
cares enough to implement/use it.  If yes, then by all means it should
be in a Standards track document.

Given that this is the first time someone is suggesting ST/PS, it seems
there isn't much interest. (Which says leave as Experimental and revisit
if / when it becomes used.)

Lou