Subject: Re: (ION) RFC 1483 to Draft

From: Dan Grossman <[email-masked]>
Date: Wed, 24 Jun 1998 12:44:31 -0400

Oops, forgot something:
We should consider either merging RFC 1626 into Multiprotocol, or referencing 
it.
Dan

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Gary Hanson <[email-masked]>
Date: Wed, 24 Jun 1998 09:12:42 -0700 (PDT)

Dan,

In RFC 1483, the "Payload Format for BPDUs" header is missing above
the last figure in section 4.2.

Gary

---

From: Dan Grossman <[email-masked]>
Date: Wed, 24 Jun 1998 11:52:16 -0400

All,
Andy and I had a brief email discussion concerning the fact that multiprotocol 
encapsulation over AAL5 is overdue to get progressed to Draft. 

Here's my list of minor tweaks:

1) References need to be updated
2) A special case of VC multiplexing is used when PPP encapsulation is used 
over ATM (as in many ADSL implementations).  This case should be explicitly 
called out in the draft.
3) Section 2 needs to be updated to reflect maturation of ATM signalling 
protocols and to refer to RFC  1755.   RFC 1755 also needs to be referenced in 
Section 5.
4) Some words are needed in section 2 to emphasize that a separate VCC is 
needed for ARP.
5) Section 6 should be updated to become mostly a reference to LANE
6) Section 7 needs to be removed
7) A section (or perhaps an appendix) should set this memo in the context of 
the several systems that use it -- LANE, Classical, MPOA/NHRP, MARS.  I'm not 
yet sure how best to organize such material, only that it seems to be 
necessary.
8) Fix various typos and terminology inconsistencies
9) Remove various minor anachronisms

Any other thoughts?

rgds
Dan

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 09 Jul 1998 22:58:00 -0400

Dan, Andy,

Clarification question - is it actually appropriate to start
adding to this document or changing its thrust as part of
upgrading its standardization status?

Comments embedded...

> over ATM (as in many ADSL implementations).  This case should be explicitly

If this is cited already in another standards document then we
should cite it, nothing more. If including a full description of
this encaps method creates ambiguity as to which document is
normative, we should leave the defn to the current place where its
defined (an ADSL Forum spec?)

> protocols and to refer to RFC  1755.   RFC 1755 also needs to be referenced in

Agree.

> 4) Some words are needed in section 2 to emphasize that a separate VCC is

Disagree. Section 2 just says "hey, you can use LLC/SNAP or not". Nothing
about what protocol architectures might or might not force separate
VCCs for different protocols. If you're going to special-case ATMARP,
why not mention MARS, NHRP.... best not to worry at all.  If you
know of a common implementation error that would be solved by the
words you want, that should be placed in ClassicalIP/ATM spec, not here.

> 5) Section 6 should be updated to become mostly a reference to LANE

Only if no-one out there has built products that do simple bridging
as implied by section 6. (I'd support adding a citation to LANE as
an additional, more modern solution to bridging, though.)

> yet sure how best to organize such material, only that it seems to be

Sounds like Section 7 is exactly where the use of LLC/SNAP encaps in
ATMARP, MARS, NHRP, LANE, etc should now be documented.

> 9) Remove various minor anachronisms

cheers,
gja
________________________________________________________________________
Grenville Armitage                          High Speed Networks Research
http://nj5.injersey.com/~gja              Bell Labs, Lucent Technologies
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 10 Jul 1998 09:48:04 -0400 (EDT)

Grenville,

> upgrading its standardization status?

Generally, the rules say that you can add clarifications, fix bugs, and
"improve the quality" of the spec.  You should also remove
functionality that hasn't been shown to be interoperably tested. 

If you add major new functionality, then you have to recyle at
Proposed.

> defined (an ADSL Forum spec?)

A citation is I believe what Dan had in mind.

> words you want, that should be placed in ClassicalIP/ATM spec, not here.

Actually, what I would update in this section is the text beginning
"The details of B-ISDN signalling are still under study in CCITT [5]."
This is clearly out of date.

> an additional, more modern solution to bridging, though.)

It's always been my understanding that there are products that do
bridging encapsulation using the 1483 rules (there certainly are for
1490). This is almost exclusively over PVCs.

Cheers,
Andy
________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886

---

From: Paul Koning <[email-masked]>
Date: Fri, 10 Jul 1998 10:45:46 -0400

>>>>> "Andrew" == Andrew G Malis <[email-masked]> writes:

 >> Only if no-one out there has built products that do simple
 >> bridging as implied by section 6. (I'd support adding a citation
 >> to LANE as an additional, more modern solution to bridging,
 >> though.)

 Andrew> It's always been my understanding that there are products
 Andrew> that do bridging encapsulation using the 1483 rules (there
 Andrew> certainly are for 1490). This is almost exclusively over
 Andrew> PVCs.

Absolutely.

LANE is indeed an additional solution to bridging, with rather
different properties.  Which is the better solution depends very much
on the environment where it's being deployed.  (I would suggest
staying away from descriptions such as "more modern" which could be
taken to imply an inappropriate value judgement.)

1483 bridging encapsulation should certainly be retained.

	paul