Re: [Isis-wg] CCAMP LC: draft-ietf-ccamp-isis-interas-te-extension-02.txt

[Mach Chen <[e-mail]>]

Hi Hannes,

Please see inline...

--------------------------------------------------
From: "Hannes Gredler" <[e-mail]>
Sent: Monday, July 21, 2008 4:01 PM
To: "Mach Chen" <[e-mail]>
Cc: "isis mailing list" <[e-mail]>rg>; "David Ward" <[e-mail]>om>; 
"Adrian Farrel" <[e-mail]>uk>; "ALABS Brungard Deborah A" 
<[e-mail]>om>; "Ross Callon" <[e-mail]>et>; "Christian Hopps" 
<[e-mail]>rg>; <[e-mail]>
Subject: Re: [Isis-wg] CCAMP LC: 
draft-ietf-ccamp-isis-interas-te-extension-02.txt

> On Mon, Jul 21, 2008 at 10:28:23AM +0800, Mach Chen wrote:
> | > i have a general question:
> | >
> | >  since IS-IS does not run on the border link between ASes, how
> | >  are the TE link attributes like (remote ASBR-ID, AS #, system-ID)
> | >  supplied ? -
> |
> | The TE link attributes are supplied by manually configuration.
> |
> | >
> | >  is this done by means of static configuration, i.e. prone
> | >  to misconfiguration and lack of diagnosing & tracking changes
> | >  in the neighboring AS ?
> |
> | As stated in the document (Section 5), some of the TE link attributes(
> | remote ASBR-ID, ASN) are obtained manually from a neighboring 
> administration
> | as part of commercial relationship, so the operators (both include
> | neighboring and local administrations) have the responsibility to check 
> the
> | information carefully before it entered as configuration information at 
> the
> | ASBR responsible for adverting the inter-AS TE links.
>
> as i have stated - there is too much manual'ism in for my taste.
>  are you not concerned about changes like remote router ID etc. ?
>  i want to remind that there is no way to detect/troubleshoot a
>  misconfiguration. i have some concerns that in large networks
>  (100+ ASBR links) this is a managable solution.

Manual configuration is the basal method, this document does not limit to 
use any other dynamic methods to get the info, as stated in section 4.1 BGP 
may be one of the options, but whether and how to utilize these 
possibilities is an implementation matter.

As to detect/troubleshoot a misconfiguration, IMO, I think that's the same 
as any protocols with manual configuration (e.g, configure BGP, configure 
routing policy, configure VPN...), there always are some methods could be 
used for troubleshooting/detection (e.g. OM tools, manual check...)

>
> | And we are considering a Border Gateway Protocol (BGP) peering may exist
> | between the two ASBRs and this could be used to detect inconsistencies 
> in
> | configuration( e.g. the AS #).
>
> detection is good, avoidance of mis-config by automatism is even better 
> :-).
>
> essentially what i'd like to see here is to inject is information
> from the BGP local peering session into the IS-IS cloud.
> i.e. all the information that is locally
> available (rem AS #, rem router-ID, link BW etc)

Yes, you could do it, while some of the TE information of an inter-AS TE 
link may be available within the AS
from other protocols, but we can't not assume that such protocols are always 
processed on the ASBRs (the ASBRs will not always run BGP). And IMO, I think 
this is an implementation matter.
>
> | >
> | > and a specific question on the semantics of the System ID field:
> | >
> | >  why is this required at all ? - and what should be inserted if the
> | >  neighboring ASBR does not have a system-ID (e.g. it is running OSPF).
> |
> | There is no any specific requirement for the System-ID in this document, 
> the
> | System ID is just one of the ISIS protocol fields. The operators could
> | configure any unique value within their domain as the System-ID( e.g. 
> Router
> | ID ) based on their planning/deployment policy, even if the neighboring 
> ASBR
> | does not have a system-ID.
>
> i am asking specifically about the inter-AS reachability TLV.
> what should get inserted in the first seven octects ?
> what should get inserted if the neighboring AS runs OSPF ?

No matter what the neighboring AS runs ISIS or OSPF, we consider that local 
System-ID+0 or local Router ID+0 could get inserted into the first seven 
octects, and there will not be any extra configuration required. The 
System-ID or Router-ID can be used for indicating the source of the inter-AS 
reach TLV.

>
> | > 3.1. Inter-AS Reachability TLV
> | >
> | >   The Inter-AS Reachability TLV has type 141 (which needs to be
> | >   confirmed by IANA see Section 6.1), it contains a data structure
> | >   consisting of:
> | >
> | >      7 octets of System ID and Pseudonode Number
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | >      3 octets of default metric
> | >      1 octet of control information, consisting of:
> | >         1 bit of flooding-scope information
> | >         1 bit of up/down information
> | >         6 bits reserved
> | >      1 octet of length of sub-TLVs
> | >      0-243 octets of sub-TLVs
> | >         where each sub-TLV consists of a sequence of:
> | >           1 octet of sub-type
> | >           1 octet of length of the value field of the sub-TLV
> | >           0-241 octets of value
>
> | the inter-AS reachability TLV defined
> | in this document is used to advertise the TE link attributes of an 
> inter-AS
> | TE link, so just announce an AS number and the remote ASBR IDs is not
> | enough, because an inter-AS link also has other TE link attributes as an
> | intra-area TE link does, and such TE link attributes are needed when
> | performing path computation.
>
> thats all good and fine - where it gets hack'ish is that you try to
> fake up an IS-IS node-ID (system-ID + PSN) in the inter-as reach TLV,
> where there is no IS-IS speaker.
>
> what you try to advertise here is a link to an external (non-IS-IS)
> domain. and attach some TE attributes to it. the agreed upon ID for
> external domains is the autonomous system number and nobody prevents
> you to attach misc. TE information (bandwidth, etc.) to that.
>
> ---
> i really want to get rid of the manual'ism in this spec.

As I said above, manual configuration is the basal method, we have not to 
depend on other protocols.

>
> what you need to do in order to avoid manual configuration is
> to get rid off the faked 7 octects (system-ID and PSN) and replace
> that with something neutral to represent the link.

Even if get rid off the 7 octects, manual configuration can not be avoided 
totally, because we have to configure the remote ASBR ID and remote AS 
number for an inter-AS TE link when the ASBRs don't run BGP or other 
protocols.

>
> there are several choices at hand (my preferred one would
> be to advertise the ASN and attach TE rleevant parameters
> (link IP addresses, remote ASBR ID, BW information as subTLV).

It seems that the PSN octet is not necessary, we could remove it. How do you 
think about it?

>
> /hannes 


_______________________________________________
Isis-wg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/isis-wg