Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover

2020-01-23 Thread slitkows.ietf 
Hi Greg,

 

I think there is still a misunderstanding on the proposed encoding  I may not 
have been fully clear, sorry.

 

Here is what you have:

 

   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

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |BFD Mode   |  Reserved |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |   BFD Discriminator   |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  Type |   Length  |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  ~ Value ~

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

Here is what I expected :

 

   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

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |BFD Mode   |  Reserved |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |   BFD Discriminator   |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  Optional TLVs (variable)

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

 

Associated with a text:

Optional TLVs:

The BFD Discriminator attribute MAY context optional TLVs for future extension. 
Each TLV consists of a sequence of:

*   1 octet of TLV type
*   1 octet of length of the value field of the TLV
*   Followed by the value 

This document does not define any TLV yet.

 

Thinking more about it, while it remains a good idea to use TLVs for future 
extensions, we need to define a registry to manage the TLV type in the context 
of the BFD attribute. Which means we will create an empty registry.

I would be happy to hear other opinions on that.

 

Brgds,

 

Stephane

 

 

 

From: Greg Mirsky  
Sent: jeudi 23 janvier 2020 01:06
To: slitkows.i...@gmail.com
Cc: BESS ; bess-cha...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

 

Hi Stephane,

I've followed your suggestions and updated the working version of the draft 
with adding:

*   explicit TLV in the format of BFD Discriminator attribute;
*   text to define check the proper format of the BFD Discriminator 
attribute and the handling in case it is malformed per RFC 7606.

I greatly appreciate your feedback. Attached please find the diff to the 
updated working version of the draft and its copy.

 

Regards,

Greg

 

On Tue, Jan 7, 2020 at 5:59 AM mailto:slitkows.i...@gmail.com> > wrote:

Hi Greg,

 

More inline,

 

 

From: Greg Mirsky mailto:gregimir...@gmail.com> > 
Sent: mercredi 4 décembre 2019 23:22
To: slitkows.i...@gmail.com  ; BESS 
mailto:bess@ietf.org> >; bess-cha...@ietf.org 
 
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

 

Hi Stephane,

thank you for the review and your thoughtful comments. Please find my answers 
and notes in-lined under GIM>> tag.

Attached, please find the diff and copy of the working version.

 

Regards,

Greg

 

Hi,

 

Please find below my review of the document.

 

Nits:

 


Section 3.1.1: 

As the document is standard track, could you introduce normative language in 
the expected behavior description ?

 

GIM2>> My apologies, I've pasted the same text twice. I propose to remove "may 
be omitted" altogether. Hence the updated text:

   If BGP next-hop tracking is done for VPN routes and the root address
   of a given tunnel happens to be the same as the next-hop address in
   the BGP auto-discovery route advertising the tunnel, then the use of this

   mechanism for the tunnel will not bring any specific benefit. 

Do you see this version without any normative language as acceptable?

 

[SLI] Looks good thanks

 

 


Section 3.1.2:

As the document is standard track, could you introduce normative language in 
the expected behavior description ?

 

“This method should not be used”. Wouldn’t this be a normative statement ?

GIM>> Would the following modification of the text be acceptable:

OLD TEXT:

   This method should not be used when there is a fast restoration
   mechanism (such as MPLS FRR [RFC4090]) in place for the link.

NEW TEXT:
Using this method when a fast restoration mechanism (such as MPLS FRR
   [RFC4090]) is in place for the link requires careful consideration
   and coordination of defect detection intervals for the link and the
   tunnel.  In many cases, it is not practical to use both methods at
   the same time.

Re: [bess] WG adoption poll and IPR poll for draft-zzhang-bess-bgp-multicast-controller

2020-01-23 Thread slitkows.ietf 
Hi WG,

 

The document is adopted.

Authors, pls republish using -ietf-

 

Thanks

 

 

From: slitkows.i...@gmail.com  
Sent: lundi 6 janvier 2020 15:13
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption poll and IPR poll for
draft-zzhang-bess-bgp-multicast-controller

 

Hello,

 

This email begins a two-weeks WG adoption poll for and
draft-zzhang-bess-bgp-multicast-controller-02 [1] .

For information, it's companion document
(draft-zzhang-bess-bgp-multicast-03) is also polled for WG adoption in a
separate email.

 

Please review the draft and post any comments to the BESS working group
list.

 

We are also polling for knowledge of any undisclosed IPR that applies to
this Document, to ensure that IPR has been disclosed in compliance with IETF
IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

 

If you are listed as an author or a contributor of this document, please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR, copying the BESS mailing list. The document won't
progress without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

 

If you are not listed as an author or a contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

 

This poll for adoption closes on *** 20th January 2020 ***  

 

Regards,

Matthew and Stephane

 

[1]

https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast-controller/

 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

2020-01-23 Thread slitkows.ietf 
The document is adopted.

Authors please republish using -ietf-

 

 

From: slitkows.i...@gmail.com  
Sent: lundi 6 janvier 2020 15:15
To: bess@ietf.org
Cc: bess-cha...@ietf.org; draft-zzhang-bess-bgp-multic...@ietf.org
Subject: WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03 

 

Hello,

 

This email begins a two-weeks WG adoption poll for and
draft-zzhang-bess-bgp-multicast-03 [1] .

For information, it's companion document
(draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG
adoption in a separate email.

 

Please review the draft and post any comments to the BESS working group
list.

 

We are also polling for knowledge of any undisclosed IPR that applies to
this Document, to ensure that IPR has been disclosed in compliance with IETF
IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

 

If you are listed as an author or a contributor of this document, please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR, copying the BESS mailing list. The document won't
progress without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

 

If you are not listed as an author or a contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

 

This poll for adoption closes on *** 20th January 2020 ***  

 

Regards,

Matthew and Stephane

 

[1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast

 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess