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

From: David Ward <[email-masked]>
Date: Tue, 15 Jul 2008 11:43:44 -0500

All -

The CCAMP WG would like any last call comments from the ISIS WG on:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te- 
extension-02.txt

This last call will timeout July 30, 2008. Please cc this email with  
your comments.

Thanks

-DWard, CHopps

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

---

From: Mach Chen <[email-masked]>
Date: Mon, 21 Jul 2008 10:28:23 +0800

Hi Hannes,

Thanks for you questions!

Please see inline...

--------------------------------------------------
From: "Hannes Gredler" <[email-masked]>
Sent: Friday, July 18, 2008 9:06 PM
To: "Mach Chen" <[email-masked]>; "isis mailing list" <[email-masked]>
Cc: "David Ward" <[email-masked]>; "Adrian Farrel" <[email-masked]>; 
"ALABS Brungard Deborah A" <[email-masked]>; "Ross Callon" 
<[email-masked]>; "Christian Hopps" <[email-masked]>; 
<[email-masked]>
Subject: Re: [Isis-wg] CCAMP LC: 
draft-ietf-ccamp-isis-interas-te-extension-02.txt

> hi,
>
> 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.

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 #).

>
> 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.

>
>  --
>
>  IMO the inter-AS reachability TLV should just announce an AS number
>  and the remote ASBR IDs as subTLV information.

No,
Just as the the Extended IS Reachability TLV(rfc 3784) defined for 
advertisement of intra-area TE links, 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.

>
> or am i missing something ?
>
> /hannes
>
> ---
>
> 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
>
>
> On Tue, Jul 15, 2008 at 11:43:44AM -0500, David Ward wrote:
> |    All -
> |
> |    The CCAMP WG would like any last call comments from the ISIS WG on:
> |
> | 
> [1]http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te
> |    -extension-02.txt
> |    This last call will timeout July 30, 2008. Please cc this email with
> |    your comments.
> |    Thanks
> |    -DWard, CHopps
> |
> | References
> |
> |    1. 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-02.txt
>
> | _______________________________________________
> | Isis-wg mailing list
> | [email-masked]
> | https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jul 2008 12:56:53 +0800

Hi Hannes,

Please see inline...

--------------------------------------------------
From: "Hannes Gredler" <[email-masked]>
Sent: Monday, July 21, 2008 4:01 PM
To: "Mach Chen" <[email-masked]>
Cc: "isis mailing list" <[email-masked]>; "David Ward" <[email-masked]>; 
"Adrian Farrel" <[email-masked]>; "ALABS Brungard Deborah A" 
<[email-masked]>; "Ross Callon" <[email-masked]>; "Christian Hopps" 
<[email-masked]>; <[email-masked]>
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?

---

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jul 2008 16:39:07 +0800

Hi Hannes,

> | >
> | > 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.
>
> well that does not feel right. just consider the intra-level case.
> a node with system-ID XXX is advertising some reachability to node XXX.
>
> all the existing IS-Reach TLVs are carrying edges to
> *neighboring* routers, i.e. not to yourself.

I guess you misunderstand what I mean.

There is a little bit different between inter-AS reach TLV and IS-Reach TLV, 
the inter-AS Reach TLV does not need to advertise the reachability by 
carrying System-ID. The System-ID field( may be called Originator ID or 
something else, just like the Router ID of "IS-IS Router CAPABILITY TLV" 
which defined in RFC 4971) in the inter-AS Reach TLV is just used as the 
identifier of the source who generates the inter-AS Reach TLV.

So:

      6 octets of System ID( indicate the source of the inter-AS reach TLVs)
      0-244 octets of sub-TLVs
           0-242 octets of value

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jul 2008 18:10:36 +0800

Hi Hannes,

> On Tue, Jul 22, 2008 at 04:39:07PM +0800, Mach Chen wrote:
> | Hi Hannes,
> |
> | > | >
> | > | > 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.
> | >
> | > well that does not feel right. just consider the intra-level case.
> | > a node with system-ID XXX is advertising some reachability to node 
> XXX.
> | >
> | > all the existing IS-Reach TLVs are carrying edges to
> | > *neighboring* routers, i.e. not to yourself.
> |
> | I guess you misunderstand what I mean.
> |
> | There is a little bit different between inter-AS reach TLV and IS-Reach 
> TLV,
> | the inter-AS Reach TLV does not need to advertise the reachability by
> | carrying System-ID. The System-ID field( may be called Originator ID or
> | something else, just like the Router ID of "IS-IS Router CAPABILITY TLV"
> | which defined in RFC 4971) in the inter-AS Reach TLV is just used as the
> | identifier of the source who generates the inter-AS Reach TLV.
> |
> | So:
> |  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:
> |
> |       6 octets of System ID( indicate the source of the inter-AS reach 
> TLVs)
> |       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-244 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-242 octets of value
>
> i see, so you basically want to retain sort of originator-ID when leaking
> information across levels. - may i remind you that the same problem 
> already
> has been solved in the caps-code extension - see 
> http://www.ietf.org/rfc/rfc4971.txt
> here the originator-id is a 32-bit router-ID.

Thanks for your remind.

> IMO we should stick with router-IDs as originator-IDs for TE related 
> information, since
> they are universally applicable (e.g. even when leaking TE information 
> between
> a IS-IS and a non-IS-IS domain).

Deal:)

I will change the System-ID field to Router ID field with 4 octets.

Thanks again for your useful comments and suggestions!

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 28 Jul 2008 16:35:32 +0100

Folks,

I know you are all busy at the IETF this week, but please don't forget this 
last call.

Cheers,
Adrian
----- Original Message ----- 
From: "David Ward" <[email-masked]>
To: "isis mailing list" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; "ALABS Brungard Deborah A" <[email-masked]>; "Mach 
Chen" <[email-masked]>
Cc: "David Ward" <[email-masked]>; "Christian Hopps" <[email-masked]>; 
"Ross Callon" <[email-masked]>
Sent: Tuesday, July 15, 2008 5:43 PM
Subject: CCAMP LC: draft-ietf-ccamp-isis-interas-te-extension-02.txt

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Jul 2008 06:14:04 -0700

Primarily editorial comments.

Comment #1:
Section 2.1 has a number of references to "OSPF" which I presume should
be "IS-IS".

Comment #2:
Section 3.1 - it would be good if there was a reference to
draft-ietf-isis-genapp-01.txt flooding procedures so that correct
leaking of the TLVs is specified. Note that Section 4 of the genapp
draft is intended to be the authoritative text on flooding issues of
this type and should be referenced rather than repeated so as to avoid
any appearance of conflict.

Comment #3:
Section 3.3
Because sub-TLVs defined for TLV 22 can be advertised in the new
Inter-AS Reachability TLV, the new sub-TLVs defined here cannot conflict
with existing and/or future sub-TLV definitions for TLV 22. Therefore
the new sub-TLVs MUST be defined from a sub-TLV registry which is shared
by these two TLVs. This needs to be clearly stated here. It also needs
to be clearly stated that these sub-TLVs SHOULD NOT appear in TLV 22 (or
TLV 222) and MUST be ignored in TLV 22(or 222). This must also be
reflected in the IANA registry.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of David Ward
> Sent: Tuesday, July 15, 2008 9:44 AM
> To: isis mailing list; Adrian Farrel; ALABS Brungard Deborah A; Mach
Chen
> Cc: Ross Callon; Christian Hopps
> Subject: [Isis-wg] CCAMP
LC:draft-ietf-ccamp-isis-interas-te-extension-
> 02.txt
your
> comments.

---

From: Mach Chen <[email-masked]>
Date: Wed, 30 Jul 2008 16:13:32 +0800

Hi Les,

Thanks for your useful comments!

--------------------------------------------------
From: "Les Ginsberg (ginsberg)" <[email-masked]>
Sent: Tuesday, July 29, 2008 9:14 PM
To: "David Ward" <[email-masked]>; "isis mailing list" <[email-masked]>;
"Adrian Farrel" <[email-masked]>; "ALABS Brungard Deborah A"
<[email-masked]>; "Mach Chen" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; "Christian Hopps"
<[email-masked]>
Subject: RE: [Isis-wg] CCAMP
LC:draft-ietf-ccamp-isis-interas-te-extension-02.txt

> Section 2.1 has a number of references to "OSPF" which I presume should

Good catch!

These will be updated in the next revision!

> any appearance of conflict.

OK

> by these two TLVs. This needs to be clearly stated here.

Yes.

>It also needs

The three new sub-TLVs defined in this document will definitely not appear 
in the TLV 22(or 222), but I am not sure whether there will be other future 
sub-TLVs which may be the common attribute of intra-area and inter-AS TE 
links.

So, it seems that just state that the three new sub-TLVs defined in this 
document SHOULD NOT appear in the TLV 22( or 222) and MUST be ignored in TLV 
22(or 222) will be more reasonable. How you think that?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 30 Jul 2008 02:08:51 -0700

Mach -

> document SHOULD NOT appear in the TLV 22( or 222) and MUST be ignored
in
> TLV

Yes - I think we are saying the same thing.

   Les