Subject: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

From: Acee Lindem <[email-masked]>
Date: Wed, 05 Jul 2006 21:12:10 -0400

Dimitri,

Here are my comments on the subject document:

General - Describe the relationship of OSPF areas to ASON RAs.
   Section 6.1 references     OSPF area ID but the relationship
   is implied.

Section  3.2 - The length calculation is simply wrong.  You
  really don't know how many prefixes you've got until you've
  parsed them.

Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
  specifies the router-id. Why do you need the remote router-id
  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
  requirement?

Section 6.0 - You should NOT need to change OSPF flooding rules.
  In other words, I don't see the need to specify the following:

  The Opaque TE LSA re-origination is governed as follows:
    - If the target interface is associated to the same area as the
      one associated with the receiving interface, the Opaque LSA MUST
      NOT be re-originated out that interface.
    - If a match is found between the Advertising Router ID in the
      header of the received Opaque TE LSA and one of the Router ID
      belonging to the area of the target interface, the Opaque LSA
      MUST NOT be re-originated out that interface.
    - If these two conditions are not met the Opaque TE LSA MAY be re-
      originated.

  Rather you should specify rules for importing/exporting
  information between OSPF instances at different levels.

Section 6.1 While an RA is completely contained within a single
   parent layer RA. A given    RA may have multiple child RAs. Hence,
   the election algorithm is broken.  At a minimum,
   you must advertise all your child areas.  Also, you MUST state
   that reachability is a precondition for considering a router
   eligible to pass information between levels.

   Finally, since this is going to require advertisement of more
   than a single area-ID, please allocate a separate opaque LSA
   for ASON purposes.

Section 6.2 - Are you suggesting a single area ID or an area ID
   path (similar to the BGP AS path)? I guess this may work if you
   always advertise you own area ID when redistributing between
   areas (relying on the fact that a child area is completely
   contained by its parent). I'm going to think more about this
   encourage others to do the same.

General: Have you considered aggregation?

Thanks,
Acee

---

From: [email-masked]
Date: Thu, 6 Jul 2006 07:40:49 +0200

hi acee - thanks for commenting 

one or two hints below such as to clarify some point you mentioned here 
below

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 03:12
 
        To:     [email-masked]
        cc: 
        Subject:        Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Dimitri,

[dp] point taken (i guess we did not do a sufficiently good
job in RFC 4258 and in the eval doc. as still some questioning
remains about information map)

[dp] which length are you referring to ? the prefix or the sub-TLV ?

[dp] it is not the router_id but the TE router_ID

[dp] the issue is that there is no more a there is no 
more a 1:1 relationship between the Router_ID and the TE 
Router_ID in the present context

[dp] your proposal is thus to revise these as import/export rules ?
in order to prevent having specific flooding rules between levels
the point was to not expand too much on the communication process
(inside the entity) between level adjacent RCs but if this makes
you more confortable i can revise as import/export rules

Section 6.1 While an RA is completely contained within a single
   parent layer RA. A given    RA may have multiple child RAs. 
Hence, the election algorithm is broken. 

[dp] to make it clear this is not an "election" process

At a minimum,

[dp] upper not lower (it is a discovery from a given to an upper
parent viewpoint, where a child has a unique parent)

[dp] having clarified the above is that still needed ?

Section 6.2 - Are you suggesting a single area ID or an area ID
   path (similar to the BGP AS path)? 

[dp] the former

I guess this may work if you

[dp] at which level - reachability can be aggregated for inst.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 06 Jul 2006 12:36:23 -0400

>hi acee - thanks for commenting 
Hi Dimitri,
Please see inline.

>Sent by: [email-masked]
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
   number of local prefixes included in the sub-TLV. 

>Router_ID in the present context
I surmised that. Why wouldn't the link ID be the remote TE router ID in this
case? The advertising router seems irrelevant from a TE standpoint.

>you more confortable i can revise as import/export rules
The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped LSAs
have very well defined flooding rules and, IMHO, you should not be trying to
roll-your-own flooding rules for this application. Just think what a 
mess we'd have
if every party proposed an opaque LSA also proposed some flooding hack for
their opaque LSA type.

>parent viewpoint, where a child has a unique parent)
I get from RFC 4258 that a child RA will be contained within a single 
parent RA. However,
no where do I that a parent RA can have a single child RA. So, if a 
single RC in a parent
RA has multiple child RAs, you need to advertise more than one area ID.

Also, you did not address the requirement for reachability. What if the 
RA becomes partitioned
or the advertising RC goes down without withdrawing its advertisements. 
You MUST deal
this - it is simply broken the way it is.

>[dp] having clarified the above is that still needed ?
You only clarified that it is wrong.

>[dp] at which level - reachability can be aggregated for inst.
Than the rules for aggregation should be specified.

Thanks,
Acee

---

From: [email-masked]
Date: Thu, 6 Jul 2006 20:12:04 +0200

acee - see inline

06/07/2006 18:36
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

[dp] 4 x n as defined in the node i-d is ok - why not this one 

>Router_ID in the present context

I surmised that. Why wouldn't the link ID be the remote TE router ID in 
this
case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE 
router_id
when space is per TE_router_id you need to seggregate this information

>you more confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped 
LSAs
have very well defined flooding rules and, IMHO, you should not be trying 
to
roll-your-own flooding rules for this application. Just think what a 
mess we'd have
if every party proposed an opaque LSA also proposed some flooding hack for
their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and 
export
rules (even if there is nothing in 3640 to pass LSA between routing 
instance)

[dp] the parent is unique why multiple parent area id

[dp] situation is the same as with a single ABR case, in case of 
multiple RC's you are expected to be aware of the broken RC -

[dp] not sure to capture your point - but ok - 

[dp] can add base guidelines if needed

Thanks,
Acee

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 6 Jul 2006 17:18:15 -0400

Hi Dimitri, Acee,

Just a small comment on the Link_ID - I think Dimitri is right that the
Link_ID and the Local/Remote TE_Router_ID have different meanings and
must not be confused.  On the other hand, Acee may have a point that the
Link_ID actually is no longer necessary once you have the Local/Remote
TE_Router_ID - we found in some prototyping that with the separation
of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
to what value you gave as the remote Router_ID, this was not used in
path computation at all.

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

>[dp] point taken (i guess we did not do a sufficiently good job in RFC 
>4258 and in the eval doc. as still some questioning remains about 
>information map)
>

>[dp] the issue is that there is no more a there is no more a 1:1 
>relationship between the Router_ID and the TE Router_ID in the present 
>context

I surmised that. Why wouldn't the link ID be the remote TE router ID in
this case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE
router_id when space is per TE_router_id you need to seggregate this
information

>  Rather you should specify rules for importing/exporting  information 
> between OSPF instances at different levels.
>
>in order to prevent having specific flooding rules between levels the 
>point was to not expand too much on the communication process (inside 
>the entity) between level adjacent RCs but if this makes you more 
>confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
LSAs have very well defined flooding rules and, IMHO, you should not be
trying to roll-your-own flooding rules for this application. Just think
what a mess we'd have if every party proposed an opaque LSA also
proposed some flooding hack for their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and
export rules (even if there is nothing in 3640 to pass LSA between
routing
instance)

>[dp] upper not lower (it is a discovery from a given to an upper parent

>viewpoint, where a child has a unique parent)
> 
>
I get from RFC 4258 that a child RA will be contained within a single
parent RA. However, no where do I that a parent RA can have a single
child RA. So, if a single RC in a parent RA has multiple child RAs, you
need to advertise more than one area ID.

Also, you did not address the requirement for reachability. What if the
RA becomes partitioned or the advertising RC goes down without
withdrawing its advertisements. 
You MUST deal
this - it is simply broken the way it is.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 06 Jul 2006 17:23:14 -0400

>path computation at all.
Hi Lyndon,

Exactly my point but I seemed to be getting into a circular argument. 
 From the standpoint of TE,
you only care about the entity to which link actually connects.  Also, 
is there any reason why
the TE router ID space and router-id space wouldn't overlapp? I don't 
see one.

Thanks,
Acee

---

From: [email-masked]
Date: Fri, 7 Jul 2006 14:13:56 +0200

hi lyndon

the link_id remains the mandatory sub-tlv including the remote router_id 
from 3630 - 

the link_id remains thus as defined in that rfc - translated into the 
terminology 
used in ason it represents the remote RC_ID

does it change something in terms of TE/computation - in principle not - 
even if
some engines where not able to process such mix of identifiers

thanks,
- dimitri.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
06/07/2006 23:18
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
<[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Hi Dimitri, Acee,

Cheers,

Lyndon 

-----Original Message-----

acee - see inline

Thanks,
Acee

---

From: "Ong, Lyndon" <[email-masked]>
Date: Sun, 9 Jul 2006 11:44:23 -0400

hi dimitri,

I agree regarding the existing LSA, it needs to retain the link_ID.
I thought that Acee was perhaps suggesting a new LSA
where link_id would not be mandatory.   

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, July 07, 2006 5:14 AM
To: Ong, Lyndon
Cc: Acee Lindem; [email-masked]; [email-masked]
Subject: RE: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

hi lyndon

the link_id remains thus as defined in that rfc - translated into the
terminology used in ason it represents the remote RC_ID

does it change something in terms of TE/computation - in principle not -
even if some engines where not able to process such mix of identifiers

thanks,
- dimitri.

Hi Dimitri, Acee,

Just a small comment on the Link_ID - I think Dimitri is right that the
Link_ID and the Local/Remote TE_Router_ID have different meanings and
must not be confused.  On the other hand, Acee may have a point that the
Link_ID actually is no longer necessary once you have the Local/Remote
TE_Router_ID - we found in some prototyping that with the separation of
the Router_ID and TE_Router_ID that it became somewhat arbitrary as to
what value you gave as the remote Router_ID, this was not used in path
computation at all.

Cheers,

Lyndon 

-----Original Message-----

acee - see inline

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Sun, 09 Jul 2006 11:58:52 -0400

Hi Lyndon,

>where link_id would not be mandatory.   
I blieve you mean making the link_id optional when the new sub-TLV was 
advertised -
we certainly don't want a new LSA. But no, I was suggesting defining 
link_id as the
end point of the link rather than the advertising router (which I don't 
is contrary to
RFC 3630)
Thanks,
Acee