headers
Samita Chakrabarti | 1 Feb 03:46

Comments on RFC4893

Hello Quaizar and Enke:

While reviewing RFC4893 (4-byte AS Number support for BGP), I have
encountered several questions related to interoperability and
implementation.

I am listing them below; my apology if they are already discussed in this
list before. (I am new in this mailing list)

It seems to me that the RFC has ambiguity in several places that needs to be
corrected from implementation perspective. Is there a plan for a revision?

Regards,
-Samita
----------------------------------------------------------------------------
----------------------------------------------------------------------------
RFC4893 is unclear about the processing of "My ASN" field in the OPEN
message. Section 3
 mentions about the capability message for 4byte ASN support:

"The Capability that is used by a BGP speaker to convey to its BGP peer the
4-octet Autonomous System number
 capability, also carries the 4-octet Autonomous System number of the
speaker in the Capability Value field of the
 Capability Optional Parameter. The Capability Length field of the
Capability is set to 4. "

and 
"We denote this special AS number as AS_TRANS for ease of description in the
rest of this
(Continue reading)

Permalink | Reply | 11 comments |
headers
Vishwas Manral | 1 Feb 03:58
Picon

Fwd: 6PE-Alt

Forwarding from the discussion on the v6ops list - on the draft.

---------- Forwarded message ----------
From: Vishwas Manral <vishwas.ietf <at> gmail.com>
Date: Jan 31, 2008 3:46 PM
Subject: Re: 6PE-Alt
To: DE CLERCQ Jeremy <jeremy.de_clercq <at> alcatel-lucent.be>
Cc: Francois Le Faucheur IMAP <flefauch <at> cisco.com>,
v6ops <at> ops.ietf.org, Ooms Dirk <dirk <at> onesparrow.com>,
stuart.prevost <at> bt.com

Hi Jeremy,

You are absolutely right.

This is not an alternate mechanism it is just an interesting way of
using already existing functionality BGP-IPv6 to derive the same
functionality as 6PE. We can get 6PE functionality without having to
do any different signaling at all.

It saves all the complicated mechanisms of label distribution, label
signaling, defining AFI/ SAFI and the complicated Inter-AS
distribution to achieve the same functionality. We do not need to
populate the hardware either with that many entries. I think that is
the idea of the draft.

Thanks,
Vishwas

On Jan 31, 2008 3:41 PM, DE CLERCQ Jeremy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kalpesh Zinjuwadia | 1 Feb 05:15
Favicon

Re: Comments on RFC4893

Some comments inline.

Thanks,
Kalpesh

-----Original Message-----
From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of
Samita Chakrabarti
Sent: Thursday, January 31, 2008 6:46 PM
To: idr <at> ietf.org; quaizar.vohra <at> gmail.com; enkechen <at> cisco.com
Subject: [Idr] Comments on RFC4893

Hello Quaizar and Enke:

While reviewing RFC4893 (4-byte AS Number support for BGP), I have
encountered several questions related to interoperability and
implementation.

I am listing them below; my apology if they are already discussed in
this
list before. (I am new in this mailing list)

It seems to me that the RFC has ambiguity in several places that needs
to be
corrected from implementation perspective. Is there a plan for a
revision?

Regards,
-Samita
------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 10 comments |
headers
Martin Horneffer | 1 Feb 10:07
Picon

Re: 6PE-Alt draft

Hi Vishwas,

just a quick question from an operator's point of view: what is your
consideration of how a P device (IPv4/MPLS only) should do the
load-sharing for 6PE traffic in case of ECMP?

If I got it correctly 6PE allows the egress PE to use different labels
which would make it easy for a P device to load-share. It does not
have to, though...

Best regards, Martin

On Thu, Jan 31, 2008 at 09:32:01AM -0800, Vishwas Manral wrote:
> Hi Jan,
> 
> Unlike in BGP MPLS IP VPN, the label does not tell any interface as we
> finally look up the only routing table the IPv6 routing table. We do
> not have the VRF concept here. That is the reason we do not need any
> presignaled label. The 6PE draft mentions why we need the top label
> very clearly.
> 
> However they have wrongly decided to signal a label with each route
> instead of just using the IPv6 Explicit NULL label.
> 
> Thanks,
> Vishwas
> 
> On Jan 31, 2008 9:00 AM, Jan Novak <jjjnovak <at> hotmail.com> wrote:
> >
> >
(Continue reading)

Permalink | Reply | 9 comments |
headers
Vishwas Manral | 1 Feb 18:26
Picon

Re: 6PE-Alt draft

Hi Martin,

The load sharing and everything else on the of P devices will still
work the same way. So we would have for example LDP running on the P
routers giving out labels for FEC's just the same way. The P device
works on the outer Tunnel label and its functionality will not change
in my view.

There is a case of having different labels for preventing one IPv6
lookup in some cases but in case we had the ECMP case we would have to
use the IPv6 header lookup and use the inner label as an IPv6 Explicit
NULL label.

Do let me know if I missed the point?

Thanks,
Vishwas

On Feb 1, 2008 1:07 AM, Martin Horneffer <maho <at> nic.dtag.de> wrote:
> Hi Vishwas,
>
> just a quick question from an operator's point of view: what is your
> consideration of how a P device (IPv4/MPLS only) should do the
> load-sharing for 6PE traffic in case of ECMP?
>
> If I got it correctly 6PE allows the egress PE to use different labels
> which would make it easy for a P device to load-share. It does not
> have to, though...
>
> Best regards, Martin
(Continue reading)

Permalink | Reply | 8 comments |
headers
Vishwas Manral | 1 Feb 19:34
Picon

