Subject: Re: -18 last call comments

From: Mareline Sheldon <[email-masked]>
Date: Sun, 1 Dec 2002 18:05:08 -0800 (PST)

Hi,
> From Appendix A:
> 
>   UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.

Can you please tell me the reason why this subcode has been deprecated? As i understand it
means that if i now recieve this UPDATE which carries the same AS as mine then i need not
close the session. I just need to ignore this particular UPDATE.

Incidentally, i was doing some testing yesterday and was confused with one major vendor's BGP
implementation. It is accepting UPDATEs which carry its own AS number in the AS-SET and
advertises them to its EBGP peers. It refuses these UPDATEs if it finds its own AS number in
the AS SEQ and does not advertise them to its EBGP neighbors.

AFAIK, a BGP implementation should check for its own AS nos. in both the AS-SET and AS-SEQ. Am
i missing something here?

with regards,
mareline s.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: "John G. Scudder" <[email-masked]>
Date: Sun, 1 Dec 2002 22:46:21 -0500

At 6:05 PM -0800 12/1/02, Mareline Sheldon wrote:
>Can you please tell me the reason why this subcode has been 
>deprecated? As i understand it means that if i now recieve this 
>UPDATE which carries the same AS as mine then i need not close the 
>session. I just need to ignore this particular UPDATE.

Right.  In fact this is nothing new.  The existence of the "AS 
Routing Loop" error incorrectly implied that such an UPDATE was a 
protocol violation, which it is not.

>Incidentally, i was doing some testing yesterday and was confused 
>with one major vendor's BGP implementation. It is accepting UPDATEs 
>which carry its own AS number in the AS-SET and advertises them to 
>its EBGP peers. It refuses these UPDATEs if it finds its own AS 
>number in the AS SEQ and does not advertise them to its EBGP 
>neighbors.
>
>AFAIK, a BGP implementation should check for its own AS nos. in both 
>the AS-SET and AS-SEQ. Am i missing something here?

What you describe sounds like a bug in the implementation to me.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Dec 2002 10:52:49 -0500

Yakov,

On Sat, Nov 30, 2002 at 04:46:57PM -0800, Yakov Rekhter wrote:
> 1772 is in the non-normative section. I think we could keep it there,
> and keep the references as well.

My concern is mostly that as we publish the BGP spec as an RFC
it'd be nice for it to refer to whatever replaces 1772.

I don't know how this is handled in practice, but I don't think its
a big deal.  I just thought it was worth bringing up.

> > Capitalization of magic words such as MUST and SHOULD should be done.
> 
> It should be done *as appropriate*. Therefore, if you think there
> are places where it is *appropriate* to do capitalization, please
> point them out.

Will do when I can find a few cycles.

> > Update message error subcode 7 is removed.  Especially in -18,
> > it looks like an editing mistake based on where it would fall
> > in the editing..
> 
> From Appendix A:
> 

What I would like to see is something like this:

6 - Invalid ORIGIN Attribute
7 - [Deprecated - See Appendix A]
8 - Invalid NEXT_HOP Attribute

As it stands, 7 lies on a page boundary and looks like it got clipped
by the roff.

> > Reference to IDRP should be ISO10747 not IS10747.
> 
> No, it should be IS10747.

I'll take your word on this, however what I have on my shelf reads:
ISO/IEC DIS 10747: 1992

Which probably means I have a last-call version of the draft standard.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 02 Dec 2002 08:06:32 -0800

Jeff,

> As it stands, 7 lies on a page boundary and looks like it got clipped

Ok. I'll also add a similar text for Open Message Error subcode 5.

Yakov.