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

From: Udayasree palle <[email-masked]>
Date: Wed, 3 Jun 2015 08:28:33 +0000

Hi,

I've reviewed the updated version of this document and believe it is ready for publication

Regards,
Udayasree as a co-author

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 03 June 2015 02:35
> To: [email-masked]
> Cc: Vishnu Pavan Beeram
> Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-
> subobjects-01
> 
> All,
> 
> As is always the case, positive comments, e.g., "I've reviewed this 
> document and believe it is ready for publication", are welcome! This 
> is useful and important, even from authors.
> 
> Thanks,
> Lou (and Pavan)
> 
> On 5/19/2015 5:20 PM, Vishnu Pavan Beeram wrote:
> > 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-ccamp-flexi-grid-fwk/hi
> > st
> > ory/>
> > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subo
> > bj
> > ects/history/
> >
> > Pavan and Lou.
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Jun 2015 20:39:30 +0100

Hi Dhruv,
 
I've been silent on this because (like I said) I don't really care if you go ahead with this extension as an experiment. But just for the record, I think it is a wrong thing and that your experiment will not be a success because:
- the feature has no value
- you appear to be saying that you are not really interested even for
 your experimental implementation because your real concern is for
  the PCEP work.
 
The use cases you suggest here do not seem to me to have value...
 
> Area based domain-sequence configuration to be applicable even when PCE
> are not used for path computation
 
I remain certain that with or without a distinct PCE node, the concept of an area-sequence is unhelpful. If you do anything other than specify a full explicit path, then a node will be faced with an abstract node in the ERO (the area ID) and must perform a path computation to expand the path to reach the abstract node. My contention is:
- placing an area ID in the path when the hops are explicit is of no help
- placing an area ID in the path as an abstract node does not aid
 computation of a path within an AS as the path can already be
  determined to traverse the sequence of areas.
 
> To allow to and fro of subobjects between signalling and path computation
> if need be  
 
I don't believe that there is the need! There are two directions:
- The PCC might want to map an area ID encountered in a signaling
  message to a PCReq. But it will not find one in a signaling message
  or have any use for this feature if there is no value to placing an
  rea ID in signaling
- The PCC might want to map an area ID in a path in a PCRep to a
  signaling message. But it will not find one in a PCRep if the inclusion
  of an area ID in a path does not further define a path.
 
In other words, neither in signaling nor in PCEP does adding an area ID to the definition of a path in any way clarify the path or aid the description or signaling of the path.
 
That's my last comment on this issue unless you choose to debate further.
 
Thanks,
Adrian
 
PS I still wonder whether pulling the 4 octet ASN onto the standards track would be wise.

From: Dhruv Dhody [mailto:[email-masked]] 
Sent: 22 May 2015 04:09
To: [email-masked]; [email-masked]
Cc: Dhruv Dhody ([email-masked])
Subject: RE: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01
 
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,
 
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.
 
[Dhruv]: Chairs, WG, Thoughts? 
 
---
 
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.
 
[Dhruv]: It should be no surprise (J) 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.
---
 
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.
 
[Dhruv]: Updated.
 
---
 
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.
 
[Dhruv]: But I thought we moved away from that as we added more subobjects like Unnumbered Interface ID and SRLG :) 
 
---
 
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.
 
[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
 
   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.
 
[Dhruv]: Yes, removed “also”! 
 
---
 
3.3.1 and 3.3.2
 
   The meaning of the L bit (similar to [RFC4874]).
 
"similar" or "identical"?
 
[Dhruv]: Agreed, changed also to handle Xian’s comment!   
 
---
 
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.
 
[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]
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.