Subject: RE: Next-Hop in IPv6 only environment

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Feb 2003 14:01:14 -0500

Andrew:

My understanding from the ADs is that
we are completing the Base specification
first without any additions.

After we have completed the 1st version of
the base specification, I believe the ADs
will re-open the charter to these additions.
It is my understanding that we will deal
with IPv6 issues after this point.

Yakov, Bill and Alex - am I correct?

Sue Hares

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Saturday, February 22, 2003 6:28 PM
To: Manav Bhatia
Cc: Enke Chen; Jeffrey Haas; [email-masked]; [email-masked]
Subject: Re: Next-Hop in IPv6 only environment

Going through the entire base spec and adding a caveat in every place where
an extention document modifies it, is almost as much work as documenting all the
varriant behavior in the base spec.  

If there is confusion on this issue, I would suggest we add a statement
like this:

 This document specifies the base behavior of the BGP protocol.  This
 behavior can and is modified by extention specifications.  When the
 protocol is extended the new behavior is fully documented in the
 extention specifications.

to the beginning of the document somewhere.

Andrew

On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Fri, 14 Feb 2003 10:28:55 +0530
> From: Manav Bhatia <[email-masked]>
> Subject: Re: Next-Hop in IPv6 only environment
> To: Enke Chen <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>, [email-masked], [email-masked]
> Reply-To: Manav Bhatia <[email-masked]>
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> X-Mailer: Microsoft Outlook Express 6.00.2720.3000
> X-Priority: 3
> X-MSMail-priority: Normal
> Precedence: bulk
> X-Spam-Status: No, hits=0.1 required=5.0
> 	tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,
> 	      USER_AGENT_OE
> 	version=2.43
> X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5]
> 
> Enke,
> 
> >    An UPDATE message that carries no NLRI, other than the one encoded in
> >    the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
> >    If such a message contains the NEXT_HOP attribute, the BGP speaker
> >    that receives the message should ignore this attribute.
> 
> Yes it indeed is.
> 
> However it would be really nice if a similar thing is mentioned somewhere
> in the base spec too OR once again, a pointer to the fact that NEXT_HOP
> attribute is not always *mandatory* is mentioned to remove any later
> confusions amongst the implementers.
> 
> I have a gut feeling that this issue will crop up again some time later
> down the line. The confusion will be all the more aggravated when your base
> spec RFC is greater than your extensions RFC nos.
> 
> Thanks,
> Manav
> 
> P.S.
> Once again, the issue isn't that RFC 2858 isn't clear .. its just that it
> defies what the base spec mandates any implementation to do!
> 
> It just gets all the more skewed when the base spec is more recent than the
> extensions draft/RFC!
> :-)

---

From: [email-masked]
Date: Mon, 24 Feb 2003 12:42:40 -0800

Sue,

The paragaph below would be part of the base spec.  I don't think it would
violate the charter, since it would basically say "if you are interested in
bgp foo, look in the bgp foo document, since bgp foo is beyond the scope of
this document".  However, I certainly do NOT want to hold up the process.  
I proposed that text because there was some indication on the list that 
it was not clear how the BGP specifications interrelated.  I was trying to
take the view of someone who was not a list veteren and was reading the
BGP documents for the first time.  

If you, as the document editor, feel that this is not necessary, I'm
happy to defer to your editorial judgement on this.

Andrew

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 25 Feb 2003 08:07:32 -0800

Sue,

> Yakov, Bill and Alex - am I correct?

I think that adding the text suggested by Andrew would be fine.

Yakov.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Feb 2003 11:54:02 -0500

In message <[email-masked]>, Yakov Rekhter writes
> I think that adding the text suggested by Andrew would be fine.

A worthwhile clarification since it keeps coming up on the list.  I
agree that it is worth adding Andrew's text either to the front or as
an additional "Protocol Extensions" appendix at the very end.

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Tue, 25 Feb 2003 09:09:41 -0800

While something like this definitely wouldn't harm the spec, I don't
think it is really required--a situation where the base spec is more
recent than the extensions is absolutely normal and happens quite
often. A higher number of the base RFC does not mean it obsoletes the
extension spec, whatever RFC number that is. Example: OSPFv2 spec:
RFC2328; the demand circuit extension to it suppressing Hello's on a
link: RFC1793... and no disclaimers that extensions may modify the
described behavior, and no confusion :)

Then again, it's a minor question. If you guys believe it's a good
idea to have something like this in the text--sure.

-- 
Alex