Re: Comments on RFC4893

Hi,

There is just one small part I wanted to clarify.

> Clarification 3
> ============
> Section 3 of RFC4893 states:
> "NEW BGP speakers carry AS path information expressed in terms of
> 4-octet Autonomous Systems numbers by using the existing AS_PATH
> attribute, except that each AS number in this attribute is encoded not
> as a 2-octet, but as a 4-octet entity."
>  o-------------------o----------------------o-------------------
>   NEW1                NEW2               OLD2                    OLD3
> =====> Route Adv
>
> In the above sequence of configuration, how does the OLD2 process the
> 4byte ASN value in the AS_PATH  put by NEW1 ? The OLD BGP implementation
> is expected to use 2byte ASN value.  Please clarify.
> Should not it be easy and backward compatible if NEW BGP speakers always
> use AS4_PATH for 4byte ASN and use AS_PATH only when the ASNs
> are mappable to 2bytes?
>
> Kalpesh> NEW1 & NEW2 will exchange update with 4-byte AS-PATH & AGGR
> attributes. However, when NEW2 advertises update to OLD2, it will split
> 4-byte AS-PATH attribute into 2-byte AS-PATH and 4-byte AS4-PATH using
> the steps mentioned in RFC. Same goes for AGGR attribute. OLD2 & OLD3
> will treat AS4-PATH & AS4-AGGR attributes as unknown opt-trans and pass
> it further.

When the New router sends the update with the old router, it converts the 4 byte
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samita Chakrabarti | 1 Feb 20:51

Re: Comments on RFC4893

Hi Kalpesh,

Thanks for the response. Please see in-line.

>----
>
>Clarification 1:
>============
>In section 4 it describes the interaction between NEW BGP speakers; it
>discusses the UPDATE
>message processing with
>NEW and OLD BGP speakers. But  it does not discuss the OPEN message
>send/recv in details;
>the following cases need clarification:
>1) NEW BGP speakers interactions: If the BGP speaker has a 2byte unique
>ASN
>it uses the
>   2 byte ASN in the "My ASN" field of OPEN message. If the BGP speaker
>has
>a 4 byte
>   non-mappable AS number, then it  uses AS_TRANS in "My ASN" field of
>OPEN
>message.
>2) Receiving OPEN message: If a NEW BGP speaker receives a OPEN message
>with
>extended ASN
>   capability, then it ignores the "My ASN" field of OPEN message and
>uses
>the 4byte ASN
>   value in the capability message. [ this will clarify the
(Continue reading)

Permalink | Reply | 8 comments |
headers
Rajiv Asati (rajiva | 1 Feb 21:23
Picon
Favicon

Re: 6PE-Alt draft

Hi Vishwas,

Good discussion. 
It was interesting to see the following excerpt wrt 6VPE - 

> become IPv6 and the network may still have IPv4. If the assumption
> that each device in the IPv6 networks has a Global IPv6 address (not
> that IPv6 site local has been deprecated), we can do without the
> entire BGP MPLS IPv6 VPN functionality.

Assuming PE-to-PE tunneling is still in place, yah, you are right from
the routing perspective in 6VPE. But how would we prohibit one IPv6 site
communicating with another IPv6 site belonging to different enterprises.

AFAIK, the benefit of having VRF is beyond just the routing. And that's
one of the key components of BGP IP VPN functionality. 6VPE indeed has
merits. 

Perhaps, you intended to point to something else in BGP IPv6 VPN
functionality.

Cheers,
Rajiv 

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
> Sent: Thursday, January 31, 2008 10:01 AM
> To: Jan Novak
> Cc: idr <at> ietf.org; Francois Le Faucheur (flefauch); Ooms Dirk
> Subject: Re: [Idr] 6PE-Alt draft
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kalpesh Zinjuwadia | 1 Feb 21:28
Favicon

Re: Comments on RFC4893

Comments inline.

Thanks,
Kalpesh

-----Original Message-----
From: Samita Chakrabarti [mailto:samitac <at> ipinfusion.com] 
Sent: Friday, February 01, 2008 11:52 AM
To: Kalpesh Zinjuwadia; idr <at> ietf.org; quaizar.vohra <at> gmail.com;
enkechen <at> cisco.com
Cc: 'Samita Chakrabarti'
Subject: RE: [Idr] Comments on RFC4893

Hi Kalpesh,

Thanks for the response. Please see in-line.

>----
>
>Clarification 1:
>============
>In section 4 it describes the interaction between NEW BGP speakers; it
>discusses the UPDATE
>message processing with
>NEW and OLD BGP speakers. But  it does not discuss the OPEN message
>send/recv in details;
>the following cases need clarification:
>1) NEW BGP speakers interactions: If the BGP speaker has a 2byte unique
>ASN
>it uses the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Samita Chakrabarti | 1 Feb 21:52

Re: Comments on RFC4893

Hi Kalpesh,

>[SC>]  Yes. We are saying the same thing. But the point is that the RFC
>is
>not very clear about sending/receiving "My ASN" value in the OPEN
>message
>and it should be clarified.
>
><<Kalpesh>> I don't think there is any ambiguity in RFC for this. Can
>you elaborate what's not clear to you?
>

[SC>] 
I'd like to see a section on OPEN message on sending and receiving clearly
for example. I am hearing questions and problems in understanding from the
engineers who are implementing this RFC. I have been involved with IETF
process for a long time and wish to see a revision of this RFC which does
not generate clarification questions for those who did not get involved
during the development of this RFC.

-Samita

_______________________________________________
Idr mailing list
Idr <at> ietf.org
http://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 6 comments |

Gmane