Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-02

From: "Osnat Shasha" <[email-masked]>
Date: Thu, 30 Oct 2008 09:45:29 +0200

Hi,

I have a question related to the PW Associated Channel Type values
described in draft-ietf-pwe3-vccv-bfd-02:

In 5.2. PW Associated Channel Type, several Channel Types are defined
(CC type 1 is used):
*	0x21 (Internet Protocol version 4 payload) 
*	0x57 (Internet Protocol version 6 payload)
*	0x07 (BFD without IP/UDP headers)

What should be the behavior when Channel Type equal to zero is found in
the VCCV-BFD frame?
The payload may be one of the described above.

Thanks,

Osnat Shasha
Axerra Networks.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 30 Oct 2008 07:41:54 -0400

The text states that the types in this draft augment those from RFC5085:

 The CV Type is defined as a bitmask field used to indicate the
   specific CV Type or Types (i.e., none, one or more) of VCCV packets
   that may be sent on the VCCV control channel.  The values shown below
   augment those already defined in [RFC5085].  They represent the
   numerical value corresponding to the actual bit being set in the CV

    The implication is that you follow the same rules that are in RFC5085.
We should 
make this minor adjustment to the text above to stipulate that not only do
we augment the types, but you MUST follow the rules defined therein for use
of them.

    Section 5 of RFC 5085 explains this too here BTW:

   The format of the VCCV parameter field is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0c     |       0x04    |   CC Types    |   CV Types    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Control Channel Type field (CC Type) defines a bitmask used to
   indicate the type of control channel(s) (i.e., none, one, or more)
   that a router is capable of receiving control channel traffic on.  If
   more than one control channel is specified, the router agrees to
   accept control traffic over either control channel; however, see the
   rules specified in Sections 4 and 7 for more details.  If none of the
   types are supported, a CC Type Indicator of 0x00 SHOULD be
   transmitted to indicate this to the peer.  However, if no capability
   is signaled, then the PE MUST assume that its peer is incapable of
   receiving any of the VCCV CC Types and MUST NOT send any OAM control
   channel traffic to it.  Note that the CC and CV Types definitions are
   consistent regardless of the PW's transport or access circuit type.
   The CC and CV Type values are defined in Section 4.

On 10/30/08 3:45 AM, "Osnat Shasha" <[email-masked]> wrote:

> Hi,
> 
> I have a question related to the PW Associated Channel Type values described
> in draft-ietf-pwe3-vccv-bfd-02:
> 
> In 5.2. PW Associated Channel Type, several Channel Types are defined  &lrm(CC
> type 1 is used):
> 
> ·       0x21 (Internet Protocol version 4 payload)
> 
> ·       0x57 (Internet Protocol version 6 payload)
> 
> ·       0x07 (BFD without IP/UDP headers)
> 
> What should be the behavior when Channel Type equal to zero is found in the
> VCCV-BFD frame?
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 30 Oct 2008 14:11:13 +0200

Thomas and all,
>From an admittedly very casual pass thru RFC5085 it seems that it does not state explicitly what to do with the received packets identified as ACH (via the 1st nibble) but with unknown/unsupported ACH Channel Type.

Did I miss something?

Regards,
    Sasha.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Thursday, October 30, 2008 1:42 PM
To: Osnat Shasha; [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-02

    The implication is that you follow the same rules that are in RFC5085. We should
make this minor adjustment to the text above to stipulate that not only do we augment the types, but you MUST follow the rules defined therein for use of them.

    0                   1                   2                   3

Hi,

I have a question related to the PW Associated Channel Type values described in draft-ietf-pwe3-vccv-bfd-02:

In 5.2. PW Associated Channel Type, several Channel Types are defined &lrm(CC type 1 is used):

What should be the behavior when Channel Type equal to zero is found in the VCCV-BFD frame?

Thanks,

Osnat Shasha

Axerra Networks.

________________________________
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 30 Oct 2008 12:28:07 +0000

Usual thing is throw it in the bit bucket and count it.

Stewart

Alexander Vainshtein wrote:
> Thomas and all,
> From an admittedly very casual pass thru RFC5085 it seems that it does 
> not state explicitly what to do with the received packets identified 
> as ACH (via the 1st nibble) but with unknown/unsupported ACH Channel Type.
>  
> Did I miss something?
>  
> Regards,
>     Sasha.
>  
>  
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Thomas D. Nadeau
>     *Sent:* Thursday, October 30, 2008 1:42 PM
>     *To:* Osnat Shasha; [email-masked]
>     *Subject:* Re: [PWE3] draft-ietf-pwe3-vccv-bfd-02
>
>
>
>     make this minor adjustment to the text above to stipulate that not
>     only do we augment the types, but you MUST follow the rules
>     defined therein for use of them.
>
>         I have a question related to the PW Associated Channel Type
>         values described in draft-ietf-pwe3-vccv-bfd-02:
>
>         ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 30 Oct 2008 14:38:46 +0200

Stewart,
I fully agree with you.
However I would be happy to see this statement in 5085... and I did not find it there.
So my question "Did I miss something" has been not a rhetoric one...

Regards,
	Sasha

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Thursday, October 30, 2008 2:28 PM
> To: Alexander Vainshtein
> Cc: Thomas D. Nadeau; Osnat Shasha; [email-masked]
> >        that may be sent on the VCCV control channel.  The 
> values shown
> >     below
> >         The implication is that you follow the same rules 
> that are in
> >     RFC5085. We should
> >         0                   1                   2           
>         3
> >        rules specified in Sections 4 and 7 for more 
> details.  If none
> >     of the
> >         In 5.2. PW Associated Channel Type, several Channel 
> Types are
> >         defined &lrm(CC type 1 is used):
> >
> >         What should be the behavior when Channel Type equal 
> to zero is
> >         found in the VCCV-BFD frame?
> >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 30 Oct 2008 08:49:46 -0400

Is it standard practice for protocols to state how their control
packets should be counted? From what I have seen, it is not.  The MIBs
sometimes define this stuff, but not always either.

    I'd agree with Stewart: count, process and discard it.

    --Tom

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 30 Oct 2008 12:51:21 +0000

Maybe we can clarify this in the GAL-ACH draft, since this will be the 
root of all the significant extensions to this work

Stewart

Alexander Vainshtein wrote:
>>> From an admittedly very casual pass thru RFC5085 it seems 
>>>       
>> that it does 
>>     
>>> not state explicitly what to do with the received packets 
>>>       
>> identified 
>>     
>>> as ACH (via the 1st nibble) but with unknown/unsupported 
>>>       
>> ACH Channel Type.
>>     
>>>  
>>> Did I miss something?
>>>  
>>> Regards,
>>>     Sasha.
>>>  
>>>  
>>>
>>>     
>>>       
>>>        specific CV Type or Types (i.e., none, one or more) 
>>>       
>> of VCCV packets
>>     
>>>        augment those already defined in [RFC5085].  They 
>>>       
>> represent the
>>     
>>>        numerical value corresponding to the actual bit 
>>>       
>> being set in the CV
>>     
>>>     make this minor adjustment to the text above to 
>>>       
>> stipulate that not
>>     
>>>         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
>>     
>>>        
>>>       
>>>        |      0x0c     |       0x04    |   CC Types    |   
>>>       
>> CV Types    |
>>     
>>>        
>>>       
>>>        The Control Channel Type field (CC Type) defines a 
>>>       
>> bitmask used to
>>     
>>>        indicate the type of control channel(s) (i.e., none, 
>>>       
>> one, or more)
>>     
>>>        more than one control channel is specified, the 
>>>       
>> router agrees to
>>     
>>>        is signaled, then the PE MUST assume that its peer 
>>>       
>> is incapable of
>>     
>>>        consistent regardless of the PW's transport or 
>>>       
>> access circuit type.
>>

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 30 Oct 2008 14:47:23 +0100

There is a statement to this effect in Section 4 of the GACH/GAL draft
that says:

"An LER, LSR or PE MUST discard received G-ACH packets if it is not G-
   ACH capable, it is not capable of processing packets on the indicated
   G-ACH channel, or it has not, through means outside the scope of this
   document, indicated to the sending LSR, LER or PE that it will
   process G-ACH packets received on the indicated channel. The LER, LSR
   or PE MAY increment an error counter and MAY also optionally issue a
   system and/or SNMP notification."

Matthew

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: 30 October 2008 12:51
> To: Alexander Vainshtein
> Cc: [email-masked]; Osnat Shasha
> Maybe we can clarify this in the GAL-ACH draft, since this 
> will be the root of all the significant extensions to this work
> 
> Stewart
> 
> 
> >>>     The text states that the types in this draft augment 
> those from
> >>>     RFC5085:
> >>>
> >>>        that a router is capable of receiving control 
> channel traffic
> >>>     on.  If
> >>>        accept control traffic over either control 
> channel; however,
> >>>     see the
> >>>        receiving any of the VCCV CC Types and MUST NOT 
> send any OAM
> >>>     control

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 30 Oct 2008 15:55:54 +0200

Matthew,
May be it is worth to add that the same applies to the ACH channel for PWs and that the RFC emerging (presumably) from the GACH/GAL draft also updates RFC 5085.

Regards,
	Sasha

> From: BOCCI Matthew [mailto:[email-masked]] 
> Sent: Thursday, October 30, 2008 3:47 PM
> To: [email-masked]; Alexander Vainshtein
> Subject: RE: [PWE3] draft-ietf-pwe3-vccv-bfd-02
> 
>

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 30 Oct 2008 10:23:24 -0400

I think that the text that Matthew referenced from Section 4 of
draft-bocci-mpls-tp-gach-gal-00 covers the case; it could help to
explicitly add that it also applies to the PW-ACH channel type. I think
that draft-bocci-mpls-tp-gach-gal-00 should probably Update RFC4385 (and
not RFC5085) in this respect since that's where the Channel Type is
defined. This is already tagged in the GACH/GAL I-D's heading.

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 30 Oct 2008 16:45:40 +0200

Carlos,
I agree that it is 4385 and not 5085 that would be updated.
IMHO would be nice to have a dedicated section summarizing updates to 3032 and 4385 (and to any other RFC updated) in the GACH/GAL draft. Currently it only contains a section discussing relationship with 3429.

Regards,
	Sasha

> From: Carlos Pignataro [mailto:[email-masked]] 
> Sent: Thursday, October 30, 2008 4:23 PM
> To: Alexander Vainshtein
> Cc: BOCCI Matthew; [email-masked]; Osnat Shasha; [email-masked]
> > May be it is worth to add that the same applies to the ACH 
> channel for PWs and that the RFC emerging (presumably) from 
> the GACH/GAL draft also updates RFC 5085.
> > 
> > Regards,
> > 	Sasha
> > 
> >>>>>>        transmitted to indicate this to the peer.  
> However, if no
> >>>>>>     capability