Re: [Idr] draft-rosen-idr-aigp-00

Hi Pradosh,

 > 1) MED alone is not a good tool since the MED comparison step
 >    is after AS_PATH length comparison.

Correct. That is why I proposed to use it along with cost communities.

 > 2) Cost community is an extended community which is optional
 >    transitive. We want to make the attribute non-
 >    transitive to restrict its scope of propagation.

Transitiveness should be discussed in the scope. Ext community attribute 
is transitive within the domain. Inter-domain high-order type field 
decides if this should be transitive or not at the AS boundary.

Cost community is not transitive.

Exactly as required :).

The BGP Cost Community

    The BGP Cost Community is an Opaque Extended Community [EXT_COMM]
    defined as follows:

       Type Field:

          The value of the high-order octet of the extended Type Field is
          0x43, which indicates it is non-transitive. The value of the
          low-order octet of the extended type field for this community
          is TBD.

Cheers,
R.

> Hi Robert,
> 
> Thanks for the comments. Inline:
> 
> | I would like to support the suggestion made yesterday by Enke 
> | Chen, Keyur Patel and Danny which suggested to make a good 
> | analysis for using MED + Cost Community which are an already 
> | existing tools to achieve the same functionality as the draft 
> | proposed via a definition of a new AIGP attribute.
> 
> Here are the replies I made during the WG discussion for these
> questions:
> 
> 1) MED alone is not a good tool since the MED comparison step
>    is after AS_PATH length comparison.
> 2) Cost community is an extended community which is optional
>    transitive. We want to make the attribute non-
>    transitive to restrict its scope of propagation.
> 
> - Pradosh
> 
> | 
> | In fact the problem described in the draft is a very good 
> | example where practical problem can be solved using the above 
> | two solutions combined together.
> | 
> | It can be a very good motivation for restarting work on cost 
> | community itself which were last posted 
> | draft-retana-bgp-custom-decision-00. There are apparently 
> | practical cases which this draft has a potential to solve and 
> | IMHO there is a saving to implement something once and then 
> | reuse for various applications as opposed to implementing 
> | separate attributes which would at the end result in more 
> | burden to BGP and deployment difficulties.
> | 
> | Cheers,
> | R.
> | 
> | _______________________________________________
> | Idr mailing list
> | Idr@ietf.org
> | https://www.ietf.org/mailman/listinfo/idr
> | 
> 
> 