Re: [CCAMP] [Isis-wg] [Technical Errata Reported] RFC4920 (4480)

Adrian -

I assume you are quoting Section 3.3?

NSAPs come in a variety of flavors/formats depending upon the addressing authority. The example in RFC Section 3.3 is talking about using USA GOSIP version 2.0 format as specified in Reference #9. The NSAP field is then broken into a set of subfields which include:

        AFI       1 octet       value "47" (specifies ICD format)

        ICD       2 octet       value "00 05" (specifies Internet/Gosip)

        DFI       1 octet       value "xx"

        AA        3 octets      value "xx xx xx" (specifies special
                                IP-only use of NSAPs)

        Reserved  2 octets      must be "00 00"

        RD        2 octets      contains autonomous system number

        Area      2 octets      must be assigned as described below

        ID        6 octets      must be assigned as desribed below

        SEL       1 octet       used as described below

Everything up to "ID" is part of the "area address". So the AFI/ICD/AA/Reserved/RD/Area comprise a 13 octet "area address" - part of which are specific values mandated by the GOSIP format. The "area" is simply one field in this GOSIP format.

ISO 8348 has more info - but frankly I always found this somewhat nauseating to read. The simplest way of thinking about things is:

Area Address: 1 -13 octets (length and values depend on the NSAP format chosen)
System ID: 1-6 octets - but always 6 octets in practice
NSEL: 1 octet - always 0

   Les

> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Friday, September 25, 2015 12:43 PM
> To: Les Ginsberg (ginsberg); ccamp@ietf.org
> Cc: isis-wg@ietf.org; teas@ietf.org
> Subject: Re: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> 
> OK, Thanks Les, a great help.
> 
> One last point of clarification...
> 
> When RFC 1195 says...
> >         Area      2 octets      must be assigned as described below
> ... why am I confused that that is allowed to be just one octet?
> 
> Cheers,
> Adrian
> 
> > -----Original Message-----
> > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
> > Sent: 25 September 2015 15:15
> > To: adrian@olddog.co.uk; ccamp@ietf.org
> > Cc: isis-wg@ietf.org; teas@ietf.org
> > Subject: RE: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> >
> > Adrian -
> >
> > The definitive document on OSI addressing is ISO 8348 (Annex A and B).
> > Freely available here:
> > http://standards.iso.org/ittf/PubliclyAvailableStandards/c035872_ISO_I
> > EC_8348_
> > 2002(E).zip
> >
> > Some text in ISO 10589 Section 7.1 is also helpful.
> >
> > But if you don't want to wade through the documents (for which I would
> > not blame you :-) ) here's the short version: An area address is 1 -
> > 13 octets in
> length -
> > so at a quick read the proposed text in the errata seems to be correct.
> >
> >    Les
> >
> >
> >
> > > -----Original Message-----
> > > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Adrian
> > > Farrel
> > > Sent: Friday, September 25, 2015 5:16 AM
> > > To: ccamp@ietf.org
> > > Cc: isis-wg@ietf.org; teas@ietf.org
> > > Subject: Re: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> > >
> > > All,
> > >
> > > This email is copied to TEAS and ISIS, but it would be really
> > > helpful if any discussion was held to one list. CCAMP is probably best
> because they "own"
> > > RFC 4920.
> > >
> > > The CCAMP chairs asked me to look into this as one of the original
> > > authors, and I have to say it has been so long that I can't recall the
> answer.
> > >
> > > However, I looked at RFC 1195 and found section 3.3 gave me that the
> > > full description of an Area ID as:
> > >
> > > >         AFI       1 octet       value "47" (specifies ICD format)
> > > >
> > > >         ICD       2 octet       value "00 05" (specifies Internet/Gosip)
> > > >
> > > >         DFI       1 octet       value "xx"
> > > >
> > > >         AA        3 octets      value "xx xx xx" (specifies special
> > > >                                 IP-only use of NSAPs)
> > > >
> > > >         Reserved  2 octets      must be "00 00"
> > > >
> > > >         RD        2 octets      contains autonomous system number
> > > >
> > > >         Area      2 octets      must be assigned as described below
> > >
> > > This implies (to me) that an Area ID must be at least the trailing
> > > two
> octets,
> > > but may be given more context reading up this table up to a maximum
> > > of 13 octets.
> > >
> > > All I deduce from this is that I am consistent in my ability to
> > > reproduce my processing, not that I am right.
> > >
> > > Can someone with IS-IS clue please comment:
> > > What are the max and min string lengths of an "area ID" in IS-IS?
> > >
> > > Thanks,
> > > Adrian
> > >
> > > > -----Original Message-----
> > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> > > > Sent: 21 September 2015 06:55
> > > > To: adrian@olddog.co.uk; asatyana@cisco.com;
> > > > a-iwata@ah.jp.nec.com; n- fujita@bk.jp.nec.com;
> > > > gash5107@yahoo.com; akatlas@gmail.com; db3546@att.com;
> > > > aretana@cisco.com; daniele.ceccarelli@ericsson.com;
> > > > zhangfatai@huawei.com
> > > > Cc: dhruv.ietf@gmail.com; ccamp@ietf.org;
> > > > rfc-editor@rfc-editor.org
> > > > Subject: [Technical Errata Reported] RFC4920 (4480)
> > > >
> > > > The following errata report has been submitted for RFC4920,
> > > > "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE".
> > > >
> > > > --------------------------------------
> > > > You may review the report below and at:
> > > > http://www.rfc-editor.org/errata_search.php?rfc=4920&eid=4480
> > > >
> > > > --------------------------------------
> > > > Type: Technical
> > > > Reported by: Dhruv Dhody <dhruv.ietf@gmail.com>
> > > >
> > > > Section: 6.2
> > > >
> > > > Original Text
> > > > -------------
> > > > For types 10 and 23, the Value field has the format:
> > > >
> > > >        0                   1                   2                   3
> > > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > > >       |   Length      |     IS-IS Area Identifier                     |
> > > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > > >       ~                     IS-IS Area Identifier (continued)         ~
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > >        Length
> > > >
> > > >           Length of the actual (non-padded) IS-IS Area Identifier in
> > > >           octets.  Valid values are from 2 to 11 inclusive.
> > > >
> > > > Corrected Text
> > > > --------------
> > > > For types 10 and 23, the Value field has the format:
> > > >
> > > >        0                   1                   2                   3
> > > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > > >       |   Length      |     IS-IS Area Identifier                     |
> > > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > > >       ~                     IS-IS Area Identifier (continued)         ~
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > >        Length
> > > >
> > > >           Length of the actual (non-padded) IS-IS Area Identifier in
> > > >           octets.  Valid values are from 1 to 13 inclusive.
> > > >
> > > > Notes
> > > > -----
> > > > IS-IS area IDs can vary from 1 to 13 bytes in length (max NSAP
> > > > length is 20,
> > > minus
> > > > 1 byte for NSEL, minus 6 bytes for SysID).
> > > >
> > > > *Noted by Jonathan Hardwick in another document that was using the
> > > > same data.
> > > >
> > > > Instructions:
> > > > -------------
> > > > This erratum is currently posted as "Reported". If necessary,
> > > > please use "Reply All" to discuss whether it should be verified or
> rejected.
> > > > When a decision is reached, the verifying party (IESG) can log in
> > > > to change the status and edit the report, if necessary.
> > > >
> > > > --------------------------------------
> > > > RFC4920 (draft-ietf-ccamp-crankback-06)
> > > > --------------------------------------
> > > > Title               : Crankback Signaling Extensions for MPLS and GMPLS
> > > RSVP-TE
> > > > Publication Date    : July 2007
> > > > Author(s)           : A. Farrel, Ed., A. Satyanarayana, A. Iwata, N.
> Fujita,
> > > G. Ash
> > > > Category            : PROPOSED STANDARD
> > > > Source              : Common Control and Measurement Plane
> > > > Area                : Routing
> > > > Stream              : IETF
> > > > Verifying Party     : IESG
> > >
> > > _______________________________________________
> > > Isis-wg mailing list
> > > Isis-wg@ietf.org
> > > https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg